Основная цель и задач= 080; учебника - представитn= 0; отечественl= 5;ым студен-там, аспирантам = 80; специалистk= 2;м современныl= 1; комплекс за = 76;ач, методов и стандартов программноl= 1; инженерии - создания и развития сложных, многоверсиl= 6;нных, тиражируемm= 9;х программныm= 3; средств и ба</t= itle>  <link rel=3DdataStoreItem href=3D"file7119.files/item0016.xml" target=3D"file7119.files/props017.xml"> <link rel=3DthemeData href=3D"file7119.files/themedata.thmx"> <link rel=3DcolorSchemeMapping href=3D"file7119.files/colorschememapping.xm= l">  <style>  </style>  </head> <body bgcolor=3D"#FFFFCC" background=3D"file7119.files/image009.jpg" lang= =3DRU link=3Dblue vlink=3Dpurple style=3D'tab-interval:35.4pt'>  <div class=3DWordSection1> <o:p> </o:p> Курс лекций по дисциплине: &la= quo;Программна&= #1103; инженерия»<o:p>= </o:p> <o:p> </o:p> Подгото= ;вил: к.э.н., доцент Гаджиев Н.К.<o:p></o:= p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <a href=3D"#_Toc50810= 2444">Аннотация.. </spa= n>6</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2445">Лекция 1. Программнаn= 3; инженерия в жизненном цикле программныm= 3; средств.. 11</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2446">1.1. Основы жизненного цикла программныm= 3; средств.. 11</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2447">1.2. Роль системотехl= 5;ики в программн = 86;й инженерии.. </spa= n>17</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2448">1.3. Системные основы современныm= 3; технологий программнl= 6;й инженерии.. </spa= n>20</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2449">Лекц&= #1080;я 2. Профили стандартов жизненного цикла систе = 84; и программнm= 9;х средств в программноl= 1; инженерии.. </spa= n>27</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2450">2.1. Назначение профилей стандартов жизненного цикла в программнl= 6;й инженерии.. </spa= n>27</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2451">2.2. Жизненный цикл профилей стандартов систем и про= 075;раммных средств.. 32</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2452">2.3. Модель профиля стандартов жизне= ;нного цикла сложных программныm= 3; средств.. 40</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2453">Лекция 3. Модели и процессы управления проектами программныm= 3; средств 43</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2454">3.1. Управление проектами программнm= 9;х средств в системе – СMMI 43</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2455">3.2. Стандарты менеджментk= 2; (администра = 90;ивного управления) качеством систем... 54</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2456">3.3. Стандарты открытых систем, регламентиl= 8;ующие структуру и интерфейсm= 9; программнm= 9;х средств.. 67</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2457">Лекция 4. Системное проектировk= 2;ние программныm= 3; средств.. 73</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2458">4.1. Цели и принципы системного проектировk= 2;ния программнm= 9;х средств.. 73</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2459">4.2. Процессы системного проектировk= 2;ния программныm= 3; средств 80</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2460">4.3. Структурноk= 7; проектировk= 2;ние сложных про = 75;раммных средств 85</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2461">4.4. Проектировk= 2;ние программныm= 3; модулей и ко= 084;понентов </= span>90</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2462">Лекция 5. Технико-эко = 85;омическое обоснованиk= 7; проектов программныm= 3; средств.. 95</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2463">5.1. Цели и процессы технико-эко = 85;омического обоснованиn= 3; проектов программныm= 3; средств.. 95</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2464">5.2. Методика 1 – экспертное технико-эк = 86;номическое<s= pan style=3D'mso-spacerun:yes'> обос= нование проектов программныm= 3; средств.. 107</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2465">5.3. Методика 2 – оценка технико-эко = 85;омических показателеl= 1; проек= ;тов программныm= 3; продуктов с учетом сово = 82;упности факторов = предваритk= 7;льной модели СОСОМО II</s= pan>. </span= >111</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2466">5.4. Методика 3 – уточненная оценка технико-эко = 85;омических пока= зателей проектов программныm= 3; продуктов с учетом полной совокупноl= 9;ти факторов детальной модели СОСОМО II</s= pan>.2000.. 115</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2467">Лекция 6. Разработка требований = 82; программныl= 4; средствам... </sp= an>119</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2468">6.1. Организациn= 3; разработки требований = 82; сложным программныl= 4; средствам... </sp= an>119</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2469">6.2. Процессы разработки требований = 82; характерисm= 0;икам сложных программныm= 3; средств.. 124</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2470">6.3. Структура основных документов, отражающих требования = 82; программныl= 4; средствам... </sp= an>131</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2471">Лекция 7. Планированl= 0;е жизненного цикла прогр= аммных средств 134</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2472">7.1. Организациn= 3; планированl= 0;я жизненного цикла сложн= ых программныm= 3; средств.. 134</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2473">7.2. Задачи планов для обеспечениn= 3; жизненного цикла сложных программнm= 9;х средств.. 138</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2474">7.3. Планированl= 0;е процессов управления качеством сложных программныm= 3; средств.. 142</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2475">Лекция 8. Объектно-ор = 80;ентированн&#= 1086;е проектировk= 2;ние программныm= 3; средств 146</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2476">8.1. Задачи и особенностl= 0; объектно-ор = 80;ентированн&#= 1086;го проек= ;тирования программнm= 9;х средств.. 146</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2477">8.2. Основные понятия и модели объектно-ор = 80;ентированн&#= 1086;го проек= тирования программныm= 3; средств.. 151</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2478">8.3. Варианты представлеl= 5;ия моделей и средства объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния программныm= 3; средств 159</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2479">Лекция 9. Управление ресурсами в жизненном ц = 80;кле программнm= 9;х средств 163</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2480">9.1. Основные ресурсы для обеспечениn= 3; жизненногl= 6; цикла &= nbsp; сложн= ых программныm= 3; средств.. 163</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2481">9.2. Ресурсы специалисm= 0;ов для обеспеч = 77;ния жизненногl= 6; цикла &= nbsp; сложных программныm= 3; средств.. 167</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2482">9.3. Ресурсы для обеспечениn= 3; функционалn= 0;ной пригодносm= 0;и при разработке сложных пр = 86;граммных средств.. 177</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2483">9.4. Ресурсы на реализациn= 2; конструктиk= 4;ных характерисm= 0;ик качества программныm= 3; средств.. 182</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2484">9.5. Ресурсы на имитацию внешней среды для об= 077;спечения тестироваl= 5;ия и испытаний программныm= 3; средств.. 186</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2485">Лекция 10. Дефекты, ошибки и риски в жизненном цикле прогр= аммных средств.. 189</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2486">10.1. Общие особенностl= 0; дефектов, ошибок и рисков в сложных программнm= 9;х средствах.. </spa= n>189</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2487">10.2. Причины и свойства дефектов, ошибок и модификациl= 1; в сложных программнm= 9;х средствах.. </spa= n>193</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2488">10.3. Риски в жизненном цикле сложных программныm= 3; средств 202</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2489">10.4. Риски при формированl= 0;и требований = 82; характерисm= 0;икам сложных программныm= 3; средств.. 208</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2490">Лекция 11. Характерисm= 0;ики качества п = 88;ограммных средств.. 214</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2491">11.1. Основные факторы, определяющl= 0;е качество сложных программнm= 9;х средств.. 214</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2492">11.2. Свойства и атрибуты качества функционалn= 0;ных возможностk= 7;й сложных программныm= 3; средств.. 218</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2493">11.3. Конструктиk= 4;ные характерисm= 0;ики качес= ;тва сложных программнm= 9;х средств.. 225</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2494">11.4. Характерисm= 0;ики качества ба = 79; данных.. 236</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2495">11.5. Характерисm= 0;ики защиты и безl= 6;пасности функционирl= 6;вания программныm= 3; средств.. 242</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2496">Лекция 12. Выбор характерисm= 0;ик качества в проектах прогр= ;аммных средств 251</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2497">12.1. Принципы выбора характерисm= 0;ик качества в проектах программнm= 9;х средств.. 251</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2498">12.2. Пример выбора и формированl= 0;я требований к характерисm= 0;икам качества программноk= 5;о средства.. 256</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2499">Лекция 13. Верификациn= 3;, тестированl= 0;е и оценивани = 77; корректноl= 9;ти программныm= 3; компонентоk= 4;.. </spa= n>262</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2500">13.1. Принципы верификациl= 0; и тестированl= 0;я программ... 262</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2501">13.2. Процессы и средства тестированl= 0;я программныm= 3; компонентоk= 4; </= span>271</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2502">13.3. Технологичk= 7;ские этапы и стратегии систематичk= 7;ского тестироваl= 5;ия программ... </sp= an>278</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2503">13.4. Процессы тестированl= 0;я структуры программныm= 3; компонентоk= 4; </= span>285</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2504">13.5. Примеры оценок сложности тестированl= 0;я программ... 293</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2505">13.6. Тестированl= 0;е обработки потоков данных про&= #1075;раммными компонентаl= 4;и.. </spa= n>298</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2506">Глава 14. Интеграция, квалификаm= 4;ионное тестированl= 0;е и испытания комплексов = 87;рограмм... </sp= an>302</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2507">14.1. Процессы оценивания характерисm= 0;ик и испытания прогр= аммных средств.. 303</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2508">14.2. Организациn= 3; и методы оценивания характерисm= 0;ик сложных комплексоk= 4; программ... 308</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2509">14.3. Средства для испытаний и определениn= 3; характерисm= 0;ик сложных комплексов = 87;рограмм... </sp= an>316</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2510">14.4. Оценивание надежности = 80; безопасносm= 0;и функционирl= 6;вания сложных программныm= 3; средств.. 327</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2511">14.5. Оценивание эффективноl= 9;ти использоваl= 5;ия ресурсов ЭВМ программнm= 9;м продуктом... </sp= an>332</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2512">Лекция 15. Сопровождеl= 5;ие и мониторин = 75; программныm= 3; средств 336</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2513">15.1. Организацl= 0;я и методы сопровождеl= 5;ия программныm= 3; средств 336</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2514">15.2. Этапы и процедуры при сопровождеl= 5;ии программныm= 3; средств 346</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2515">15.3. Задачи и процессы переноса программ и д= 072;нных на иные платформы... </sp= an>355</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2516">15.4. Ресурсы, для обеспечениn= 3; сопровождеl= 5;ия и мониторингk= 2; программнm= 9;х средств.. 365</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2517">Лекция 16. Управлениk= 7; конфигурацl= 0;ей в жизненном цикле программныm= 3; средств.. 371</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2518">16.1. Процессы управления конфигурацl= 0;ей программныm= 3; средств 371</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2519">16.2. Этапы и процедуры при управлении = 82;онфигураци&#= 1077;й программнm= 9;х средств.. 386</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2520">16.3. Технологиm= 5;еское обеспечениk= 7; при сопровождеl= 5;ии и управлении конфигурацl= 0;ей программныm= 3; средств.. 396</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2521">Лекция 17. Документирl= 6;вание программныm= 3; средств.. 402</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2522">17.1. Организациn= 3; документирl= 6;вания программныm= 3; средств 403</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2523">17.2. Формированl= 0;е требований = 82; документацl= 0;и сло&= #1078;ных программныm= 3; средств.. 408</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2524">Лекция 18. Удостовере&= #1085;ие качества и сертификацl= 0;я прогр= аммных продуктов.. </spa= n>420</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2525">18.1. Процессы сертификацl= 0;и в жизненном цикле = &nb= sp; программнm= 9;х средств.. 420</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2526">18.2. Организациn= 3; сертификаm= 4;ии программныm= 3; продуктов </= span>424</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2527">Литература= ;.. </spa= n>433</a></span= >= <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <h1><o:p> </o:p></h1> <h1><a name=3D"_Toc508102444"></a><a name=3D"_Toc508102217">Аннотаци= 03;</a></h1> <o:p> </o:p> = Основная цель курса лекций -</span= > представитn= 0; студентам, аспирантам = 80; менеджерам проектов современныl= 1; комплекс задач, метод= 086;в и стандарто = 74; программноl= 1; инженерии = - создания и развития сложных, = 084;ноговерсио&= #1085;ных, тиражируемm= 9;х программныm= 3; средств (ПС) и баз данных (Б&#= 1044;) требуемого высокого ка = 95;ества. Изложение ориентировk= 2;но на коллекти = 74;ную, групповую работу специалистl= 6;в над крупным = 80; программныl= 4;и проектами. Внимание акцентировk= 2;но на комплекс = 77; методов и пр= 086;цессов, которые спо = 89;обны непосредстk= 4;енно обеспечить = 01;ффективный жизненный цикл сложны = 93; высококаче= ственных программныm= 3; продуктов и баз данных. При этом пре= 076;полагаетс= 103;, что процесс = 99; и технологи= 03; создания ко = 84;плексов программ и документов опираются н = 72; совокупносm= 0;ь современныm= 3;, автоматизиl= 8;ованных методов и инструментk= 2;льных средств поддержки длительногl= 6; жизненного цикла программнm= 9;х продуктов. О= 076;нако не всегда эт= 086; может быть рентабельнl= 6; вследствие высокой стоимости т = 72;ких средств. В результате может снижаться к = 72;чество программныm= 3; продуктов и повышаться = 80;х стоимость.<o:p></o:p>= Быстрый рост областей применения, сложности функций и масштабов комплексов программ привел к принципиалn= 0;ному изменению м = 77;тодов в этой сфере &#= 1080; к переходу о= 090; технологии = 80;ндивидуаль&#= 1085;ого программирl= 6;вания отдельных небольших программок = 82; коллективн&= #1086;му созданию кр = 91;пных комплексов программ инженернымl= 0; методами проектировk= 2;ния и разработк = 80;. Накоl= 7;ление в мире знани= 081;, опыта разработки = 80; применения огромного количества различных с = 83;ожных программ дл= 03; ЭВМ, способс= 090;вовал систематизk= 2;ции и обобщению методов и т= 077;хнологий их разработ = 82;и, сокращению дефектов и н= 077;определенн&= #1086;стей в характери = 89;тиках и качестве поставляемm= 9;х и применяем = 99;х программныm= 3; продуктов. В результате сформироваl= 3;ась современнаn= 3; методологиn= 3; и инженерна= 03; дисциплина обеспечениn= 3; процессов жизненного цикла сложных программныm= 3; продуктов – программнаn= 3; инженерия для различн = 99;х областей применения. <o:= p></o:p> Программнk= 2;я инженерия = - это область компьютернl= 6;й науки и технологии, которая занимается построениеl= 4; программныm= 3; систем, настолько больших и сложных, что для этого требуется участие сла = 78;енных команд разработчиl= 2;ов различных с = 87;ециальност&#= 1077;й и квалификацl= 0;й. Обычно таки = 77; системы существуют = 80; применяютсn= 3; долгие годы, развиваясь от версии к версии, претерпеваn= 3; на своем жизненном пути множес = 90;во изменений, улучшение с = 91;ществующих функций, доб= 072;вление новых или удаление устаревших возможностk= 7;й, адаптацию для работы в новой среде, устранение дефектов и ошибок. Суть &#= 1084;етодологии программноl= 1; инженерии с = 86;стоит в применени = 80; систематизl= 0;рованного, научного и п= 088;едсказуемо&= #1075;о процесса пр = 86;ектировани&#= 1103;, разработки = 80; сопровождеl= 5;ия программныm= 3; средств.<o:p></o:p> Массовое создание сложных программныm= 3; средств l= 7;ромышлен</spa= n>ными меm= 0;одами и большими коллективаl= 4;и специалистl= 6;в вызвало необходи&#= 1084;ость их четкой организациl= 0;, планированl= 0;я работ по тре= 073;уемым ресурсам, этапам и сро&sh= y;кам реализации. Совокупные затраты в мире на таки= 077; разработки </sp= an>состав= 083;яют миллиарды, а для отдельных проектов <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";letter-spacing:.35pt;mso-char-type: symbol;mso-symbol-font-family:Symbol'>- миллионы долларов в год, поэтому требуется тщательный анализ экон = 86;мической эффективноl= 9;ти создания и и= 089;пользова<sp= an style=3D'font-size:14.0pt;letter-spacing:.4pt'>ния к= ;онкретных ПС. Для решения эти = 93; задач в прог= 088;аммной инженерии ф = 86;рмируется новая область зна= ;ния l= 0; научная дис = 94;иплина <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";letter-spacing:.3= 5pt; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- экономl= 0;ка жизненного цикла про</span= >граммнm= 9;х средств, как часть экономики п = 88;омышленнос&#= 1090;и и вычислительl= 5;ой техники в общей экономике государств = 80; предприятиl= 1;. Объекти = 74;но положение осложнено трудностью </sp= an>изме= рения экономичесl= 2;их характерисm= 0;ик таких объектов. Широкий спектр количествеl= 5;ных и качествен = 85;ых показателеl= 1;, которые с различных сторон характеризу= ;ют содержание этих объектов, и невысокая достоверноl= 9;ть оценки их значений, определяют значительнm= 1;ю дисперсию п = 88;и попытках описать и из= 084;ерить экономичесl= 2;ие свойства созд= ;аваемых или используемm= 9;х крупных ПС. <o:p></o:p> Вследствиk= 7; роста сфер применения = 80; ответственl= 5;ости функций, выполняемыm= 3; программамl= 0;, резко возро = 89;ла необходимl= 6;сть гарантировk= 2;ния высокого качества пр = 86;граммных продуктов, регламентиl= 8;ования и корректно = 75;о формированl= 0;я требований = 82; характерисm= 0;икам реальных комплексов программ и и= 093; достоверноk= 5;о определениn= 3;. В результат = 77; специалистm= 9; в области теории и мет= 086;дов, определяющl= 0;х качество продукции, в= 099;нуждены осваивать область развития и п= 088;именения нового, специфичесl= 2;ого продукта – п= 088;ограммных средств и систем в целом, и их качество пр = 80; использова&= #1085;ии. Сложность анализируеl= 4;ых объектов – комплексов программ и п= 089;ихологичес&= #1082;ая самоуверенl= 5;ость ряда програ = 84;мистов в собственноl= 1; “непогрешиl= 4;ости”, часто приводят к тому, что реальные ха = 88;актеристик&#= 1080; качества функционирl= 6;вания программныm= 3; продуктов о = 89;таются неизвестныl= 4;и не только дл= 103; заказчиков = 80; пользоватеl= 3;ей, но также для самих разра = 73;отчиков. Отсутствие четкого декларировk= 2;ния в документа = 93; понятий и требуемых значений характерисm= 0;ик качества ПС вызывает конфликты между заказчикамl= 0;-пользовате&#= 1083;ями и разработчиl= 2;ами-поставщ&#= 1080;ками из-за разной трак = 90;овки одних и тех же характер = 80;стик. <o:p></o:p> &n= bsp; Методы программноl= 1; инженерии поддерживаn= 2;т и конкретиз = 80;руют технологичk= 7;ский процесс, а также отслеживанl= 0;е значений качества ко = 84;понентов на этапах жизненного цикла ПС. Для каждого про = 77;кта, выполняющеk= 5;о ответственl= 5;ые функции, должны разр = 72;батываться и применятьсn= 3; система качества, специальныk= 7; планы и Программа, методологl= 0;я и инструмен = 90;альные средства разработки = 80; испытаний, обеспечиваn= 2;щие требуемые качество, надежность = 80; безопасносm= 0;ь функционирl= 6;вания программныm= 3; продуктов. Эти методы и процессы позво= ;ляют разработчиl= 2;ам и заказчика = 84; программныm= 3; продуктов более корре = 82;тно взаимодейсm= 0;вовать при определениl= 0; и реализаци = 80; требований контрактов = 80; техническиm= 3; заданий.<o:p></o:p> Основны= ;е концепции программноl= 1; инженерии сконцентриl= 8;овались и формализо = 74;ались в целостном = 082;омплексе систематизl= 0;рованных международl= 5;ых стандартов, охватывающl= 0;х и регламентиl= 8;ующих практическl= 0; все процесс = 99; жизненного = 94;икла сложных про = 75;раммных средств. Несколько десятков стандартов этого комплекса д = 86;пускают целеустремl= 3;енный отбор необходимыm= 3; процессов, в зависимостl= 0; от характерисm= 0;ик и особенносm= 0;ей конкретногl= 6; проекта, а также формированl= 0;е на их базе проблемно-о = 88;иентирован&#= 1085;ых профилей стандартов для определеннm= 9;х типов проек = 90;ов и/или предпр= 080;ятий. <o:p></o:p> Практич= ;еское применение профилей стандартов, сосредоточl= 0;вших мировой опы = 90; создания различных типов крупных комплексов программ, способствуk= 7;т значительнl= 6;му повышению производитk= 7;льности труда специ = 72;листов и качества создаваемыm= 3; программныm= 3; продуктов. Эти стандар = 90;ы определяют модификациn= 2;, мобильностn= 0; и возможнос = 90;ь повторного применения программныm= 3; компонентоk= 4; и комплексо = 74;, их расширяемоl= 9;ть и переносим = 86;сть на различны = 77; аппаратные = 80; операционнm= 9;е платформы, что непосре = 76;ственно отражается на росте эко= 085;омической эффективноl= 9;ти технологий = 80; процессов с = 86;здания различных программныm= 3; средств и систем. Для регламентиl= 8;ования процессов жизненного цикла такие профили ста = 85;дартов должны адаптироваm= 0;ься и конкретиз= ;ироваться применителn= 0;но к определеннm= 9;м классам и функциям пр = 86;ектов, процессов и компонентоk= 4; программныm= 3; средств. При этом должна сохранятьсn= 3; концептуалn= 0;ная целостностn= 0; применяемоl= 1; совокупносm= 0;и стандартов = 80; их эффектив = 85;ое, положительl= 5;ое влияние на процессы и результаты, на качество, надежность = 80; безопасносm= 0;ь программныm= 3; продуктов при реальны = 93; ограничениn= 3;х на использо = 74;ание доступных ресурсов проектов.<o:p></o:p>= <= span style=3D'mso-spacerun:yes'> В жизненном цикле комплексов программ сложно соче = 90;аются содержание, этап= ;ы и распределеl= 5;ие работ, возможен ря = 76; возвратов н = 72; более ранние технологичk= 7;ские этапы в процессе создания ко = 84;понентов ПС, они имеют не совсем опре = 76;еленные границы начала и завершения. Спеm= 4;иалисты в коллектив = 77; могут на некотором интервале в = 88;емени реша= ;ть несколько производстk= 4;енных задач и заме= 085;ять друг друга. <s= pan style=3D'letter-spacing:.15pt'>Положе&#= 1085;ие усугубляетl= 9;я трудностью поэтапного определениn= 3; качk= 7;ства компонентоk= 4; и его прогно= 079;ирования в процессе разработки, что н&#= 1077;посредстве= нно отражается на пр&#= 1086;екте в целом. Мет&#= 1086;дология программноl= 1; инженерии и стандарты р = 77;гламентиру&#= 1102;т современныk= 7; процессы управления проектами сложных систем и программныm= 3; средств. Они обеспечиваn= 2;т организациn= 2;, освоение и применение апробироваl= 5;ных, высококачеl= 9;твенных процессов проектировk= 2;ния, программирl= 6;вания, верификациl= 0;, тестированl= 0;я и сопровожд = 77;ния программныm= 3; средств и их компонентоk= 4;. Тем самым эт= 080; проекты и процессы позволяют получать ст = 72;бильные, предсказуеl= 4;ые результаты = 80; программныk= 7; продукты требуемого качества. <o:p></o:p></span= > Многообра= 079;ие классов и ви&sh= y;дов сложных комплексов программ, об= 091;словленное различными функциями и сферами применения = 89;истем, определяет формальные трудности, связанные с методами и п= 088;оцедурами д= ;оказательс= ;тва соответствl= 0;я создаваемыm= 3; и поставляе = 84;ых программныm= 3; продуктов условиям контрактов, требованияl= 4; заказчиков = 80; потребителk= 7;й. По мере расширения применения = 80; увеличения сложности систем, выделились области, в которых дефекты, нед= 086;статочное качество комплексов программ ил = 80; данных могу = 90; наносить катастрофиm= 5;еский ущерб, значительнl= 6; превышающиl= 1; положительl= 5;ый эффект от их использоваl= 5;ия. В таких криm= 0;ических системах (например, управления = 72;томными электростаl= 5;циями, крупными ба = 85;ками или системами вооружения) недопустимm= 9; проявления катастрофиm= 5;еских рисков функционирl= 6;вания программныm= 3; продуктов при любых ис= 082;ажениях исходных данных, сбоях, части= 095;ных отказах апп= ;аратуры, ошибках пользоватеl= 3;ей и других нештатных ситуациях. Подобные риски компл = 77;ксов программ мо = 75;ут определять безопасносm= 0;ь функционирl= 6;вания объектов, предприятиl= 1; и даже стран= 099;. Вследствие этого резко повысилась = 86;тветственн&#= 1086;сть специалистl= 6;в за качество результатоk= 4; их труда и создаваемыm= 3; программныm= 3; продуктов. Это требует непрерывноk= 5;о совершенстk= 4;ования, обучения и повышения квалификацl= 0;и заказчиков, разработчиl= 2;ов и пользоватеl= 3;ей в области программноl= 1; инженерии, освоения им = 80; современныm= 3; методов, процессов и международl= 5;ых стандартов, = 072; также высокой корпоративl= 5;ой культуры коллективоk= 4; специалистl= 6;в, обеспечиваn= 2;щих жизненный цикл критическиm= 3; программныm= 3; продуктов.<o:p></o:p>= В курсе лекци = 81; предполагаk= 7;тся, что проекти = 88;ование, разработка, сопровождеl= 5;ие и документирl= 6;вание программныm= 3; продуктов ведется пре = 80;мущественн&#= 1086; с использоваl= 5;ием регламентиl= 8;ованных процессов н = 72; основе профилей стандартов ISO в = соответстk= 4;ии с формализо = 74;анными требованияl= 4;и определеннm= 9;ми заказчиком. Тем самым не отражено со = 79;дание и применени = 77; открытого кода в прогр= 072;ммных продуктах, при котором = 085;евозможна их сертификацl= 0;я на соответс = 90;вие международl= 5;ым стандартам, вследствие неоднозначl= 5;ости версий ПС, изменяемых = 85;е синхронно р = 72;зличными пользоватеl= 3;ями и различным = 80; предприятиn= 3;ми. <o:p></o:p> Зна&#= 1095;ительное внимание в курсе метод = 86;логии программноl= 1; инженерии у = 76;елено фрагментам = 80; компонентаl= 4; профилей стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'>, целесообраk= 9;ным для обеспечениn= 3; высокого качества и безопасносm= 0;и применения = 87;рограммных продуктов в = 080;х жизненном цикле. Менеджмент = 88;ассматрива&#= 1077;мых проектов ориентировk= 2;н преимущестk= 4;енно на базовые стандарты серии ISO 9000:2000. Стандарты = де-факто менеджментk= 2; CMM / </span= >CMMI= изложеl= 5;ы как возможная альтернатиk= 4;а стандартам </sp= an>ISO<= span style=3D'font-size:14.0pt'> при упр = 72;влении проектировk= 2;нием ПС, однако, он&= #1080; не покрываю = 90; все процесс = 99; жизненного цикла сложных ком = 87;лексов программ. Наиболее ра = 89;пространен&#= 1085;ая сертификацl= 0;я предприятиl= 1;, производящl= 0;х программныk= 7; продукты на соответствl= 0;е стандартам CMM / CMMI существеннl= 6; проще, чем се&#= 1088;тификация на соответствl= 0;е полному про = 92;илю стандартов = 74;сего жизненного цикла ISO= . При пр= ;именении моделей CMM / CMMI учитыва= ;ется преи&= #1084;ущественно качество менеджментk= 2; проектов, однако не стандартизl= 0;руются и не контрол= 080;руются некоторые в = 72;жные компоненты = 87;роцессов ЖЦ: регламен= 090;ированные характерисm= 0;ики качества ПС; интерфейсы = 54;ткрытых систем; функ= 094;иональная и информациоl= 5;ная безопасносm= 0;ь; комплекс те = 93;нологическ&#= 1086;й и эксплуатацl= 0;онной документацl= 0;и. Это может быть оправдано для предприятиl= 1;, создающих программныk= 7; продукты средней или = 086;тносительн&= #1086; не высокой сложности, и вряд ли допус= ;тимо для разрабо = 90;чиков крупных, осо= 073;о сложных, кри= 090;ических ПС. Ак = 94;ент методологиl= 0; программно&#= 1081; инженерии н = 72; крупные про = 77;кты предполагаk= 7;т сохранение = 80; возможностn= 0; применения её базовых методов, процессов и стандартов при обеспечениl= 0; жизненного цикла относ = 80;тельно небольших проектов. Для эm= 0;ого должна быть = 087;редусмотре&= #1085;а и использовk= 2;ться адаптация с = 90;андартов, технологий = 80; инструментk= 2;рия для различн = 99;х по сложност = 80; и размеру пр= 086;ектов.<o:p></o:p> В публикацияm= 3; в области программноl= 1; инженерии широко расп = 88;остранено изобретениk= 7; многочислеl= 5;ных аббревиатуl= 8; на основе английских, = 080;ногда полужарk= 5;онных слов, которы= 077; выдаются за принципиалn= 0;ные достижения авторами публикаций. = 042; тексте лекций для облегчения восприятия учащимися, из&= #1073;егается прим&= #1077;нение аббревиатуl= 8;, за исключениеl= 4; небольшого = 80;х числа, на основе част = 86; используемm= 9;х словосочетk= 2;ний русских сло = 74;. В официальныm= 3; документах = 74; имени стандартов </sp= an>ISO<= span lang=3DEN-US style=3D'font-size:14.0pt'> часто присутствуn= 2;т через слеш имя IEC (Междунk= 2;родная электротехl= 5;ическая комиссия). Для сокращения = 80; упрощения текста лекций имя <sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-ansi-language:EN-US'>IEC<= span style=3D'font-size:14.0pt'> всюду опускается, однако его следует учитывать при использ = 86;вании и формированl= 0;и официальныm= 3; документов. <o:= p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'>Предл = 72;гаемый курс основ методологиl= 0; программноl= 1; инженерии предназначk= 7;н для заказчи = 82;ов, менеджеров крупных проектов, для аналитиков = 80; ведущих специалистl= 6;в, обеспечиваn= 2;щих все этапы жизненного цикла крупных про = 75;раммных средств и систем. Лекции реко = 84;ендуется испо&= #1083;ьзовать при обучk= 7;нии по специаль = 85;ости информатикk= 2;, студентов старших курсов, аспирантов = 80; менеджеров проектов, созданию сложных ком = 87;лексов программ на всем их жизненном цикле. Курс полезен исполнителn= 3;м научных проектов и опытно-конс = 90;рукторских работ, к которым пре = 76;ъявляются высокие требования = 82; качеству функционирl= 6;вания и ограничен = 99; доступные ресурсы разработки программныm= 3; продуктов. Материалы л = 77;кций могут служить базой при подготовке = 80; внедрении систем каче = 89;тва предприятиl= 1;, создающих сложные кон = 82;урентоспос&#= 1086;бные программныk= 7; продукты, дл= 103; их сертификацl= 0;и на соответствl= 0;е международl= 5;ым стандартам. <o:= p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'><o:p> </o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'><o:p> </o:p> <h1> <a name=3D"_Toc508102445"></a><a name=3D"_Toc508102218">Лекция 1. Программнаn= 3; инженерия в жизненном цикле программныm= 3; средств</a></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'><o:p> </o:p>= <h1><a name=3D"_Toc508102446"></a><a name=3D"_Toc508102219">1.1. Основы жизненного цикла программныm= 3; средств</a></h1> <o:p>&nbs= p;</o:p> Термином жl= 0;зненный цикл (ЖЦ) принято отражать совокупносm= 0;ь процессов и этапов развития организмов живой природы, техническиm= 3; систем, прод= 091;ктов производстk= 4;а от моментов зарождения или появлен = 80;я потребностl= 0; их создания = 080; использоваl= 5;ия до прекраще = 85;ия функционирl= 6;вания или примене = 85;ия. Это соответствm= 1;ет всеобщему з = 72;кону развития любых изделий, событий или процессов м = 77;жду их началом и концом, которые определяют цикл их создания, су= 097;ествования и применени= 03;. Программы для вычислителn= 0;ных машин обычн = 86; являются кl= 6;мпонентами жизненного цикла техническиm= 3; систем, но по своей при= 088;оде значительнl= 6; отличаются от аппаратурнm= 9;х, техническиm= 3; изделий, поэтому их жизненный цикл имеет характерныk= 7; особенностl= 0;, по сравнени= 02; с другими техническиl= 4;и объектами. Программы и данные в сис= 090;емах и вычислителn= 0;ных машинах являются наиболее гl= 0;бкими компонентаl= 4;и программноl= 1; инженерии и подвержены изменениям</spa= n> в течение всего их ЖЦ. <o:p></o= :p> <sp= an style=3D'mso-bidi-font-size:14.0pt;mso-bidi-font-weight:bold;mso-bidi-font-= style: italic'> Типовая модель процессов жизненного цикла сложной сис = 90;емы начинается = 89; концепции идеи систем = 99; или потребн = 86;сти в ней, охватывает проектировk= 2;ние, разработку, применениk= 7; и сопровожд = 77;ние системы, и за&#= 1082;анчивается снятием системы с эксплуатацl= 0;и. Программныk= 7; средства сл = 91;жат для выполнения определеннm= 9;х функций сис = 90;ем на компьюте = 88;ах. Модель жизненного цикла системы обычно разд = 77;ляют на последов = 72;тельные периоды реализации </sp= an>= - стади= 080; или этапы. Каждый подобный период вклю = 95;ает основные реализуемыk= 7; в нем процессы, работы и задачи, при з&#= 1072;вершении которых может потребоватn= 0;ся переход к следующему периоду реа = 83;изации. Общую модел= 00; жизненного цикла сложн = 86;й системы обычно разд = 77;ляют на следующи = 77; основные этапы с последующеl= 1; адаптацией каждого из них в модели <s= pan style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>жl= 0;зненного цикла конкретной = 89;истемы:<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>опред = 77;ление потребностk= 7;й;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>иссле = 76;ование и описание основных концепций;<o:p></o:p>= <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>проек = 90;ирование и разработк = 72;;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>испыт = 72;ния системы;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>созда = 85;ие и производстk= 4;о;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>распр = 86;странение и продажа;<o:p></o:p></span= > <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>экспл = 91;атация;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>сопро = 74;ождение и мониторин = 75;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>с = 85;ятие с эксплуатацl= 0;и (утилизация).<o= :p></o:p> По особеннос = 90;ям и свойствам жизненного цикла программ их целесообраk= 9;но делить на ря= 076; классов и категорий, и= 079; которых наиболее различающиl= 4;ися являются дв = 72; крупных класса – малые и большие. <o:p></o:p></span= > = 55;ервый класс составляют относительl= 5;о небольшие программы, создаваемыk= 7; одиночками или небольш = 80;ми коллективаl= 4;и (3 –5) специалис= ;тов, которые:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здаются преимущестk= 4;енно для получен = 80;я конкретных = 88;езультатов автоматизаm= 4;ии научных исследованl= 0;й или для анал= 080;за относительl= 5;о простых процессов самими разработчиl= 2;ами программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>н = 77; предназначk= 7;ны для массового тиражироваl= 5;ия и распростр = 72;нения как пl= 8;ограммного продукта на рынке, их оценивают качественнl= 6; и интуитивн = 86; преимущестk= 4;енно как “художестk= 4;енные произведенl= 0;я”; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77; имеют конкретногl= 6; независимоk= 5;о заказчика-п = 86;требителя, определяющk= 7;го требования = 82; программам = 80; их финансир = 86;вание;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77; ограничиваn= 2;тся заказчиком допустимой стоимостью, трудоемкосm= 0;ью и сроками их создания, требованиn= 3;ми заданного качества и документирl= 6;вания;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77; подлежат независимоl= 4;у тестированl= 0;ю, гарантировk= 2;нию качества и/или сертиф= 080;кации. <o:p></o:p> Для таких, а также для многих друг = 80;х видов относительl= 5;о не сложных п= 088;ограмм, нет необходимоl= 9;ти в регламентиl= 8;овании их жизненно = 75;о цикла, в длительном применении и сопровождk= 7;нии множества в = 77;рсий, в формализацl= 0;и и применени = 80; профилей ст = 72;ндартов и сертификацl= 0;и качества программ. Их разработчиl= 2;и не знают и не применяют регламентиl= 8;ующих, нормативнm= 9;х документов, вследствие чего жизненный цикл таких изде = 83;ий имеет не предсказуеl= 4;ый характер по структуре, содержанию, качеству и стоимости основных процессов “творчествk= 2;”. <o:p></o:p></spa= n> </spa= n>Вm= 0;орой класс составляют крупномасшm= 0;абные комплексы п = 88;ограмм для сложных систем управления = 80; обработки информации, оформляемыk= 7; в виде програl= 4;мных продуктов = 89; гарантировk= 2;нным качеством, и отличаются следующими особенностn= 3;ми и свойствам = 80; их жизненного цикла:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>б = 86;льшая размерностn= 0;, высокая трудоемкосm= 0;ь и стоимость = 089;оздания таких компл = 77;ксов программ определяют необходимоl= 9;ть тщательноk= 5;о анализа экономичесl= 2;ой эффективноl= 9;ти всего их жизненного цикла и возм= 086;жной конкурентоl= 9;пособности на рынке;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 90; заказчика, финансируюm= 7;его проект прог = 88;аммного средства и/или базы да&#= 1085;ных, разработчиl= 2;ам необходимо получать квалифицирl= 6;ванные конкретные требования = 82; функциям и характерисm= 0;икам проекта и пр= 086;дукта, соответствm= 1;ющие выделенномm= 1; финансировk= 2;нию и квалификацl= 0;и исполнителk= 7;й проекта; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>д = 83;я организациl= 0; и координациl= 0; деятельносm= 0;и специалистl= 6;в-разра-ботчиков при наличии единой, крупной целевой задачи, созд= 072;ния и совершенстk= 4;ования программноk= 5;о продукта, необходимы квалифицирl= 6;ванные менеджеры проектов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>в проектах таких сложных программныm= 3; средств и ба= 079; данных= с множеством различных, функционалn= 0;ных компонентоk= 4;, участвуют с = 87;ециалисты разной квалификацl= 0;и и специализаm= 4;ии, от которых требуется высокая ответственl= 5;ость за качество результатоk= 4; деяте= ;льности каждого из них; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 90; разработчиl= 2;ов проектов требуются гарантии высокого ка = 95;ества, надежности функционирl= 6;вания и безопасносm= 0;и применения компонентоk= 4; и поставляе = 84;ых программныm= 3; продуктов, в<sp= an style=3D'mso-spacerun:yes'> которые не допустимо прямое вмешательсm= 0;во заказчика и пользоватеl= 3;ей для изменений, н= 077; предусмотрk= 7;нных эксплуатацl= 0;онной документацl= 0;ей разработчиl= 2;ов;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77;обходимо применять индустриаl= 3;ьные, регламентиl= 8;ованные стандартаl= 4;и процессы, этапы и документы, а также метод = 99;, методики и комплексы средства автоматизаm= 4;ии, технологии обеспечениn= 3; жизненного цикла компл = 77;ксов программ. <o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Такие крупномасшm= 0;абные комплексы программ являютl= 9;я компонентаl= 4;и систем, реализующиl= 4;и обычно их основные, функционалn= 0;ные свойства, у= 074;еличивающи&= #1084;и сложность и создающими предпосылкl= 0; для последу= 02;щих изменений и = 93; жизненного цикла. Реализациn= 3; ЖЦ, методоло= 075;ии управления = 80; изменения П = 57; зависит от многих факторов, от персонала, техническиm= 3;, организациl= 6;нных и договорны = 93; требований = 80; сложности проекта. Множество текущих состояний и модификациl= 1; компоненm= 0;ов сложных ПС менеджерам необходимо упорядочивk= 2;ть, контролироk= 4;ать их развитие = 080; применение участникам= и проекта. Орг= 072;низованное, контролируk= 7;мое и методично = 77; отслеживан= ие динамики изменений в жизненном ц = 80;кле программ и д= 072;нных, их слаженна= 03; разработка при строгом = 091;чете и контроле каждого изменения, является основой эффективноk= 5;о, поступателn= 0;ного развития ка = 78;дой крупной системы методами программноl= 1; инженерии. <o:p= ></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Существуеm= 0; мl= 5;ожество моделей процессов жизненного = 94;икла систем и про= 075;раммных средств, но три из них в международl= 5;ых стандартах</spa= n> обычно квал = 80;фицируются как фундаментаl= 3;ьные: каскадна= ;я; инкрементнk= 2;я; эволюционнk= 2;я. Каждая из указанных м = 86;делей может быть и= 089;пользована самостоятеl= 3;ьно или скомбин = 80;рована с другими дл= 103; создания гибридной модели жизненного цикла конкретногl= 6; проекта. При этом конкре = 90;ную модель жизненного цикла системы или ПС следует выбирать та = 82;, чтобы процессы и задачи были связаны между собой, и определен = 99; их взаимосвязl= 0; с предшествуn= 2;щими процессами, видами деят = 77;льности и задачами. <o:p></o:= p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Каскадная модель жизненного цикла наиб = 86;лее известна и п= 088;именяется достаточно широко. Она по существу реализует принцип одн = 86;кратного выполнения каждого из базовых процес= сов и этапов в их естественнm= 9;х границах. На рис. 1.1 представлеl= 5; пример этапов каскадной м = 86;дели ЖЦ ПС, которая в последующиm= 3; лекциях используетl= 9;я как ориенти = 88; при изложении процессов п = 88;ограммной инженерии. При этом в лекциях акцентируеm= 0;ся внимание на методах обеспечениn= 3; качества программныm= 3; продуктов и = 085;е отражено программирl= 6;вание модулей и ко= 084;понентов, которое остается за границами программноl= 1; инженерии. Связь между этапами показана то = 83;ько сверху вниз, тогда как в реальных пр = 86;цессах жизненного цикла следует учи = 90;ывать возможностn= 0; возврата на предшествуn= 2;щие этапы, снизу ввер = 93; для их уточн= 077;ния и корректироk= 4;ки результатоk= 4;.<o:p></o:p> При применении этой модели = 076;ля создания каждого программноk= 5;о компонента, соответствm= 1;ющие работы и зад= 072;чи п= ;роцесса жизненного цикла обычно выполняют последоватk= 7;льно. Однако они могут быть ч= 072;стично выполнены параллельнl= 6; в случаях пе= 088;екрытия последоватk= 7;льных работ. Когда несколько компонентоk= 4; разрабатывk= 2;ют одновременl= 5;о, для них работы и задачи процесса разработки могут быть выполнены параллельнl= 6;. Процессы заказа и поставки, а также вспомогатеl= 3;ьные и организац = 80;онные процессы выполняютсn= 3; параллельнl= 6; с процессам = 80; разработки. Процессы сопровождеl= 5;ия и эксплуатацl= 0;и обычно реализуютсn= 3; после проце = 89;са разработки. <o:= p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Модель процессов жизненного цикла системы и степень её практическl= 6;го применения = 74; качестве обязательнl= 6;го или рекомендуеl= 4;ого документа зависит от роли конкре = 90;ного программноk= 5;о продукта в системе. Должна быт= 00; определена соответствm= 1;ющая модель жизн = 77;нного цикла систе = 84;ы, в которой программныl= 1; продукт становится её частью. Установленl= 0;е этого поможеm= 0; определить</spa= n>, можно ли использоваm= 0;ь конкретную = 84;одель для разработки, эксплуатацl= 0;и или сопрово = 78;дения программноk= 5;о средства. Программныk= 7; средства могут быть постоянно (резидентно) размещены в компьютераm= 3;, встроены ка = 82; часть прогр = 72;ммно-аппара&= #1090;ных средств или = 080;нтегрирова&= #1085;ы в объект техническиm= 3; средств. В лю&#= 1073;ом случае зака = 79;, поставку, разработку, эксплуатацl= 0;ю или сопровождеl= 5;ие программныm= 3; средств необходимо координироk= 4;ать и гармонизи = 88;овать с аналогичн = 99;ми процессами для всей исходной системы.<o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Для проект = 72; системы должен быть проведен выбор одной или нескольких = 89;оответству&#= 1102;щих моделей жизненного цикла. Необх= 086;димо установить, = 103;вляется ли модель жизненного цикла прогр = 72;ммного средства сl= 6;ставной частью модели жизненного цикла систе = 84;ы либо полной моделью жизненного цикла ПС. Каждая модель жизн = 77;нного цикла содер = 78;ит некоторые процессы, которые могут быть выполнены последоватk= 7;льно, повторно ил = 80; комбинировk= 2;нно. Процессы должны быть отображены = 74; выбранной модели жизн = 77;нного цикла, с точки зрени= 03; создания модифицируk= 7;мого, развивающеk= 5;ося, структурирl= 6;ванного и планируем = 86;го продукта, ре= 079;ультаты одного процесса из модели жизн = 77;нного цикла должн = 99; быть переда = 85;ы следующему. = 042; этом случае соответствm= 1;ющие документы должны быть созданы к ок= 086;нчанию определеннl= 6;го процесса, до начала след = 91;ющей работы.<o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> = Должны быт= 00; оl= 7;ределены стороны (специалист = 99;, предприятиn= 3;), участвующиk= 7; в проекте системы, и их <= span style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>оm= 0;ветственно= 089;ть за конкретн = 99;е процессы и р= 077;зультаты в ЖЦ. Следуе&#= 1090; учесть все работы и задачи, связ= 072;нные с взаимодейсm= 0;виями (интерфейса = 84;и) между этими сторонами. Для большог = 86; проекта, в ко&#= 1090;орый вовлечено много лиц, необходим р = 72;звитой администраm= 0;ивный надзор и контроль, проведение внутренних = 80; независимыm= 3; оценок, анализов, аудиторскиm= 3; проверок, инспекций и подготовка отчетов, являющихся главным инструментk= 2;рием для большог = 86; проекта. <o:p></o:p> Современнm= 9;е предприятиn= 3; шl= 0;роко используют модели проц = 77;ссов жизненного цикла в качестве составной части деятельносm= 0;и по определе = 85;ию и усовершен = 89;твованию процессов, связанных с = 087;рограммным&= #1080; средствами. <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>Пl= 8;именение стандартов жизненного цикла позволяет ориентировk= 2;ться специалистk= 2;м на построен = 80;е систем и комплексов программ из крупных функционалn= 0;ных узлов, отвеч= 072;ющих требованияl= 4; стандартов, применять отработаннm= 9;е и проверенныk= 7; проектные решения. Они определяют унифицировk= 2;нные интерфейсы взаимодейсm= 0;вия компонентоk= 4; таким образом, что разработчиl= 2;у системы, как правило, не требуется в = 76;аваться в детали внутреннегl= 6; устройства = 01;тих компонентоk= 4;. Стандарты, относящиесn= 3; к программныl= 4; комплексам (функционал= 00;ным частям) систем, обле= 075;чают повторное использоваl= 5;ие в новых сист= 077;мах готовых и апробироваl= 5;ных программныm= 3; продуктов. Для унифика= ;ции и регламентиl= 8;ования процессов Ж = 62; ПС такие совокупносm= 0;и - профили стандартов должны адап = 90;ироваться и конкретиз= ;ироваться применителn= 0;но к определен = 85;ым классам проектов, процессов и компонентоk= 4; ПС. Таким образом, разработка программноk= 5;о продукта, в знаm= 5;ительной степени, может сводиться к интеграции = 80; комплексирl= 6;ванию из стандарт = 80;зированных компонентоk= 4;. <o:p></o:p> Методы l= 0; процессы стандартизk= 2;ции жизненного цикла ПС играют стабил= изирующую и организующm= 1;ю роль во все= 084; жизненном цикле многи = 93; сложных сис = 90;ем. Они оk= 3;еспечивают:<o= :p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 72;сширение и совершенстk= 4;ование функций сис = 90;ем и компонентl= 6;в с сохранени = 77;м их целостностl= 0; и первичных = 079;атрат;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 80;стематичес&#= 1082;ое повышение качества фу = 85;кционирова&#= 1085;ия комплексов программ и баз данных для решения = 079;адач пользоватеl= 3;ей в различной внешней среде;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 83;учшение технико-эко = 85;омических характерисm= 0;ик применения систем и про= 075;раммных продуктов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;вершенство&#= 1074;ание технологий обеспечениn= 3; жизненного цикла сложн = 99;х систем и комплексов программ.<o:p></o:p>= Для этого при создании и сопровождеl= 5;ии сложных, рас= 087;ределенных<= span style=3D'mso-spacerun:yes'> систем, форми= ;ровании их архитектурm= 9;, при выборе стандартов для програм = 84;ных компонентоk= 4; и их связей, целесообраk= 9;но учитывать рn= 3;д совре= ;менных концептуаl= 3;ьных требований программноl= 1; инженерии и формированl= 0;я их жизненного цикла:<o:p></o:p><= /span> <![if !supportList= s]>-&nb= sp; = <![endif]>арх= итектура комплекса п = 88;ограмм должна соответстk= 4;овать текущим и персп= ;ективным целям и стратегичеl= 9;ким, функционалn= 0;ным задачам, создаваемоl= 1; системы, быть достаточнl= 6; гибкой и допускать относительl= 5;о простое, без коренных структурныm= 3; изменений, развитие и наращиваниk= 7; функций и ре= 089;урсов системы в соответствl= 0;и с расширени = 77;м сфер и задач её применен = 80;я;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>в структуре и компонентаm= 3; ПС и системы следует предусматрl= 0;вать обеспечениk= 7; максимальнl= 6; возможной сохранностl= 0; инвестиций = 74; аппаратные и программныk= 7; средства, а также в базы данных при длительном развитии, сопровождk= 7;нии и модернизацl= 0;и системы;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>нео= бходимо обеспечиваm= 0;ь эффективнl= 6;е использовk= 2;ние ресур= ;сов в ЖЦ системы и минимизироk= 4;ать интегральнm= 9;е затра= ;ты на обработк = 91; данных= в типовых режимах её ф= 091;нкциониров&= #1072;ния с учетом эксплуатацl= 0;онных затрат и капитальныm= 3; вложений в создание системы и пр= 086;граммного продукта;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>дол= жны быть обеспечены безопасносm= 0;ь функционирl= 6;вания системы и надежная защита данных от ошибок, от разрушения или потери информации, а также авторизациn= 3; пользоватеl= 3;ей, управление рабочей заг = 88;узкой, резервировk= 2;нием и оперативныl= 4; восстановлk= 7;нием функционирl= 6;вания системы и программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>для обеспечениn= 3; перспективm= 9; развития жи = 79;ненного цикла систе = 84;ы и комплекса программ целесообраk= 9;но предусматрl= 0;вать возможностn= 0; интеграции гетерогеннm= 9;х вычислителn= 0;ных компонентоk= 4; и возможностn= 0; переноса ПС = 080; БД на различные аппаратные = 80; операционнm= 9;е платформы н = 72; основе концепции и стандартоk= 4; открытых си = 89;тем;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>сле= дует обеспечить комфортное обучение и максимальнl= 6; упрощенный доступ= конечных п = 86;льзователе&#= 1081; к управлени= 02; и результат = 72;м функционирl= 6;вания системы и п= 088;ограммного продукта на основе совр = 77;менных графическиm= 3; средств и наглядных п = 86;льзователь&#= 1089;ких интерфейсоk= 4;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Наиболее актуальна стандарти = 79;ация процессов жизненного цикла комплексов программ пр = 80; коллективнl= 6;й разработке = 80; сопровождеl= 5;ии крупных критическ = 80;х систем управления = 74; реальном времени, к<s= pan style=3D'mso-spacerun:yes'> котор= ;ым предъявляn= 2;тся высокие тр = 77;бования к качеству. В этих случая = 93; особенно необходимо = 95;еткое планированl= 0;е и управлени = 77; технологичk= 7;скими процессами их жизненного цикла. Созданы или разрабатывk= 2;ются комплексы м = 77;ждународны&#= 1093; стандартов, в той или иной степени регламентиl= 8;ующие проце= ;ссы проектироk= 4;ания, разработки, эксплуатацl= 0;и и сопровожд = 77;ния в ЖЦ програм= 084; и баз данных. Они обычно ориентировk= 2;ны на ПС, выполн&#= 1103;ющие важные функции в системах управ= ;ления объектами, технологиm= 5;ескими процессами или при обработке ответственl= 5;ой информации. При&= #1084;енение таких стандартов полностью при создани = 80; и использовk= 2;нии простых про = 75;рамм, узкого или эксперименm= 0;ального назначения (первого кла= 089;са см. выше) не всегда може = 90; быть оправдано. О= 076;нако они определяют </sp= an>современн = 91;ю культуру программноl= 1; инженерии и стандартизk= 2;ции жизненного цикла комплексов программ высокого ка = 95;ества. <o:p></o:p> <o:p> </o:p> <h1> = <a name=3D"_Toc508102447"></a><a name=3D"_Toc508102220">1.2. Роль системотехl= 5;ики в программноl= 1; инженерии</a><= /h1> <o:p> </o:p> С&= #1080;стема <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > это совокупносm= 0;ь взаимодейсm= 0;вующих компонентоk= 4;, работающих совместно для достижения определеннm= 9;х целей. Определяющ= 080;м признаком системы является то, что свойств = 72; и поведение системных компонентоk= 4; влияют друг на друг= 072; сложным обр = 72;зом. Корректное функционирl= 6;вание каждого системного компонента зависит от функционирl= 6;вания многих других компонентоk= 4;. Системы час = 90;о имеют иерархичесl= 2;ую структуру, т.е. в качеств&= #1077; компонентоk= 4; содержат другие системы (подсистем = 99;). Определяюm= 7;ее свойство подсистем з = 72;ключается в том, что они могут функционирl= 6;вать самостоятеl= 3;ьно, независимо от тех систе= 084;, в состав которых входят. Вместе с тем их поведени = 77; в составе ко= 085;кретной системы зависит от взаимодейсm= 0;вия с другими подсистемаl= 4;и.<o:p></o:p> &n= bsp; Сложность взаимодейсm= 0;вия между систе = 84;ными компонентаl= 4;и означает, чт= 086; система не сводится просто к сумме её составных ч = 72;стей. Она имеет определеннm= 9;е свойства, ко= 090;орые присущи ей именно как ц= 077;лостной системе. Такие интеграцио&= #1085;ные свойства н = 77; могут быть свойствами отдельной части системы. Они проявляютсn= 3; тогда, когда система рас = 89;матриваетс&#= 1103; как единое целое. Некоторые и = 79; этих свойст = 74; можно вывести из аналогичныm= 3; свойств отдельных подсистем, н= 086; чаще они являются ко = 84;плексным результатоl= 4; взаимодейсm= 0;вия подсистем и их невозможно оценить, исходя из анализа отдельных системных компонентоk= 4;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Системотеm= 3;ника <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Courier New";mso-hansi-font-family:"Courier New";color:windowtext;mso-char= -type: symbol;mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > </s= pan>как технология создания систем охватывает все аспекты = 089;оздания и модернизацl= 0;и сложных вычислителn= 0;ных комплексов, где програм = 84;ные продукты играют ведущую рол= 00;. Сюда можно отнести технологию = 88;азработки аппаратных средств, внутренних вычислителn= 0;ных процессов и связей всей системы, а также техно = 83;огию создания ПС. Инженеры системотехl= 5;ики на основе спецификацl= 0;и требований = 89;истемы определяют её архитектурm= 1; и затем, собр&#= 1072;в воедино её отдельные части, созда= 102;т законченнуn= 2; систему.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;color:windowtext'> Пl= 6; мере увеличения = 74; системах роли програ = 84;мных компонентоk= 4; методы прог = 88;аммной инженерии все шире исполь = 79;уются в процессе с= 086;здания разнообразl= 5;ых систем. Системотехl= 5;ика, как техноло = 75;ия создания систем, охватывает процессы со = 79;дания спецификацl= 0;й, проектировk= 2;ния, разработки, тестированl= 0;я, внедрения и сопровождеl= 5;ия систем как единог= 086; целого. = 057;истемотехн&= #1080;к, занимающиl= 1;ся разработкоl= 1; вычислителn= 0;ных систем, не может быть сосредоточk= 7;н только на программноl= 4; комплексе, о= 085; должен удел= 03;ть равное внимание программноl= 4;у средству, аппаратным средствам и средствам взаимодейl= 9;твия с пользоватеl= 3;ями и системным окружением. Специалист по созданию программноk= 5;о продукта должен пони = 84;ать задачи и методы системотехl= 5;ики, поскольку возникающиk= 7; проблемы ча = 89;то являются результатоl= 4; решений, при= 085;ятых системоm= 0;ехниками.<o:p></o:= p> Прог= раммный менеджер и/или системный инженер должен быть знаком с несколькимl= 0; способами проектировk= 2;ния, знать, как пе&#= 1088;евести расплывчатm= 9;е требования = 80; пожелания заказчика в четкое техническоk= 7; задание, и уметь разговаривk= 2;ть с пользоват = 77;лем системы на языке предм = 77;тной области, а не на професси = 86;нальном программисm= 0;ском жаргоне. Такие способностl= 0; требуют, в свою очеред= 00;, гибкости и открытости, = 095;тобы ухватить су = 97;ность предметной области раз = 83;ичных приложений = 80; стать в ней специалистl= 6;м. Программныl= 1; инженер должен обладать возможностn= 0;ю переходить от одного уровня абстракции = 82; другому на р= 072;зных стадиях про = 77;кта: от особых процедур и требований приложения = 82; абстракцияl= 4; программноl= 1; системы, к специфике дизайна системы и, наконец, к уровню дета = 83;ьного кодированиn= 3; программ. <o:p></o:p> Неформальl= 5;ый подход, применяющиl= 1;ся к построени= 02; некоторых программ, не= 076;остаточен для разработки больших систем. Стоимость аппаратных средств постепенно снижается, тогда, как стоимо = 89;ть программныm= 3; продуктов стремительl= 5;о возрастает. Возникла необходимоl= 9;ть в новых технологияm= 3; и методах управления комплексныl= 4;и проектами разработки больших программныm= 3; систем. Таки= 077; методы составили программнуn= 2; инженерию. Возрастает как объем пр= 086;изводства программноk= 5;о продукта, та= 082; и его сложно= 089;ть. Кроме того, сближение вычислителn= 0;ной и коммуника = 94;ионной техники ставит новы = 77; требования перед специалистk= 2;ми. Это также является одной из причин возн = 80;кновения проблем при разработке программныm= 3; систем, как и то, что многие= компании, занимающиеl= 9;я производстk= 4;ом ПС, не уделяют должного внимания эф = 92;ективному применению = 89;овременных методов и стандартов, разработанl= 5;ых в программноl= 1; инжен= ;ерии. <o:p></o:p> Программнk= 2;я инженерия -</span= > как часть системотехl= 5;ики охватывает все аспекты жизненного цикла ПС от начальной стадии разр = 72;ботки системных требований до завершения использоваl= 5;ия программноk= 5;о продукта. Пр= 080; этом специалистm= 9; выполняют практическm= 1;ю, инженерную работу. Они применяют теоретичесl= 2;ие построения, методы и средства та = 84;, где это необ= 093;одимо, но делают эт= 086; выборочно и всегда пытаются найти практическl= 6;е решение задачи, даже если не суще= 089;твует подходящей теории или м= 077;тодов решения. Инж= 077;неры всегда должны понимать, чт= 086; они работаю = 90; в организац = 80;онных и финансовы = 93; рамках заключенныm= 3; контрактов, = 080; ищут решени = 77; поставленнl= 6;й перед ними задачи с учетом условий контракта. П= 088;ограммная инженерия не рассматривk= 2;ет техн = 80;ческие аспекты де = 90;ального создания компонентоk= 4; = - в её ведение входят таки = 77; задачи, как управление проектами П = 57; и разработк = 72; средств, мет= 086;дов и теорий, необходимыm= 3; для обеспечениn= 3; жизненного цикла комплексов программ. Программирl= 6;вание компонентоk= 4; = - это дел = 86;, главным образом, индивидуалn= 0;ное, а программн = 72;я инженерия систем -</span= > всегда коллективнk= 2;я работа.<o:p></o:p> Программнm= 9;е средства вс = 77; больше встраиваютl= 9;я в различные системы. Раб= 086;та с такими проектами требует от программноk= 5;о инженера широкого взгляда на общие задач = 80; проектировk= 2;ния систем. Программноl= 4;у инженеру необходимо участвоватn= 0; в выработке требований для всей сис= 090;емы, а также пыта= 090;ься понять прикладную область ПС еще до начал= 072; обдумываниn= 3; абстрактныm= 3; интерфейсоk= 4;, требованияl= 4; которых должен буде = 90; отвечать программныl= 1; продукт. Рас= 089;матривая программнуn= 2; инженерию как часть системотехl= 5;ики, обнаруживаk= 7;тся важность компромиссk= 2; как отличит = 77;льного признака лю = 73;ой инженерной дисциплины. Существуют принципиалn= 0;ные трудности изменения масштаба пр = 80; попытке привнести приемы написания малых программ в проектировk= 2;ние больших про = 75;раммных комплексов. <o:= p></o:p> = Разработчl= 0;ки проекта сис = 90;емы вынуждены тратить время на общение дру = 75; с другом, вместо того, чтобы писат= 00; программы. Иногда люди покидают проект, и это влияет не только на работу выполняемуn= 2; непосредстk= 4;енно ими, но и на работу тех, кто от них зависит. Замена разработчиl= 2;а в проекте может требо = 74;ать обучения и серьезнейшk= 7;й подготовки = 85;ового специалистk= 2; для освоени= 03; им техничес = 82;их условий проекта и текущего со = 89;тояния системы. Любое изменение первоначалn= 0;ных требований = 82; системе влияет на мн= 086;гие составные части проекта, выливаясь в дальнейшем = 74; задержку по = 89;тавки готового пр = 86;дукта. Как в любой инженерной отрасли, программныl= 1; инженер должен развивать умения, позв= 086;ляющие построить набор моделей и оценить эти модели, управляя выбором ком = 87;ромиссов. Такие модел = 80; используютl= 9;я на этапе определениn= 3; требований = 82; проектируеl= 4;ой системе, в разработке архитектурm= 9; программно&#= 1075;о средства и н= 072; стадии реализации проекта. Программныl= 1; инженер = - это чле = 85; команды, поэтому должен обладать навыками общения и межличностl= 5;ых отношений, а также уметь планироватn= 0; не только свою работу, &#= 1085;о и координир = 86;вать её с работой других. <o:p></o:p> Специалисm= 0; по программноl= 1; инженерии должен знат= 00; системотехl= 5;ику вычислителn= 0;ных систем, поскольку здесь программныl= 1; компонент играет опре = 76;еляющую роль. Таким образом, технологии программнl= 6;й инженерии часто являются критическиl= 4; фактором пр = 80; разработке сложных вычислителn= 0;ных систем. Интеграциоl= 5;ные свойства систем проя = 74;ляются только тогд = 72;, когда система рас = 89;матриваетс&#= 1103; как единое целое. В этом состоит сложность прогнозироk= 4;ания и оценки её с&#= 1074;ойств, поскольку иногда можн = 86; измерить характерисm= 0;ики только подс = 80;стем, из которых с= 086;стоит комплекснаn= 3; система. Вm= 9;сокие темпы роста основных ресурсов аппар= ;атных средств (приблизит = 77;льно на порядок каждые пять лет), и сохран&= #1103;ющаяся потребностn= 0; в увеличени = 80; их использо = 74;ания со стороны р= 072;зличных пользоватеl= 3;ей и сфер применения, приводят к необходимоl= 9;ти адекватногl= 6; совершенстk= 4;ования технологий создания пр = 86;граммных средств и ба= 079; данных. <o:p></o:p> <s= pan style=3D'mso-bidi-font-size:14.0pt'><o:p> </o:p> <h1><a name=3D"_Toc508102448"></a><a name=3D"_Toc508102221">1.3. Системные основы современныm= 3; технологий = &nb= sp; программнl= 6;й инженерии</a> = </h1> <o:p> </o:p> = Основная цель современныm= 3; технологий</spa= n> программноl= 1; инженерии состоит в обеспечениl= 0; эффективноl= 9;ти всего жизненного цикла компл = 77;ксов программ дл= 03; ЭВМ в различных проблемно-о = 88;иентирован&#= 1085;ых областях. В понятие современноl= 1; технологии = 74;ключается совокупносm= 0;ь методов и инструментk= 2;льных средств автоматизаm= 4;ии, а также технологичk= 7;ские процессы, обеспечиваn= 2;щие жизненный цикл сложны = 93; ПС с заданны= 084;и функционалn= 0;ными и конструктиk= 4;ными характерисm= 0;иками качества. Для этогl= 6; рекомендуеm= 0;ся использоваm= 0;ь наиболее эффективныk= 7; и совершенныk= 7; методы прое = 82;тирования и проводить комплекснуn= 2; автоматизаm= 4;ию ЖЦ ПС (см. рис. 1.1).= Целеустре = 84;ленная деятельносm= 0;ь разработчиl= 2;ов-поставщи&#= 1082;ов должна быт= 00; направлена на удовлетворk= 7;ние требований = 79;аказчиков и пользоват = 77;лей программныm= 3; продуктов при их применении по прямому н= 072;значению. <o:p></o:p> = Эта деятельносm= 0;ь регламентиl= 8;уется рядом методов и стандартов, которые явл= 03;ются компонентаl= 4;и технологичk= 7;ского обеспечениn= 3; сложных ПС в течение их жизненного цикла. Их применение предполагаk= 7;т высокую дисциплину коллектива специалистl= 6;в, использоваl= 5;ие им методик, стандартов, типовых нор = 84;ативных документов = 80; средств автоматизаm= 4;ии разработки, которые регламент= ;ируют порядок организациl= 0; и проведени= 03; работ по выполнению технологичk= 7;ских операций, направленнm= 9;х на получени = 77;, в имеющихся = 086;рганизацио&= #1085;но-техничеl= 9;ких условиях, готового программноk= 5;о продукта с заданными функциями и качеством.<o:p></o:p>= Методиче= ской основой технологии, регламентиl= 8;ующей деятельносm= 0;ь специалистl= 6;в, является типовой тех = 85;ологически&#= 1081; процесс. Он отражается набором этапов и операций в п= 086;следовател&= #1100;ности их выполнения = 80; взаимосвязl= 0;, обеспечиваn= 2;щих ведения работ на все= 093; стадиях от инициироваl= 5;ия проекта и подготовки техническоk= 5;о задания до завершения = 80;спытаний или применения версии ПС. <s= pan style=3D'font-size:14.0pt'>В современныm= 3; технологияm= 3; объединяютl= 9;я методы непо = 89;редственно&#= 1081; разработки программ и данных с методами обеспечениn= 3; качества и о= 088;ганизации управления их создание = 84; с учетом технологичk= 7;ских и человеческl= 0;х факторов. <o:p></o:p></span= > Индустр= ;иализация технологий программноl= 1; инженерии базир= ;уется на стандартизk= 2;ции процессов разработки программ, их структурноk= 5;о построения = 80; интерфейсоk= 4; с операцион = 85;ой и внешней средой. Для этого с само= 075;о начала разработки должны определятьl= 9;я состав и этапы работ, необходимыk= 7; для достижения конечной цели, а также требуемые для их выпол= 085;ения ресурсы. Техническиk= 7; и управленч = 77;ские проверки, анализ каче = 89;тва результатоk= 4; промежуточl= 5;ых работ и компонентоk= 4;, а также корректносm= 0;и их взаимосвязk= 7;й должны обеспечиваm= 0;ь руководитеl= 3;ям и всем разра= 073;отчикам уверенностn= 0; достижения требуемого конечного результата проекта.<o:p></o:p> Дос&#= 1090;ижение высоких значений качества ко = 84;плексов программ существеннl= 6; зависит от качества технологии = 80; инструментk= 2;льных средств, используемm= 9;х разработчиl= 2;ами для обеспечениn= 3; ЖЦ ПС. Уровень автоматизаm= 4;ии, качество технологии = 80; средств, при= 084;еняемых для поддержки процессов жизненного цикла ПС, обычно сильно коррелировk= 2;н с качеством создаваемm= 9;х комплексов программ, а также с качеством средств авт = 86;матизации для их оценивания. Оценивание = 76;остоинств технологичk= 7;ской базы ЖЦ позволяет прогнозироk= 4;ать возможное качество ПС и ориk= 7;нтировать заказчика и пользоватеl= 3;ей при выборе разработчиl= 2;а и поставщика для оl= 7;ределенног= 086; проекта с требуемыми характерисm= 0;иками. Поэтому определениk= 7; уровня техн = 86;логической поддержки п = 88;оцессов жизненного цикла, организациl= 6;нного и инструмен = 90;ального обеспеченl= 0;я ПС, непосред= 089;твенно связано с оц= 077;ниванием реальных ил = 80; возможных характерисm= 0;ик качества ко = 85;кретного комплекса п = 88;ограмм.<o:p></o:p></sp= an> Значител= ;ьные достижения = 74; развитии и применении современныm= 3; методов и технологии обеспечениn= 3; крупномасшm= 0;абных проектов ПС = 089;осредоточе&= #1085;ы в методолог = 80;и СММ (Capab= ility Maturity <= span class=3DIieoeiue>Model – система и модель для оценки зрелости) ко= 084;плекса технологичk= 7;ских процессов ж = 80;зненного цикла ПС, а также в её последующеl= 4; развитии в </s= pan>CMMI:2003 (см. лекцию 3). Она основана на формализацl= 0;и и использов = 72;нии пяти уровне = 81; зрелости технологий поддержки Ж = 62; ПС, которые также определяют = 87;отенциальн&#= 1086; возможное к = 72;чество создаваемыm= 3; на предприятиl= 0; комплексов программ. Че= 084; выше уровен= 00; зрелости, те= 084; выше статус предприятиn= 3; среди поставщикоk= 4;, доверие к ег= 086; продукции, е= 075;о конкурентоl= 9;пособность, а также возможное качество программныm= 3; продуктов. Тем самым пр= 080; выборе значений характерисm= 0;ик качества ПС можно в соответствm= 1;ющей степени доверять по = 89;тавщику и предприят = 80;ю разработчиl= 2;а, что они смогут полностью р = 77;ализовать требования заказчика. Эти уровни зрелости характеризm= 1;ются степенью формализацl= 0;и, адекватносm= 0;ью измерения и документирl= 6;вания процессов и продуктов в ЖЦ ПС, полнот&#= 1086;й применения стандартов = 80; инструментk= 2;льных средств автоматизаm= 4;ии работ, наличием и г= 083;убиной реализации функций системой качества технологичk= 7;ских процессов и их результа = 90;ов. <o:p></o:p> Методоло= ;гия обеспечениn= 3; качества ПС = 074; программноl= 1; инженерии поддержана = 88;ядом методическl= 0;х документов = 80; инструментk= 2;льных средств, а также форма = 83;изована комплексом международl= 5;ых стандартов (см. Приложен&#= 1080;е 1). Внедрение комплекса требует больших усилий и затрат, что ограничило его массово = 77; использоваl= 5;ие для относит = 77;льно простых и ср= 077;дней сложности проектов. <sp= an style=3D'font-size:14.0pt'> Конце= птуальные и организац = 80;онные основы адми = 85;истративно&#= 1075;о управления жизненным циклом и качеством П = 57; в системе СММ, а также CMMI:2003,= определ= ;ены в восьми базовых принципах, к= 086;торые декларировk= 2;ны в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9000:2000 и ISO 15504:1-9. <o:p></o:p></= span> Принцип 1 = - Ориентация = 87;редприятия-&= #1088;азработчик= ;а на потребит = 77;ля-заказчик&= #1072; . “Предприятl= 0;я зависят от своих потребителk= 7;й и, таким образом, дол= 078;ны понимать текущие и будущие потребностl= 0; потребителk= 7;й-заказчико&#= 1074;, удовлетворn= 3;ть их требован = 80;я и стремитьс= 03; превзойти и = 93; ожидания”. <o:p></o:p= > При&#= 1085;цип 2 - Лидерство-р = 91;ководство. “Лидеры обеспечиваn= 2;т единство назначения = 80; направлениn= 3; деятельносm= 0;и предприятиn= 3;. Они должны создавать и поддерживаm= 0;ь внутреннюю = 86;кружающую среду, в которой специалистm= 9; могут в полной мере участвоватn= 0; в достижени = 80; стратегичеl= 9;ких целей предп = 88;иятия”.<o:p></o:p> = Принцип 3 = - Вовлечение персонала. “Люди составляют = 89;ущность предприятиn= 3; на всех уровнях, и их полноценноk= 7; участие в деятельносm= 0;и способствуk= 7;т применению их способностk= 7;й на благо цел= 077;й предприятиn= 3;”.<o:p></o:p> = Принцип 4 = - Процессный подход. “Желаемый результат д = 86;стигается более эффек = 90;ивно, когда требуемые ресурсы и деятельносm= 0;ь специалистl= 6;в предприятиn= 3; управляютсn= 3; как единый связанный п = 88;оцесс”.<o:p></o:p> П= 088;инцип 5 - Системный подход к администраm= 0;ивному управлению. “Выявление = 80; понимание задач и администраm= 0;ивное управление системой вз = 72;имосвязанн&#= 1099;х процессов для заданно = 81; стратегичеl= 9;кой цели, повыша= 077;т эффективноl= 9;ть и результатиk= 4;ность предприятиn= 3;”.<o:p></o:p> П= 088;инцип 6 - Постоянное усовершенсm= 0;вование. “Непрерывнl= 6;е усовершенсm= 0;вование процессов и = 087;овышение качества продукции должно быть постоянной стратегичеl= 9;кой целью предприятиn= 3; и его специа= 083;истов”.<o:p></o:p> = Принцип 7 -</span= > Подх= ;од к принятию решений основанный на фактах. “Эффе= ;ктивные решения должны базироватьl= 9;я на анализе только реальных да = 85;ных и достоверн = 86;й информации̶= 1;.<o:p></o:p> П= 088;инцип 8 - Взаимовыгоk= 6;ные отношения с поставщикаl= 4;и. “Предприятl= 0;е-пользоват&#= 1077;ль и его поставщики- = 88;азработчик&#= 1080; взаимозавиl= 9;имы, и взаимовыг = 86;дные отношения между ними повышают способностn= 0; обоих производитn= 0; качественнm= 1;ю продукцию”.<o:p= ></o:p> В стандарте ISO 15504 каждый из пр= 080;веденных принципов прокомментl= 0;рован комплексом действий, необходимыm= 3; для их реали= 079;ации в проектах. Выполнение этих принци = 87;ов способствуk= 7;т повышению управленчеl= 9;кой культуры, применению системы адмl= 0;нистративн= 086;го управления качеством в = 86; всех видах деятельносm= 0;и предприятиl= 1; и, как следствие, обеспечениn= 2; высокого качества и конкурентоl= 9;пособности создаваемоl= 1; проду= ;кции, проектов и систем. Эти принципы рекомендуеm= 0;ся применять при:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>ф = 86;рмулировке политики и стратегии обеспеченl= 0;я всего ЖЦ ПС;<o:p></o:= p> <![if !supportLists]>- &nb= sp; <![endif]>выборе целей проекта, требований = 80; характерисm= 0;ик качества ПС, непосредстk= 4;енно связанных с потребностn= 3;ми и ожиданиям = 80; заказчиков = 80; потребителk= 7;й;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>управлени= 080; операциями = 74; процессе реализации проекта и дл= 103; удовлетворk= 7;ния требований заказчика и потре= ;бителей;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>управлени= 080; людскими ресурсами предприятиn= 3; для обеспеч = 77;ния ЖЦ ПС и его качества.<o:p></o:p>= Оп= ;исание процессов ЖЦ ПС в СММ сфокус= 080;ровано на поэтапно = 84; определениl= 0; реально достигаемыm= 3; результатоk= 4; и на оценивании качества их выполнения. Качество п = 88;оцессов зависит от технологичk= 7;ской среды, в которой они выполняютсn= 3;. Зрелость процессов = - это степень их управляемоl= 9;ти, возможностn= 0; поэтапной количествеl= 5;ной оценки каче = 89;тва, контр= ;олируемост= 00; и эффективноl= 9;ть результатоk= 4;. Модель зрелости предприятиn= 3; представляk= 7;т собой методическl= 0;й нормативныl= 1; документ, определяющl= 0;й правила соз = 76;ания и функциони = 88;ования системы управления жизненным ц = 80;клом ПС, методы постепенноk= 5;о повышения культуры и качества производстk= 4;а. Рост зрелости обеспечиваk= 7;т потенциальl= 5;ую возможностn= 0; возрастаниn= 3; эффективноl= 9;ти и согласованl= 5;ости использоваl= 5;ия процессов создания, сопровождеl= 5;ия и оценивани= 03; качества ко = 84;понентов и ПС в целом. Реальное и = 89;пользовани&#= 1077; регламентиl= 8;ованных процессов предполагаk= 7;т их документирl= 6;вание и поэтапный контроль характерисm= 0;ик качества ПС. На предприятиn= 3;х, достигших высокого уровня зрелости, формализовk= 2;нные процессы ЖЦ ПС должны принимать статус стандарта, ф= 080;ксироватьс&= #1103; в организациl= 6;нных структурах = 80; определять производстk= 4;енную тактику и ст= 088;атегию корпоративl= 5;ой культуры производстk= 4;а и системы обеспечениn= 3; качества программноk= 5;о продукта. <o:p></o:p></span= > = В современныm= 3; автоматизиl= 8;ованных технологияm= 3; программноl= 1; инженерии, создания и <sp= an class=3DGramE>совершенl= 9;твования сложных ПС, с позиции обеспечениn= 3; их качества можно выделить методы и средства, позволяющиk= 7;:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здавать программныk= 7; модули и функционалn= 0;ные компоненты высокого, га= 088;антированн&= #1086;го качества;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>п = 88;едотвращат&#= 1100; дефекты проектировk= 2;ния за счет систем обес = 87;ечения качества, эффективныm= 3; технологий = 80; инструментk= 2;льных средств автоматизаm= 4;ии всего жизненного цикла компл = 77;ксов программ и баз данных;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>о = 73;наруживать и устранять различные дефекты и ошибки прое = 82;тирования, разработки = 80; сопровождеl= 5;ия программ путем вериф = 80;кации и системати = 95;еского тестированl= 0;я на всех этапах жизненного цикла ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 76;остоверять достигнутыk= 7; значения качества функциониl= 8;ования программныm= 3; продуктов в процессе их = 080;спытаний и сертификацl= 0;и перед передачей в = 088;егулярную эксплуатацl= 0;ю пользоватеl= 3;ям.<o:p></o:p> = Комплекснl= 6;е, скоординирl= 6;ванное применение этих методо = 74; и средстk= 4; в процессе создания, развития и применения ПС позволяе = 90; исключать многие виды дефектов ил = 80; значительнl= 6; ослаблять и = 93; влияние. Тем самым уровень дос = 90;игаемого качества пр = 86;граммных продуктов становится предсказуеl= 4;ым и управляем = 99;м, непосредстk= 4;енно зависящим о = 90; ресурсов, выделяемых на его достижение, = 072; главное, от системы качества и эффективноl= 9;ти технологии, используемm= 9;х на всех этапах жизн = 77;нного цикла ПС. Эти ресурсы требуются н = 72; технологичk= 7;ские средства в Ж= 062; ПС:<o:p></o:p> <![= if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>нпри&= #1086;бретение</span= > или создани = 77; технологии = 80; инструментk= 2;льных средств, при= 084;еняемых для обеспеч = 77;ния требуемого качества всего жизненного цикла ПС;<o:p></o:p></span= > <![= if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>на эксплуатацl= 0;ю и непосредстk= 4;енное применение технологии = 74; процессе обеспечениn= 3; ЖЦ ПС;<o:p></o:p> <![= if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>на создание технологии = 80; инструментk= 2;льных средств для испытаний и оценивания характериl= 9;тик качества программноk= 5;о средства;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>на выполнение измерений достигнутыm= 3; значений характерисm= 0;ик качества ПС.</s= pan><o:p></o:p> Улучшен= ;ие технико-эко = 85;омических показателеl= 1; создания ПС, а также предотвращk= 7;ние ошибок и дефектов обеспечиваk= 7;тся применениеl= 4; современны&#= 1093; технологий программноl= 1; инженерии и систем автоматизиl= 8;ованного проектировk= 2;ния. Они представляn= 2;т собой высокопроиk= 9;водительны= 077;, ресурсосбеl= 8;егающие технологии создания комплексов программ вы = 89;окого качества и надежности, имеют целью = 089;окращение общих затра = 90; на проектир = 86;вание, реализацию, сопровождеl= 5;ие и совершенстk= 4;ование ПС. Для этого, прежде всег = 86;, необходимо применять методы и средства си = 89;темного анализа и проектировk= 2;ния, обеспечиваn= 2;щие конкретизаm= 4;ию и максимальнl= 6; точное представлеl= 5;ие целей, назначения = 80; функций с начала ЖЦ ПС и предотвращk= 2;ющие распростраl= 5;ение возможных системных д = 77;фектов на последую = 97;ие этапы разработки. Такие технологии программноl= 1; инженерии позволяют исключать или значительнl= 6; снижать уровень сис = 90;емных, алгоритмичk= 7;ских и программныm= 3; ошибок в программныm= 3; продуктах, передаваемm= 9;х на эксплуатацl= 0;ю. Кроме того, они эффективны при модификациl= 0; и сопровожд = 77;нии ПС, а также при изменении конфигурацl= 0;и внешней среды. <o:p></o:p> Для обнаружениn= 3;, устранения = 86;шибок и дефектов все этапы ра= 079;работки и сопровожд = 77;ния ПС должны быть поддержаны методами и средствами верификациl= 0;, а также сист= 077;матическог&= #1086;, автоматизиl= 8;ованного тестированl= 0;я корректносm= 0;и реализованl= 5;ых решений. На этапах разработки ПС целесооб = 88;азно применять различные методы, эталоны и виды тестир = 86;вания, каждый из которых ориентировk= 2;н на обнаруже = 85;ие, локализациn= 2; или диагностикm= 1; определеннm= 9;х типов дефектов. Непредсказm= 1;емость конкретных дефектов и ошибок в про= 075;раммах приводит к целесообраk= 9;ности последоватk= 7;льного, методичногl= 6; анализа возможностl= 0; проявления любого типа = 086;шибок и их исключе= 085;ия на наиболее ранних этапах разработки при минимал= 00;ных затратах. Дл= 103; тестированl= 0;я необходимы достаточно полные эталоны, такие как совокупносm= 0;ь требований техническоk= 5;о задания и по= 101;тапная их декомпозицl= 0;я в спецификацl= 0;ях. Существеннk= 2;я особенностn= 0; тестированl= 0;я сложных ПС с= 086;стоит в потребностl= 0; их проверки при огранич = 77;нной длительносm= 0;и испытаний. Для этого це= 083;есообразно тщательное планированl= 0;е тестированl= 0;я с учетом все= 093; результатоk= 4;, полученных на этапах жизненного цикла. При планированl= 0;и основная задача состоит в достижении максимальнl= 6;й достоверноl= 9;ти испытаний и определениn= 3; качества ПС при огранич = 77;нии допустимых затрат ресурсов.<o:p></o:p>= Пр = 80; применении импортных компонентоk= 4; системное проектировk= 2;ние и обеспечениk= 7; качества программныm= 3; продуктов следу = 77;т учитывать, что, в принципе, в них возможн = 99; как злоумышленl= 5;ые, так и случай= 085;ые, непредумышl= 3;енные дефекты вычислителn= 0;ного процесса, пр= 086;грамм и данных, отражающиеl= 9;я на качестве = 080;х функционирl= 6;вания. Зл= оумышленныk= 7; вирусы= и/или “закладки”, хотя l= 0; маловероятl= 5;ы, в серийных, широк= ;о тиражируемm= 9;х в мире программныm= 3; продуктах, однако треб = 91;ются особые методы и средства дл= 03; целенаправl= 3;енного их обнаружениn= 3; и устранени= 03;. Зарубежным специалистk= 2;м свойственнl= 6; ошибаться, так же, как и отечественl= 5;ым, однако боле = 77; высокое кач = 77;ство используемm= 9;х технологий разработки = 80; современнаn= 3; проектировl= 6;чная культура позволяют значительнl= 6; снижать уровень случайных дефектов в программныm= 3; продуктах, поступающиm= 3; на рынок. Однак= 086; в любых сложных импортных П = 57; всегда не гарантировk= 2;но полное, абсо= 083;ютное отсутствие случайных ошибок и дефектов, которые могут быть в= 072;жнейшими дестабилизl= 0;рующими факторами проектов. Их применение = 74; критически&= #1093; отечественl= 5;ых системах тр = 77;бует соответствm= 1;ющего дополнителn= 0;ного контроля качества и специальныm= 3; работ по обе= 089;печению надежности = 80; безопасносm= 0;и при проектировk= 2;нии и эксплуата = 94;ии.<o:p></o:p> Комплек= ;сирование готовых импортных П = 57; и компонент = 86;в при проекти = 88;овании конкретной отечественl= 5;ой системы создает усл = 86;вия их функцион = 80;рования не всегда адекватные предусмотрk= 7;нным разработчиl= 2;ами и проверенныl= 4; при испытан = 80;ях, хотя, может быть, и не выходящие з = 72; пределы требований эксплуатацl= 0;онной документацl= 0;и. Это способствуk= 7;т проявлению ранее скрытых дефектов и ошибок, и выз&#= 1099;вает необходимоl= 9;ть их устранен = 80;я. Для этого ответственl= 5;ые и квалифици = 88;ованные поставщики зарубежных программныm= 3; продуктов имеют служб = 99; сопровождеl= 5;ия, регистрациl= 0; и накоплени= 03; претензий пользоватеl= 3;ей и быстрого реагированl= 0;я для устране = 85;ия реальных дефектов функционирl= 6;вания. Легальная закупка и использоваl= 5;ие лицензионнl= 6; чистых программныm= 3; продуктов, о= 073;еспеченных сопровождеl= 5;ием фирмы-поста = 74;щика, позволяет в значительнl= 6;й степени сни = 78;ать влияние на качество функционирl= 6;вания ПС дефектов, не предотвращk= 7;нных в процессе и= 093; создания.<o:p></o:p>= Состояние экономики и промышленнl= 6;сти страны все больше зави = 89;ит от качества сложных информациоl= 5;ных систем и их важнейшей, интеллектуk= 2;льной части – программныm= 3; продуктов, применяемыm= 3; для управле = 85;ия в экономике, социальной сфере, системах вооружения = 80; других областях. В связи с этим стратегичеl= 9;кой задачей стало обеспечениk= 7; высокого ка = 95;ества отечественl= 5;ых программныm= 3; продуктов при их массовой разработке = 80; поставке дл= 03; различных сфер примен = 77;ния в стране и на мировом рынке. Для конкурентоl= 9;пособности в мире сложных программныm= 3; продуктов и возl= 4;ожности их успешног = 86; экспорта он = 80; должны быть = 089;ертифициро&= #1074;аны и соответствl= 6;вать требованияl= 4; международl= 5;ых стандартов. <o:= p></o:p> Для удостовереl= 5;ия качества, надежности = 80; безопаснос&= #1090;и применения сложных, кри= 090;ических систем, используемm= 9;е в них програ= 084;мные продукты, следует подвергать сертификацl= 0;и аттестованl= 5;ыми, проблемно-о = 88;иентирован&#= 1085;ыми испытательl= 5;ыми центрами (см. лекцию 18). Такие испыт = 72;ния необходимо проводить, когда прогр = 72;ммы управляют сложными процессами или обрабатываn= 2;т столь важну= 02; информацию, что дефекты = 074; них или недо= 089;таточное качество могут нанести зна = 95;ительный ущерб. Серти= 092;икационные испытания должны устанавливk= 2;ть соответствl= 0;е комплексов программ документацl= 0;и и допускать их к эксплуатацl= 0;и в пределах и= 079;менения параметров внешней среды, иссле= 076;ованных при проведе = 85;ных проверках. Эти виды исп= 099;таний характеризm= 1;ются наибольшей строгостью = 80; глубиной проверок и должны проводитьсn= 3; специалистk= 2;ми, независимыl= 4;и от разработ = 95;иков и от заказчиков (пользовате = 83;ей). <o:p></o:p> Основой сертификацl= 0;и должны быть детальные и эффективныk= 7; Программы и методики испытаний комплексов программ на соответствl= 0;е требованияl= 4; заказчиков, специально разработанl= 5;ые тестовые задачи и ген= 077;раторы для их формированl= 0;я, а также высо= 082;ая квалификац= ия и авторитет испытателеl= 1;. Применение на предприя = 90;иях-разрабо&= #1090;чиках программныm= 3; продуктов, сертифицирl= 6;ванных систем качества и профилей международl= 5;ых стандартов на базе требований </sp= an>IS= O 9001:2000 и/или= ; CM= MI:2003, гарантируеm= 0; высокое, устойчивое управление качеством процессов и продуктов и = 93; жизненного цикла, а также позво = 83;яет во многих случаях обл = 77;гчать сертификацl= 0;ю конечного программноk= 5;о продукта. Поэтому зак = 72;зчики сложных программныm= 3; проектов должны выбирать подрядчикоk= 4;-исполнител&#= 1077;й, имеющих сертификатm= 9;, удостоверяn= 2;щие применение ими систем гарантировk= 2;ния качества на основе адаптироваl= 5;ных профилей международl= 5;ых стандартов. <o:= p></o:p> Пробелы в обучении методам про = 75;раммной инженерии оставляют широкое пол = 77; для произвола специалистl= 6;в при оценивании = 82;ачества их труда, а та&= #1082;же для появления многочислеl= 5;ных дефектов и ошибок в про= 077;ктах ПС. Возрастанl= 0;е сложности = 80; ответственl= 5;ости современныm= 3; задач, решаемых программамl= 0;, а также возможного ущерба от недостаточl= 5;ого качества их результатоk= 4;, значительнl= 6; повысило актуальносm= 0;ь освоения ме = 90;одов полного, стандартизl= 0;рованного описания требований = 82; характерисm= 0;икам качества и способов из = 84;ерения их реальных значений на различных э = 90;апах ЖЦ ПС. Резко возросла необх= ;одимость знаний специалистk= 2;ми понятий, определениl= 1; и способов оценивания = 93;арактерист&#= 1080;к качества пр = 86;граммных продуктов.<o:p></o:p>= Многие отечественl= 5;ые специалистm= 9; в области программныm= 3; средств привыкли видеть в стандартах рутину, сковывающуn= 2; их “творчес = 90;во”. Быстрое усложнение = 80; рост размеров ко = 84;плексов программ приводит к созданию крупных программисm= 0;ских коллективоk= 4; с профессионk= 2;льным разделениеl= 4; труда, в кото&#= 1088;ых необходимо регламентиl= 8;ование координироk= 4;анной деятельносm= 0;и групп специ = 72;листов над единым проектом. Обещания разработчиl= 2;ов в контракта = 93; с заказчика = 84;и создать высококачеl= 9;твенные программы в = 089;огласованн&= #1099;е сроки во многих случаях не в= 099;полняются, как вследствие различий в понимании ими требуем = 86;го качества, та= 082; и вследстви = 77; неумения оц = 77;нить ресурсы, необходимыm= 3; для достижения = 74;ысокого качества программ. В результате = 82;ачество программноl= 1; продукции зачастую ос = 90;ается низким, неподдающиl= 4;ся достоверноl= 1; оценке и не конкурентоl= 9;пособным на международl= 5;ом рынке. Поэтому важнейшей п = 88;облемой развития и применения современныm= 3; систем, является обучение и воспитание специалистl= 6;в в области пр= 086;граммной инженерии, и= 089;пользовани&= #1102; международl= 5;ых стандартов, = 089;пособствую&= #1097;их высокому ка = 95;еству ПС и достове= 088;ному его оцениванию. Необходимо их обучение умению формализовk= 2;ть требования = 80; достигать конкретные значения ха = 88;актеристик качества функционирl= 6;вания и применени= 03; сложных комплексов программ, с учетом тех ресурсов, которые нуж = 85;ы и доступны для обеспечениn= 3; и совершенстk= 4;ования этого качес = 90;ва. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102449"></a><a name=3D"_Toc508102222">Л&= #1077;кция 2. Профили стандартов = 78;изненного цикла систе = 84; и пр&= #1086;граммных сре</a>дств в программной инженерии</spa= n><o:p></o:p></h1> <o:p> </o:p> <h1><a name=3D"_Toc508102450"></a><a name=3D"_Toc508102223">2.1. Назначение профилей стандартов жизненного цикла в прогр= аммной инженерии</spa= n></a> <o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n><o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При создании и сопровождеl= 5;ии сложных, распределеl= 5;ных, тиражируемm= 9;х ПС требуетс= 03; гибкое формированl= 0;е и применени = 77; гармонизирl= 6;ванных совокупносm= 0;ей базовых стандартов и нор= мативных документов разного уровня, выделение в них требова = 85;ий и рекоменда = 94;ий, необх= ;одимых для эффективноl= 1; реализации конкретных функций систем. Для унификациl= 0; и регламентиl= 8;ования реализации этих функци = 81;, совокупносm= 0;и базовых стандартов должны адаптироваm= 0;ься и конкретизиl= 8;оваться в программн = 86;й инженерии п = 88;именительн&#= 1086; к определеннm= 9;м классам про = 77;ктов, их функций, процессов и компонентоk= 4;. В связи с эти&#= 1084; выделилось = 80; сформироваl= 3;ось понятие "профиля стандартов"= ;, как основного инструментk= 2; функционалn= 0;ной стандартизk= 2;ции.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> <sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal;mso-bidi-font-styl= e: italic'>Профиль стандартов</spa= n> <span style=3D'font-size:14.0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font= -family: "MS Mincho";mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"T= imes New Roman"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > это совокупносm= 0;ь нескольких (или подмнож= 077;ство одного) базовых станд= ;артов (и других нормативныm= 3; документов) = 089; четко определеннm= 9;ми и гармонизи = 88;ованными подмножесm= 0;вами обязательl= 5;ых и факультатиk= 4;ных возможностk= 7;й, предназнаm= 5;енная для реализа = 94;ии заданной функции или группы функ = 94;ий. Функционаl= 3;ьная характерисm= 0;ика (заданный набор функций) объекта стандартизk= 2;ции является ис = 93;одной для формированl= 0;я и применени= 03; профиля этого объекта или процесса. В профиле выд = 77;ляются и устанавливk= 2;ются допустимые факультатиk= 4;ные возможностl= 0; и значения парам= ;етров каждого ба = 79;ового стандарта и/или нормативнl= 6;го докум= ;ента, входящего = 74; профиль. Профиль не может противоречl= 0;ть использоваl= 5;ным в нем базовым стандартаl= 4; и нормативн = 99;м документам. Он должен использоваm= 0;ь факул= ;ьтативные возможносm= 0;и и значения параметроk= 4; в пределах допустимых, выбранные и = 79; альтернатиk= 4;ных вариантов. На базе одной и той же совокупносm= 0;и базовых станд= ;артов могут= ; формироваm= 0;ься и утверждатьl= 9;я различные профили для разных проектов и сфер применения. Эти огранич = 77;ния базовых документов профиля и их гармонизацl= 0;я, проведеннаn= 3; разработчиl= 2;ами профиля, дол= 078;ны обеспечиваm= 0;ь качество, совме= ;стимость и корректно = 77; взаимодейсm= 0;вие компонентоk= 4; системы, соответстk= 4;ующих профилю, в заданной области его применения.<o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Основными целями= применениn= 3; профилей стандартов</spa= n> при создании и применении ПС являются:<o:= p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>сни= жение трудоемкосm= 0;и, длительносm= 0;и, стоимости = 80; улучшение других техн = 80;ко-экономич&= #1077;ских показателеl= 1; проектов си = 89;тем и комплексо = 74; программ;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>пов= ышение качества разрабатывk= 2;емых или применя = 77;мых покупных компонентоk= 4; и ПС в целом, при их разра= 073;отке, приобретеl= 5;ии, экспл= ;уатации и сопровождеl= 5;ии;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>обе= спечение расширяемоl= 9;ти ПС по набору прикладных функций и масштабируk= 7;мости в зависимостl= 0; от размерностl= 0; решаемых за = 76;ач;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>под= держка функционалn= 0;ной интеграциl= 0; в системах задач, ранее реша = 74;шихся раздельно;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>обе= спечение переносимоl= 9;ти программ и д= 072;нных между разны = 84;и аппаратно-п = 88;ограммными платформамl= 0;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Состояние и развитие стандартизk= 2;ции в области пр= 086;граммной инженерии х = 72;рактеризуе&#= 1090;ся следующими особенност= ;ями, которые нео = 73;ходимо учитывать при формир= 086;вании и применени = 80; профилей: <o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>нес= колько сотен разработанl= 5;ых международl= 5;ых и национальl= 5;ых стандартов не полностью = 80; неравномерl= 5;о покрывают п = 86;требности в стандарти = 79;ации объектов и п= 088;оцессов создания и применения сложн= ;ых систем, программныm= 3; средств и их компонентоk= 4;;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>бол= ьшая длительносm= 0;ь разработки, согласованl= 0;я и утвержден = 80;я международl= 5;ых и национальнm= 9;х стандартов (3-5 лет) приводи= 090; к их консерватиk= 9;му, а также к хрон= 080;ческому отставанию требованиl= 1; и рекl= 6;мендаций этих документов от современноk= 5;о состояния техники и от текущих потребностk= 7;й практики и технологии создания сложных си = 89;тем;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>ста= ндарты современныm= 3; ПС должн= ;ы: учитывать необходимl= 6;сть их построен = 80;я как открыты = 93; систем; обеспечиваm= 0;ь расширяемоl= 9;ть при наращив = 72;нии или изменении выполняемыm= 3; функций; переносимоl= 9;ть программныm= 3; средств и данных сист = 77;м между разны = 84;и аппаратно-п = 88;ограммными платформамl= 0;; возможностn= 0; взаимодейсm= 0;вия с другими информациl= 6;нными системами той жk= 7; проблемно-о = 88;иентирован&#= 1085;ой сферы;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>наи= более сложные и творческие процессы создания и р= 072;звития крупных рас = 87;ределенных ПС (системный анализ и проектироk= 4;ание, интеграция компонентl= 6;в и систем, испытания = 80; сертификацl= 0;я) почти не поддержаны требованияl= 4;и и рекоменда = 94;иями стандартов, вследствие трудности и = 93; формализацl= 0;и, унификации = 80; разнообразl= 0;я содержания;<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>чем сложнее объекты ил = 80; процессы, подлежащиk= 7; стандартизk= 2;ции, тем больше необходимо использоваm= 0;ь и формулиро = 74;ать предваритеl= 3;ьных услов= ;ий, учитываемm= 9;х в требо= ;ваниях и рекомендацl= 0;ях стандарта, которые следует адаптироваm= 0;ь и конкретиз = 80;ровать для корректногl= 6; их применен = 80;я в определен = 85;ом проекте;<o:p></o:p> <![if !supportList= s]>-<![endif]>- пробелы и задержки в подготовке = 80; издании стандартов высокого ранга и текущая по= 090;ребность унификации = 80; регламентиl= 8;ования современныm= 3; объектов и процессов в области программноl= 1; инженерии приводят к созда= ;нию и практическl= 6;му применению многочислеl= 5;ных нормативныm= 3; и методическl= 0;х документов отраслевогl= 6;, ведомственl= 5;ого или фирменн = 86;го уровня.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При практическl= 6;м форми= ;ровании и применениl= 0; профилей ПС = 074; ряде случае = 74;, возможно, испол= ;ьзовать национальl= 5;ые стандарты, станд= ;арты де-факто и ведомственl= 5;ые нормативныk= 7; документы. Это может быть обусловленl= 6; отставаниеl= 4; в разработк = 77; некоторых задач в междунаро = 76;ных стандартах или необходимоl= 9;тью учета конкр = 77;тных особенностk= 7;й систем. При применении стандартов = 80; профилей могут быть выявлены пробелы в положениях некоторых стандартов = 80; необходимоl= 9;ть модификациl= 0; или дополнения требований, определенl= 5;ых в них. Некоторые функции, не формализовk= 2;нные стандартамl= 0;, но важные дл= 103; унификации = 87;остроения или взаимодейсm= 0;вия компонентl= 6;в могут= определятn= 0;ся норма= ;тивными документаl= 4;и ведомства и = 83;и предприятиn= 3;, обязательнm= 9;ми для конкрет = 85;ого профиля и проекта.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Применениk= 7; стандартизl= 0;рованных профилей позволяет заказчику системы освободитn= 0;ся от заk= 4;исимости от одного поставщика программныm= 3; или аппарат = 85;ых средств за счет выбора этих средств из числа доступных н = 72; рынке и соответствm= 1;ющих стандартам, = 085;ормативным требованияl= 4; и рекомендацl= 0;ям профи= ;ля. Применение профи= ;лей, относящихсn= 3; к программныl= 4; комплексам (функционал= 00;ным частям систем), облег= ;чает повторное использоваl= 5;ие в проектируk= 7;мой системе уже разработанl= 5;ых и проверенн = 99;х программныm= 3; компонентоk= 4;. Профили ПС у= 085;ифицируют и регламент = 80;руют только част= 00; требований = 80; характерисm= 0;ик объектов и п= 088;оцессов, выделенных = 80; формализовk= 2;нных на базе стандартоk= 4; и норма= ;тивных документов. Другая часть функционалn= 0;ных и техническиm= 3; характерисm= 0;ик систем определяетl= 9;я заказчикамl= 0; и разработчl= 0;ками творчески, без учета положений нормативныm= 3; документов.<o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = Профиль стандартов ЖЦ ПС (функционал= 00;ных частей сист = 77;мы) должен= определятn= 0; архит= ;ектуру программнl= 6;го комплекса (м= 086;дели функций, логич= ;еские модели данных, внешние интерфейсm= 9;) и их стl= 8;уктуру (разбиение системы на подсистемы = 80; систем на мо= 076;ули, определениk= 7; унифициров&#= 1072;нных интерфейсоk= 4; взаимодейсm= 0;вия между компл = 77;ксами программ и и= 093; компонентаl= 4;и). Жизненный цикл програ = 84;мных средств отр = 72;жается в профиле стандартов набором: проце= ;ссов, этапов, частных работ и операций в п= 086;следовател&= #1100;ности их выполнения = 80; взаимосвязl= 0;, регламентl= 0;рующим ведение разработки, = 089;опровожден&= #1080;е и эксплуатацl= 0;ю, от анk= 2;лиза и подготовк = 80; требований до завершения испытаний ряда версий программноk= 5;о продукта и п= 088;екращения их использоваl= 5;ия. Жизне= ;нный цикл вкл</spa= n>ючает описания исходной информации, = 089;пособов и методов выполнения операций и работ, устанавливk= 2;ет требования = 82; результатаl= 4; и правилам их ко= нтроля, а также= ; опред= ;еляет содержание технологичk= 7;ских и эксплуата = 94;ионных документов. Он определяет = 86;рганизацио&#= 1085;ную структуру к = 86;ллектива специалистl= 6;в, регла= ментирует распределеl= 5;ие и планирова = 85;ие работ, а также = 82;онтроль за ходом разработки. = 055;овышение эффективноl= 9;ти разработки, качества программноk= 5;о продукта и производитk= 7;льности труда специалистl= 6;в дост = 80;гается за счет: <o:p></o:p>= <![if !supp= ortLists]>-&nb= sp; <![endif]>рег= ламентации организацl= 0;и и порядка проведениn= 3; работ;<o:p></o:p> <![if !supp= ortLists]>-&nb= sp; <![endif]>авт= оматизации этапов и операций;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>рац= ионального разделения труда между специалистk= 2;ми разной ква = 83;ификации и проблемно = 81; ориентации. <o:= p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Профиль ЖЦ ПС конкретной системы должен учитывать е= 05; функционалn= 0;ную ориентацию. Он должен содержать ссылки на стандартиk= 9;ированные интерфейсm= 9; между комплексоl= 4; программ и внешней сре = 76;ой, которые описываютсn= 3; в профилях среды систе = 84;ы. Каждый профиль и его параметры для примене = 85;ия в конкретно = 84; проекте системы необходимо = ;поэтапно адаптироваm= 0;ь и детализир = 86;вать в соответствl= 0;и с этапом про= 077;кта. Особенностl= 0; организациl= 6;нных структур, различия в размерах и сложности проектов, в требованияm= 3; к системам и применяемыl= 4; методам их разработки, необходимl= 6;сть преемственl= 5;ости с системами, находящимиl= 9;я в эксплуатацl= 0;и, влияют на организациn= 2; разра= ;ботки, приобретенl= 0;я, применениn= 3; и сопровожд = 77;ния программныm= 3; средств. Каждый из вы= 076;еленных профилей должен для последующеk= 5;о длительногl= 6; использоваl= 5;ия пройти стад = 80;ю формированl= 0;я, адаптации и параметризk= 2;ции применителn= 0;но к характери = 89;тикам стандартизl= 0;руемых объектов ил = 80; процессов.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Для корректногl= 6; применения<s= pan style=3D'mso-spacerun:yes'> &#= 1086;писания профилей стандартов должны соде = 88;жать:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>опр= еделение целей, которые предполагаk= 7;тся достичь применениеl= 4; данного профиля стандартов;<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>пер= ечисление функций продукта ил = 80; процесса стандартизk= 2;ции, определяемl= 6;го данным профилем;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>фор= мализованнm= 9;е сценарии применения базовых станд= ;артов и спеm= 4;ификаций, включенных = 74; данный профиль;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>сво= дку требований = 82; системе или&nbs= p; к её компонентk= 2;м, опред= ;еляющих их соответстk= 4;ие профилю и требований = 82; методам тес = 90;ирования соответствl= 0;я;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>ссы= лки на конкретный набор станд = 72;ртов и других нормативныm= 3; документов, составляющl= 0;х профиль, с то&#= 1095;ным указанием используемm= 9;х положений, редакций и ограничениl= 1;, способных оказать влияние на достижение = 82;орректного взаимодейсm= 0;вия объектов стандартизk= 2;ции при использ = 86;вании данного профиля;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>инф= ормационныk= 7; ссылки на спецификацl= 0;и тестов проверки соответствl= 0;я профилю.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> В зависимостl= 0; от области р= 072;спростране&= #1085;ия профилей он = 80; могут иметь = 088;азные статусm= 9; утверждениn= 3;:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>про= фили конкретной системы, определяюm= 7;ие стандартиk= 9;ированные проектные решения в пределах данного проекта и яв= 083;яющиеся частью прое = 82;тной документацl= 0;и;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>про= фили, предназнаm= 5;енные для решения некоторого класса прикладных = 79;адач, которые распростраl= 5;яются на все системы и П= 057; данно= ;го класса в пределах пр = 77;дприятия или отрасли = 080; утверждаютl= 9;я как стандар = 90;ы предприятиl= 1;, ведомствеl= 5;ные или государ = 89;твенные стандарты.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Особенносm= 0;и организациl= 6;нных структур, различия в размерах и сложности п = 88;оектов, требо= ;ваниях к системам и применяемыl= 4; методам их разработки, необходимl= 6;сть преемственl= 5;ости с системами, находящимиl= 9;я в эксплуатацl= 0;и, влияют на о= 088;ганизацию разработкl= 0;, приобретенl= 0;я, приме= ;нения и сопровождеl= 5;ия аппаратных = 80; программныm= 3; средств. Для эффективн = 86;го применения конкретногl= 6; профиля необходимо</spa= n>:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>выд= елить объединеннm= 9;е единой логическоl= 1; связью пробл= ;емно-ориент= 080;рованные области функционирl= 6;вания систем, где м&#= 1086;гут использоваm= 0;ься стандарты, общие для од= 085;ой организациl= 0; или группы предприятиl= 1;;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>иде= нтифицировk= 2;ть стандарты и нормативныk= 7; документы, варианты их применения = 80; параметры, которые необходимо включить в п= 088;офиль стандартов;<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>док= ументально зафиксировk= 2;ть участ= ;ки конкретноk= 5;о профи= ;ля, где требуется создание новых станд = 72;ртов или нормативныm= 3; документов, = 080; идентифициl= 8;овать характерисm= 0;ики, которые могут оказаться важными для разработки недостающиm= 3; стандартов = 80; нормативныm= 3; документов этого профиля;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>фор= мализовать профиль в соотв= ;етствии с его катег= ;орией, включая стандарты, различные варианты нормативныm= 3; документов и допl= 6;лнительные параметры, которые непосредстk= 4;енно связаны с профилем;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>опу= бликовать профиль и/или продв= ;игать его по фоl= 8;мальным инстанциям для дальнейшегl= 6; распростраl= 5;ения на предприятиl= 0; или в отрасл= 080;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> <o:p></o:p></spa= n> <h1><a name=3D"_Toc508102451"></a><a name=3D"_Toc508102224">2.2. Жизненный цикл профилей ст = 72;ндартов систем и = &nb= sp; = программнm= 9;х средств</a> <o:p></o:p></h1> </spa= n><o:p></o:p> </spa= n>Пр = 86;филь стандартов конкретной системы не является статичным, он развиваетсn= 3; и конкретизиl= 8;уется (возможно, во<s= pan style=3D'mso-spacerun:yes'> взаим= ;одействии с заказчико = 84;) в процессе жизненного цикла и оформляетсn= 3; в составе до= 082;ументации системы. Разработкk= 2; и применение профилей стандартов являются орган= 080;ческой частью процессов жизненного цикла, разработки = 80; развития систем. Проектировk= 2;нию системы предшествуk= 7;т обследованl= 0;е объекта автоматизаm= 4;ии, результатl= 6;м которой являются ег = 86; функционалn= 0;ная и информациl= 6;нная модели, определениk= 7; целей создания системы и состава ее функций. Стандарты, важные с точки зрени= 03; заказчика, должны= задаватьсn= 3; в спецификацl= 0;и требований на проектир = 86;вание системы и составлять её пе= 088;вичный профиль. То, чт = 86; не задано в требованияm= 3; заказчика, остается первоначалn= 0;но на усмотрение = 88;азработчик&#= 1072; системы, который, руководствm= 1;ясь требованияl= 4;и спецификацl= 0;й, может допол = 85;ять и развивать профили, которые согласуютсn= 3; с заказчико = 84;. В профиль ко= 085;кретной системы включаются специ= ;фикации стандартиk= 9;ации компонентоk= 4;, разра= ;ботанных в составе данно= ;го проекта, и спецификацl= 0;и использоваl= 5;ных готовых программныm= 3; и аппаратны = 93; средств, если эти средств = 72; не специфиц = 80;рованы соответствm= 1;ющими стандартамl= 0;. После завершения проектировk= 2;ния и испытаний системы, в ходе которы = 93; проверяетсn= 3; ее соответс = 90;вие профилю, профиль применяетl= 9;я как основно = 81; инстр= 091;мент сопровождеl= 5;ия системы при эксплуатацl= 0;и, модернизацl= 0;и и управлени = 80; конфигурацl= 0;ей.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Целесообрk= 2;зно рассматривk= 2;ть &#= 1076;ве группы профилей систем (рис. 2.1):<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>функциl= 6;нальные профили, регламентиl= 8;ующие архитектурm= 1; и структуру объектов системы и ее компонентоk= 4;; функции, интер= ;фейсы и протоколы взаимодейсm= 0;вия, форматы данных;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>технолl= 6;гические профили, регламен= ;тирующие процессы п = 88;оектирован&#= 1080;я, разработкl= 0;, применения, сопровождеl= 5;ия и развития систем и их компонентоk= 4;. <o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Н= 072; этапах жизненного цикла систе = 84;ы выбираются = 80; затем приме = 85;яются общесистемl= 5;ые функционалn= 0;ные профили:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>про= филь жизненногl= 6; цикла информациоl= 5;ной системы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>про= филь аппаратной = 80; операционнl= 6;й среды систе = 84;ы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>про= филь внешней и пользоватеl= 3;ьской среды функционирl= 6;вания ПС;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>про= филь обеспечениn= 3; безопасносm= 0;и функционирl= 6;вания и защиты инф= 086;рмации в системе;<o:p></o:p></span= > <![if !sup= portLists]>-&nb= sp; <![endif]>про= филь инструментk= 2;льных средств, подде= ;рживающих весь жизнен = 85;ый цикл системы.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При применении функционалn= 0;ных профилей системы следует иметь в виду согласоваl= 5;ие (гармонизац = 80;ю) этих профилей ме = 78;ду собой. Необходимl= 6;сть такого согласоваl= 5;ия возникает, в частности, при примене = 85;ии стандартизl= 0;рованных интерфейсоk= 4;, в том числе, и&= #1085;терфейсов ПС и БД со средой их фу= 085;кционирова&= #1085;ия, интерфейсоk= 4; со средствами = 79;ащиты информации. При согласованl= 0;и функционалn= 0;ных профилей возможны также уточн = 77;ния профиля внешней среды системы и профиля инструментk= 2;льных средств соз = 76;ания, сопровождk= 7;ния и развития программныm= 3; средств.<o:p></o:p> Детализацl= 0;я общесисте= 084;ных профилей стандартов</spa= n> производитl= 9;я по мере деко= 084;позиции структуры системы на составляющl= 0;е её компонен = 90;ы. Выбор и применение этих профилей является ор = 75;анической частью процессов проектировk= 2;ния, разработкl= 0;, сопровождеl= 5;ия и развития сложных систем. Их применение включает процессы: <o:p>= </o:p> <![if !supportLis= ts]>- = <![endif]>выб= ор аппаратной = 80; операционнl= 6;й среды систе = 84;ы определеннl= 6;го класса;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>опр= еделение внешней и пользоватеl= 3;ьской среды функционирl= 6;вания и применени= 03; системы;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>под= готовку администраm= 0;ивного управления системой ка = 95;ества;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>выб= ор готовых программныm= 3; и аппаратны = 93; средств, соответстk= 4;ующих функц= ;иям и профилям системы;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>про= ектированиk= 7; и разработк = 72; программныm= 3; средств и ба= 079; данных (функционал= 00;ных частей системы) в соответствl= 0;и с выбранным = 80; профилями, в частности в соответствl= 0;и со стандартамl= 0; на интерфейсm= 9;;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>раз= работка требований = 82; методам тести= ;рования компо= ;нентов системы на соответствl= 0;е функционалn= 0;ным профилям, выбор или разработка тестов соот = 74;етствия;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>тес= тирование компонентоk= 4; системы на соответствl= 0;е профилям ил = 80; проверка сертификатl= 6;в соответствl= 0;я для применяемыm= 3; готовых про = 75;раммных и аппаратны = 93; средств;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ком= плексироваl= 5;ие компонентоk= 4; в создаваем = 86;й системе на основ= ;е последоватk= 7;льного применения профилей и и= 093; квалификацl= 0;онного тестированl= 0;я.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Применениk= 7; функционалn= 0;ных профилей должны поддерживаm= 0;ь основные, &#= 1090;ехнологиче= ские профили (см. рис. 2.1): <o:p>= </o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>жиз= ненного цикла программныm= 3; средств и ба= 079; данных;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>обе= спечения качества программныm= 3; средств и информации баз дk= 2;нных;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>вер= ификации, тестированl= 0;я и сертификацl= 0;и ПС и БД;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>соп= ровождения и управлени= 03; конфигурацl= 0;ей ПС и информа= 094;ией БД;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>док= ументироваl= 5;ия программныm= 3; средств и ин= 092;ормации баз данных.<o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> <sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>Быстро оснащающиk= 7;ся разли= ;чными методами и средствами = 72;втоматизац&#= 1080;и этапы системного анализа, моделироваl= 5;ия и предваритk= 7;льного проектироk= 4;ания не позволяю = 90; стабилизирl= 6;вать основу этих процессов, достаточнуn= 2; для их полно= 081; формализацl= 0;и для любых систем на уровне международl= 5;ых стандартоk= 4;. Поэтому для этих этапо = 74; могут созда = 74;аться и применятьсn= 3; профили ЖЦ П= 057; как проблем = 85;о-ориентиро&= #1074;анные совокупносm= 0;и нормативныm= 3; документов = 80; методическl= 0;х руководств, отражающиk= 7; как наиболе = 77; современныk= 7; методы, так и фрагм= ;енты действующl= 0;х стандартов, в том числе станд = 72;ртов "де-факто". <o:p></o:p>= Отдельные внутренние этапы жизне = 85;ного цикла компонентоk= 4; и комплексо = 74; программ обеспечиваn= 2;тся группами сm= 0;андартов на локальны = 77; процессы, определяющl= 0;е:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>языки и процессы программирl= 6;вания программныm= 3; компонентоk= 4;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>визуализа= ;цию информации для пользоватеl= 3;ей и обеспечениn= 3; управления жизненным циклом ПС;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>защиту информациоl= 5;ных ресурсов от несанкционl= 0;рованных вмешательсm= 0;в и криптографl= 0;и;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>телекомму= ;никацию и взаимодейсm= 0;вие с внешней средой. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Эта группа стандартов непосредстk= 4;енно определяет инструментk= 2;льные средства решения соответствm= 1;ющих задач и в процессах жизненного цикла ПС обычно стабильны, н= 077; изменяются = 80; не раскрыва= 02;тся ниже в профи= 083;ях ЖЦ.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Учитывая динамику формированl= 0;я и применени= 03; профилей жизненного цикла ПС, по мере детали = 79;ации структуры системы и ее<sp= an style=3D'mso-spacerun:yes'> возмо= ;жного развития, образуется </sp= an>жизненный цикл профилей стандартов</spa= n>. Жизненный цикл профилей ПС целесообраk= 9;но рассматривk= 2;ть в составе технологичk= 7;ских работ проекта отд = 77;льно от этапов и работ непос = 88;едственной разработки = 80; эксплуатацl= 0;и самих программныm= 3; средств и ба= 079; данных. Соз = 76;ание и применени = 77; профилей жизненного цикла ПС можно разделить н = 72; два крупны= 093; процесса (рис. 2.2):<o:p></o:p></sp= an> <![if !sup= portLists]>-&nb= sp; <![endif]>разрабl= 6;тка, формироваl= 5;ие и адаптация</sp= an> профилей стандартов ЖЦ ПС для использоваl= 5;ия в конкретно = 84; проекте системы;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>неп= осредственl= 5;ое применk= 7;ние требований = 80; рекомендацl= 0;й каждог&#= 1086; адаптироваl= 5;ного профиля стандартов для регламентиl= 8;ования этапов, работ и документо = 74; проекта ПС.<o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При создании ПС профили стандартов развиваютсn= 3; и детализир = 91;ются параллельнl= 6; с конкретиз = 72;цией проекта. Они должны обеспечиваm= 0;ь соответствm= 1;ющую часть &#= 1090;ехнологиче= ской поддержки разработки комплекса программ нормативныl= 4;и документамl= 0;. Таким образом, жизненный цикл профилей, в некоторой степени, подобен жизненному циклу самих программныm= 3; средств и баз данных. Завершение разработки профилей ст = 72;ндартов системы и оформление результатоk= 4; должно опережать, обеспечиваm= 0;ь и подготавл = 80;вать выполнение соответствm= 1;ющих этапов и работ основ = 85;ого жизненного цикла комплекса п = 88;ограмм. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Процессы жизненного цикла, развития системы и её программныm= 3; компонентоk= 4; должны быть поддержаны </sp= an>этапами развития и приме- нения комп = 83;екта профилей, ко= 090;орые включают:<o:p></o:p>= <![if !supportLis= ts]>- = <![endif]>сис= темный анализ объекта информатизk= 2;ции и создания к= 086;нцепции системы, ког= 076;а производитl= 9;я первичный выбор исходного компл= ;екта стандартов</spa= n>, которым должна соответствl= 6;вать система; выявляется необходимоl= 9;ть разработки = 80; состав дополнителn= 0;ных норма= ;тивных докум= ;ентов; оформляетсn= 3; содержание = 80; параметры комплектов документов предполагаk= 7;мых профилей;<o:p></o:p>= <![if !sup= portLists]>- = <![endif]>про= ектированиk= 7; системы, когда= ; определяюm= 0;ся требования = 82; её архитектуl= 8;е и структуре = 080; соответствk= 7;нно уточн= ;яются положения, параметры и адаптируютl= 9;я стандарты комплекта профилей; &#= 1086;формляются проекты документов</spa= n> и методичесl= 2;их руков= ;одств по применению = 88;абочей версии каждого про = 92;иля стандартов;<o:p= ></o:p> <![if !sup= portLists]>- = <![endif]>раз= работку или приобретеl= 5;ие готовых компонентоk= 4; системы, при этом утk= 4;ерждаются и применяютсn= 3; все положен = 80;я профиля; производиm= 0;ся контроль, тестированl= 0;е и испытания компонентоk= 4; на соответс = 90;вие требованияl= 4; и документа = 84; конкретногl= 6; профиля стандартов;<o:p= ></o:p> <![if !sup= portLists]>- = <![endif]>соп= ровождение, актуализацl= 0;ю и развитие с= 080;стемы, когда анализируюm= 0;ся положения, параметры = 80; результаты адаптации п = 88;именяемой версии= каждого профиля; &#= 1074;ыявляются и устраняютсn= 3; дефекты про = 92;илей;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>модернl= 0;зацию профиля, с &= #1091;четом появления более совершенныm= 3; техническl= 0;х и программныm= 3; средств, а также новых стандартов; при необходимоl= 9;ти осуществляk= 7;тся формированl= 0;е, документирl= 6;вание и внеk= 6;рение новой модифицироk= 4;анной и уточненно = 81; версии соответствm= 1;ющего профиля. <o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> В общем случае= созданию п = 88;офилей жизненного цикла систе = 84;ы, должно предшествl= 6;вать обсле= ;дование объекта информатизk= 2;ции, для которого предполагаk= 7;тся создавать систему. Результатаl= 4;и работ на этом этапе явля= 02;тся функционалn= 0;ная и информаци = 86;нная модели, а также специ = 92;икации требованиl= 1;, котор= ;ые служат в кач= 077;стве исходных данных для проектировk= 2;ния системы и ПС.<s= pan style=3D'mso-spacerun:yes'> Целесообрk= 2;зно, чтобы эти модели= и сп= ецификации требований были выполн = 77;ны с помощью формализовk= 2;нных методов их о= 087;исания, например, с использоваl= 5;ием средств описания мо = 76;елей в известных методологиn= 3;х структурноk= 5;о проек= ;тирования и языков спецификацl= 0;й. В специфl= 0;кации должны быть опреде = 83;ены требовk= 2;ния к жизненном = 91; циклу систе = 84;ы, даны ссылки на действующиk= 7; норма= ;тивные документы = 80; определен = 72; предваритеl= 3;ьная структура профиля стандартов жизненногl= 6; цикла. Следует задать требования = 82; качеству системы и, соответствk= 7;нно, первичный п = 88;офиль обеспечениn= 3; качества комплекса п = 88;ограмм и данных, функционалn= 0;ные требования = 82; системе <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- состав реша = 77;мых задач и ссыл= 082;и на нормативныk= 7; документы, которые рег = 83;аментируют правила и процедуры выполнения функций и операций. <o:p></o:p></span= > На этапе систе= 084;ного анализа при планированl= 0;и профиля тех = 85;ологическо&#= 1081; поддержки разработки ПС следует проанализиl= 8;овать набор базовых меж = 76;ународных станд= ;артов, связанных с регла= ;ментирован = 80;ем особенностk= 7;й сист= ем и программнm= 9;х средс= ;тв. Для поддержки жизненного цикла разрабатывk= 2;емых ПС необходимо из них вm= 9;брать предваритеl= 3;ьный набор стандартов, в наибольшей степени относящихсn= 3; к ПС данного класса. Этот набор стандартов может быть дополнен во = 79;можными и целесообр = 72;зными для применения стандартамl= 0; де-факто и перечнем по = 76;лежащих разработке нормативныm= 3; документов данного проекта. В результате формируетсn= 3; предв= 072;рительный перечень стандартов и нормативнm= 9;х докум= ;ентов, который должен стать основой для профилей ЖЦ ПС. Этот перечень должен быть указан в спецификацl= 0;и требований или войти в с&#= 1086;став системного проекта комплекса п = 88;ограмм.<o:p></o:p> Од= ним из преимущестk= 4; от разработки = 80; внедрения профиля ста = 85;дартов для большой организациl= 0;-пользовате&#= 1083;я является то, что он обесп= 077;чивает совершенство= вание взаимосвязk= 7;й, особенно между разными подразделеl= 5;иями, которым необходимы гарантии того, что их системы буд = 91;т корректно взаимодейсm= 0;вовать, а ключевые программныk= 7; средства и данные будут переносимы между платформамl= 0;, полученнымl= 0; от разных поставщикоk= 4;. На этапе о= ;пределения области применения профиля должны быть выявлены:<o:p></o:p>= <![if !supportLists]>-&nb= sp; <![endif]>направлени= ;я деятельносm= 0;и предприятиn= 3;, подлежащие учету при построении профиля;<o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>срок реализации профиля и контрольнаn= 3; дата, когда работа над п= 088;офилем должна быть завершена;<o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>техническl= 0;е стратегии, предположеl= 5;ия и о= граничения проекта системы и ПС;</= span><o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>опытный и энергичный лидер, который пользуется = 74; предприятиl= 0; уваж= ;ением и авторитет = 86;м, достаточныl= 4; для того, чтобы возгл = 72;вить и довести до конца работ = 91; по = созданию и утверждениn= 2; профиля ста = 85;дартов проекта системы и ПС;</= span><o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>уровень компетентнl= 6;сти коллектива, разрабатывk= 2;ющего пр= офиль, его знания и пригодностn= 0; к экспертиз = 77; проекта и деят= ;ельности предприятиn= 3;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> На этапе проектировk= 2;ния профиля ПС уточ= ;няется жизне= ;нный цикл и основные характерисm= 0;ики проекта. Это позволяет селектир = 86;вать перечень ст = 72;ндартов и нормативн = 99;х документов, целесообраk= 9;ных для использ = 86;вания в профилях Ж = 62; данного ПС, провести и = 93; адаптацию д = 83;я применения = 89; учетом= характериl= 9;тик проекта, метод= ;ологии и технологии создания ПС, а также предполагаk= 7;мых средств автоматизаm= 4;ии разработки, = 089;опровожден&= #1080;я и управлени= 03; конфигурацl= 0;ей комплекса программ. На этом этапе описываютсn= 3; как функционалn= 0;ные, так и технич= 077;ские требования, устанавливk= 2;емые в профиле. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> В уточненном плане= ; реализациl= 0; системы должны= быть предс = 90;авлены ссылки на соста= ;в и содержани = 77; документов каждого про = 92;иля, выделены компоненты, параметры и ограничениn= 3;, сформироваl= 5;ные в процессе адаптации профиля ЖЦ данного ПС. Для разрабо = 90;чиков и заказчико = 74; на этом этап= 077; должен быть создан прое = 82;т руководствk= 2; применения профилей на последующиm= 3; этапах ЖЦ. В результате на этом этапе &= nbsp; формируетl= 9;я прое = 82;т адаптировk= 2;нного набора проф = 80;лей. Необходимо провести предваритk= 7;льное обучение ра = 79;работчиков проекта применению профилей ЖЦ ПС и основны= 084; концепциям профилей дл= 03; данной системы. Конкретизаm= 4;ия обеспечениn= 3; технологичk= 7;ской поддержки последующеl= 1; разработки ПС позволяе = 90; завер= 096;ить и утвердить адаптироваl= 5;ные профили, подде= ;рживающие ЖЦ ПС, а также руководствk= 2; по их применению. </s= pan>Результатl= 6;м этого процесса является определениk= 7; стандартов = 80; выбор интер = 92;ейсов, которые удовлетворn= 3;ют требованияl= 4;, предъявляеl= 4;ым к системе в ц&#= 1077;лом. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext; mso-bidi-font-style:italic'> &n= bsp; Этап разработки</spa= n> системы и ко= 084;плекса программ связан, преж= 076;е всего, с прог&#= 1088;аммировани= ем и тестированl= 0;ем компонентоk= 4; ПС, которые создаются заново для данной системы. Одновременl= 5;о создаются функционалn= 0;ные тесты для проверки выполнения = 82;омпонентам&#= 1080; заданных фу = 85;кций. Разработка прогр= ;аммных средств и их компонентоk= 4; произ= ;водится с помощью инстр= ;ументальны = 93; средств, отвечающих требованияl= 4; выбранного ранее профиля методологиl= 0; и технологи = 80;. Системны&= #1077;, аппаратные = 80; программныk= 7; средства необходимо проверять н = 72; соответствl= 0;е функционалn= 0;ным и эксплуатацl= 0;онным требованияl= 4; профилей. Если закупленныk= 7; продукты ил = 80; платформы уже прошли у поставщика тестированl= 0;е на соответс = 90;вие профилям, процедура тестированl= 0;я у потребите = 83;я может быть несколько сокращена п = 88;и условии, что нет проблем = 089; несоответсm= 0;вием архитектурm= 9; стандартам. </s= pan>Состав и содержани = 77; применяемыm= 3; документов профилей ЖЦ ПС должны быть тесно связа = 85;ы с планом и перечнем работ, выполняемыm= 3; на соответствm= 1;ющих этапах. В обязательнm= 9;х документах должно быть также отражено со = 76;ержание дополнителn= 0;ных нормативныm= 3; документов, согласуемыm= 3; с заказчико = 84;. <o:p></o:p> На этапе внедрения профиля стандартов</spa= n> важно иметь план по его применению. = 056;уководител&= #1080; высшего уровня должны установить приоритеты при реализа = 94;ии отдельных частей и требований профиля. Внедрение профиля в соответствl= 0;и с задачами проекта или предприятиn= 3; будет упрощ = 77;но, если ключевые цели обеспечениn= 3; функционалn= 0;ной совместимоl= 9;ти будут четко документирl= 6;ваны в профиле. План внедрения профиля дол = 78;ен быть действующиl= 4; документом = 80; постоянно актуализирl= 6;ваться по мере изменения проекта. <o:p></o:p> Для обеспечениn= 3; корректногl= 6; применения = 82;аждого профиля должна быть разработанk= 2; и утвержден = 72; методика проверки и тести= ;рования для установлеl= 5;ия степени соответствl= 0;я комплекса п = 88;ограмм утвержденнl= 6;му профилю ЖЦ П= 057; и БД. Содержаниk= 7; и рекоменда = 94;ии профилей ЖЦ должны быть освоены специалистk= 2;ми, осуществлn= 3;ющими контроль их выполнения = 80; тестированl= 0;е создаваемоk= 5;о комплекса программ. Отдельн= ;ые компоненты профиля подлежат тестированl= 0;ю, как с точки зрения соответствl= 0;я необходимыl= 4; стандартам, так и соответствl= 0;я требованияl= 4;, сформулироk= 4;анным в терминах и= 093; характерисm= 0;ик качества. Тестированl= 0;е на соответс = 90;вие не гарантируеm= 0; функционалn= 0;ной совместимоl= 9;ти, оно представляk= 7;т лишь тест на <s= pan style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>сl= 6;ответствие набору тестовых утверждениl= 1;, содержащихl= 9;я в стандарте. Поведение объекта отслеживаеm= 0;ся и сравниваетl= 9;я с ожидаемым результатоl= 4; эталонной реализации. </s= pan><o:p></o:p><= /span> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> После детального проектировk= 2;ния версии ПС все последующl= 0;е работы по со= 079;данию комплекса программ, вплоть до завершения испытаний и сертификацl= 0;и, должны проводитьсn= 3; в соответствl= 0;и с утвержден = 85;ыми профилями ЖЦ ПС</spa= n>, руководстk= 4;ами по их примен= 077;нию и проверятьсn= 3; на соответствl= 0;е профилям по утвержденl= 5;ым метод= ;икам тестированl= 0;я. Для этого должны быть созданы пла = 85;, перечень и содержание работ, в которых применяютсn= 3; конкретные фрагменты, определеннm= 9;е положения каждого профиля и ра= 079;делы методики, по которым тестируетсn= 3; соответствl= 0;е версии ПС данному профилю. Наиболее полная проверка соответствl= 0;я утвержденнl= 6;му профилю производитl= 9;я в процессе испытаний к = 86;мплекса программ. В акте по результатаl= 4; испытаний кроме всех характ = 77;ристик версии программноk= 5;о продукта до = 83;жно быть отражено соответствl= 0;е профилям стандартов = 74; той их части, которая непосредсm= 0;венно влияет на характерисm= 0;ики версии прог = 88;аммного продукта. Кроме того, должны быть обобщены и представлеl= 5;ы результаты применения утвержденнm= 9;х профилей ЖЦ ПС = 74; процессе создания данной версии комп = 83;екса программ.<o:p></o:p>= При сопровождеl= 5;ии п= ;рограммног = 86; продукта и создании ег = 86; новых верси = 81; накапливаеm= 0;ся опыт применениn= 3; каждого использовk= 2;нного профиля стандартоk= 4; ЖЦ, проявляютl= 9;я его некоторые недостатки = 80; появляются предложениn= 3; по модернизацl= 0;и. На этой стадии профиль продолжает выполнять регламентиl= 8;ующую функцию в качестве инструментk= 2; для управления конфигурацl= 0;ей системы. На этапе сопровождеl= 5;ия профиль пре = 74;ращается в документ, позволяющиl= 1; установить план текущи = 93; и долгосроч = 85;ых мероприятиl= 1; по развитию инфраструкm= 0;уры предприятиn= 3; и внедрению новых систе = 84;. Кроме того, в течен&#= 1080;е времени экспл= ;уатации созданной версии прог = 88;аммного продукта возможно появление новых стандартов де-юре и де-факто, которые целесообраk= 9;но учест= ;ь в конкретноl= 4; профиле. Сопровождk= 7;ние и смена верс= 080;й ПС может привести к необходимоl= 9;ти корректироk= 4;ки и модернизацl= 0;и конкретногl= 6; профиля ЖЦ с= 080;стемы. Такая модернизаm= 4;ия профиля может отразиться не только на вновь создаваемыm= 3; версиях ПС, но потребоватn= 0; доработок уже эксплуа = 90;ируемых версий.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Жизн&= #1077;нный цикл профил= 03; стандартов ПС при его сопровождеl= 5;ии, может в некоторой степени повторять ЖЦ системы и/или ПС, созд&= #1072;нных с его применениеl= 4;. Для этого следует разработатn= 0; или выбрать = 080; утвердить Руководст = 74;о по сопровождеl= 5;ию, разви= ;тию и модификациl= 0; профиля ЖЦ П= 057;, а также методики и плаl= 5; управления конфигурацl= 0;ями версий профиля, включающие:<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>пра= вила и процедуры идентификаm= 4;ии компонентl= 6;в и версий профиля ста = 85;дартов;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>мет= одики сбора, накопления = 80; обработки с = 86;общений о предлагае = 84;ых изменениях профиля;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>мет= одики корректироk= 4;ки и извещения пользоватеl= 3;ей о выполненнm= 9;х измен= ;ениях в профиле, влияющих н = 72; характерисm= 0;ики качества программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>мет= одики и руководствk= 2; по поддержк = 77; сохранностl= 0; и адекватно = 89;ти документацl= 0;и и средств, реализующl= 0;х требования = 80; рекомендацl= 0;и профиля;<o:p></o:p> <![if !supportLists]>- &nb= sp; = <![endif]>рук= оводство по вводу= очередной версии профиля стандартов ЖЦ ПС.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При примеl= 5;ении профилей следует обеспечить </sp= an>проверку к= 086;рректности их использо = 74;ания путем тестированl= 0;я, испыт= ;аний и сертифика = 94;ии для чего должна быть создана &#= 1090;ехнология контр= оля и тестированl= 0;я в процессе применения профиля специалистk= 2;ми. Она должна быть поддер = 78;ана совокупносm= 0;ью методик, инструменm= 0;альных средств, сос= 090;авом и содержаниеl= 4; оформляемыm= 3; документов на каждом этапе обеспечениn= 3; и контроля корректносm= 0;и применения соответствm= 1;ющей версии и по= 083;ожений профиля. Профи= ;ли должны опре = 76;еляться таким образом, чтобы тестированl= 0;е их реализации можно было осуществлn= 3;ть по возможно = 89;ти наиболее полно, по стандартизl= 0;рованной методике. При сертификацl= 0;и сложных систем как специальныl= 1; вид иl= 9;пытаний &#= 1094;елесообраз= но выделять сертификацl= 0;ю на соответствl= 0;е профилям: <o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>процесl= 9;ов жизненного цикла системы и основных компонентоk= 4; ПС и БД;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>продукm= 0;ов и компонентоk= 4; системы, подготовлk= 7;нных и рекоменду = 77;мых для эксплуа = 90;ации и сопровождеl= 5;ия.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> В ряде случаев, производитl= 9;я &#= 1087;еренос разработанl= 5;ого программноk= 5;о продукта с инструментk= 2;льной платформы разработчиl= 2;а системы на реальную – целевую платформу = 87;рименения ПС. При этом проверяетсn= 3; соответствl= 0;е реальной платформы т = 88;ебованиям функционалn= 0;ных профилей си = 89;темы и функциониl= 8;ование ПС на реальн= 086;й платформе. Этап внедрения предполагаk= 7;т адаптацию и настройку программноk= 5;о продукта на реальные условия эксплуатацl= 0;и, для которых он создавался. Прием= ;очные испытания П = 57; должны проводитьсn= 3; в условиях реальной эксплуатацl= 0;и на соответствl= 0;е спецификацl= 0;ям функционалn= 0;ных требований и требованиn= 3;м полного профиля ПС, который бы = 83; сформироваl= 5; в процессе создания системы.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Последующk= 2;я деталиk= 9;ация требований и полож= ;ений профи= ;лей должна<s= pan style=3D'mso-spacerun:yes'> прово= ;диться с ориентациеl= 1; на унификац = 80;ю конкретных процессов, работ и документов версий программноk= 5;о продукта определеннl= 6;го функционалn= 0;ного назначения. Можно выделить следующие основные группы специалистl= 6;в, </sp= an>использую = 97;ие документы профилей: <o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>рук= оводители – менеджеры крупного проекта системы и е= 105; основных, функционалn= 0;ных компо= ;нентов программноk= 5;о продукта;<o:p></o:p>= <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>мен= еджеры – системные аналитики, создатели спецификацl= 0;й требований, = 087;илотных проектов компонентоk= 4; и алгоритмо = 74; решения функционалn= 0;ных задач;<o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>про= граммисты-р = 72;зработчики программныm= 3; компоненто&#= 1074;, структур и содержания данных;<o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>инт= еграторы функционалn= 0;ных программныm= 3; компонентоk= 4;, тестирующиk= 7; и отлаж= ;ивающие крупные функционалn= 0;ные компоненты, или ПС в цело&#= 1084;;<o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>спе= циалисты сопровождеl= 5;ия и управлени= 03; конфигурац&= #1080;ей версий прог = 88;аммных продуктов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; = <![endif]>исп= ытатели и сертиф = 80;каторы программныm= 3; продуктов;<o:p></o:p>= <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>раз= работчики технологии, инструментk= 2;льных средств, методическl= 0;х, руков= ;одящих и инструктивl= 5;ых документов, обеспечиваn= 2;щих реализацию профилей стандартов ЖЦ ПС.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Для деятельносm= 0;и перечисленl= 5;ых выше категорий специалистl= 6;в, на базе профи= ;лей должен быть создан &#= 1082;омплект документов</spa= n>, каждый из которых имеет конкретных пользоватеl= 3;ей в жизненном цикле ПС. В них = 76;олжно быть отражено:<o:p></o:p>= <![if !sup= portLists]>-&nb= sp; <![endif]>сод= ержание и описание выбранных положений = 80; разделов ст = 72;ндартов и норl= 4;ативных документов профиля с позиции его = 082;онкретного пользоватеl= 3;я;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>пар= аметры адаптации разделов стандартов профиля и содержание = 76;ополнитель&#= 1085;ых нормативныm= 3; документов;<o:p= ></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>мет= одика и сценарии корректногl= 6; применения всех обязательнm= 9;х и рекоменду = 77;мых положений профиля стандартов;<o:p= ></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>тре= бования к содержани= 02; отчетов о результатаm= 3; контроля и тесm= 0;ирования компо= ;нентов системы на соответствl= 0;е обязательнm= 9;м положениям профиля стандартов = 74; процессе их жизненного цикла. <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102452"></a><a name=3D"_Toc508102225">2.3. Модель профиля стандартов жизне= ;нного цикла = &nb= sp; = &nb= sp; сложных пр = 86;граммных средств</a></h1> <o:p> </o:p> Комплекснl= 6;е, скоординирl= 6;ванное применение = 87;рофилей стандартов = 80; средств k= 4; процессе создания, развития и применения ПС позволяе = 90; исключать многие виды дефектов ил = 80; значительнl= 6; ослаблять и = 93; влияние. Тем самым уровень достигаемоk= 5;о качества ПС с = 90;ановится предсказуеl= 4;ым и управляемыl= 4;, непосредстk= 4;енно зависящим о = 90; ресурсов, выделяемых на его достижение, = 072; главное, от системы кач = 77;ства и эффективноl= 9;ти технологии, = 080;спользуемы&= #1093; на всех этапах жизненного цикла ПС. <o:p></o:p> </spa= n>Процесс= ;ы жизненного цикла ПС основаны на = 076;вух исходных пр = 80;нципах: моду = 83;ьности и ответственl= 5;ости. Процессы являются модульными = 74; том смысле, что они: строго связаны и вз= 072;имоувязаны; свободно соединены. Число интерфейсоk= 4; между проце = 89;сами сведено к ми= 085;имуму. В принципе каждый процесс предназначk= 7;н для реализа = 94;ии уникальной функции в жизненном цикле и може= 090; привлекать другой процесс для = 074;ыполнения специализиl= 8;ованной функции. Для обозначениn= 3;, определениn= 3; области применения = 80; структурирl= 6;вания процессов используютl= 9;я правила:<o:p></o:p> <![if !supportLists= ]>- &nb= sp; = <![endif]>п = 88;оцесс должен быть модульным, т. е. один процесс должен выполнять о = 76;ну и только одн= 091; функцию в жизненном цикле, а интерфейсы между двумя любыми проц = 77;ссами должны быть минимизироk= 4;аны;<o:p></o:p> <![if !supportLists= ]>- &nb= sp; = <![endif]>е = 89;ли функция вызвана более чем одним проце = 89;сом, тогда функция сам = 72; становится процессом;<o:p></o:p>= <![if !supportLists= ]>- &nb= sp; = <![endif]>д = 86;лжна быть возможностn= 0; верификациl= 0; любой функции в модели жизн = 77;нного цикла ПС;<o:p></o:p> <![if !supportLists]>-&nb= sp; = &nb= sp; <![endif]>к = 72;ждый процесс должен имет= 00; внутреннюю = 89;труктуру, установленl= 5;ую в соответст = 74;ии с тем, что должно им быть выполн = 77;но.<o:p></o:p> Когда организациn= 3; в целом (или ее часть) заключает договор на программныl= 1; продукт, то она становится сm= 0;ороной. Организацl= 0;я имеет самостоятеl= 3;ьные подразделеl= 5;ия, а стороны могут быть и= 079; одной или ра= 079;ных организациl= 1;. Каждый процесс должен быть рассмотрен = 89; точки зрени= 03; оm= 0;ветственно= 089;ти (обязанност = 77;й) стороны. Организациn= 3; может выпол = 85;ять один или несколько процессов. Сторона, выполняющаn= 3; процесс, несет ответ = 89;твенность за весь данный процесс, даж= 077; если выполнение отдельных задач поручено др = 91;гим людям. Принцип ответственl= 5;ости в архитекту = 88;е и процессах жизненного цикла облег = 95;ает применение профилей стандартов для конкретногl= 6; проекта, в ко&#= 1090;орый может быть вовлечено множество л = 80;ц. <o:p></o:p> <sp= an style=3D'font-size:14.0pt'> Общая структура и состав профиля ста = 85;дартов жизненного цикла системы и крупного программноk= 5;о средства дл= 03; управления проектом представлеl= 5;ы на рис. 2.3.= На этом рисунке выделены и о= 090;ражена группа базовых стандартов управления проектами с = 80;стем и основными процессами сложных программныm= 3; средств, а также переч = 77;нь совокупносm= 0;и стандартов детализируn= 2;щих и поддерживаn= 2;щих процессы их жизненного цикла. Выделенные = 73;азовые стандарты образуют иерархичесl= 2;ую группу и тесно связа = 85;ы между собой концепциямl= 0;, требованияl= 4;и, процессам и ссылками. Основу профилей управления проектами составляют две группы: стандарты менеджментk= 2; качества процессов жизненного цикла систе = 84; –</spa= n> <= /span>CMMI= :2003 и менеджме = 85;та (администра = 90;ивного управления) системой качества (требования) </= span>–</spa= n> ISO 9= 001:2000. Так как эти стандарты имеют много общего и трудно выделить их преимущестk= 4;а, то при реальной разработке крупных проектов целесообраk= 9;но уделять приоритет о = 76;ной из групп в зависимостl= 0; от особенностk= 7;й конкретногl= 6; проекта и предшествоk= 4;авшего опыта специ = 72;листов предприятиn= 3;. <o:p></o:p> Некоторым преимущестk= 4;ом применения стандарта ISO 9001 для управления проектами П = 57;, является ег = 86; развитие и детализациn= 3; требований = 74; специальноl= 4; руководствk= 7; ISO 90003:2004 для программныm= 3; средств. В этом руководствk= 7; цитируются каждое треб = 86;вание ISO 9001, онl= 6; комментируk= 7;тся и снабжаетс= 03; особенностn= 3;ми реализации процессов управления для конкретных проектов программныm= 3; средств. Кроме того, при описани = 80; ряда процессов управления проектом дл= 03; их уточнени= 03; и конкретиз = 72;ции делаются ссылки на основные стандарты, регламентиl= 8;ующие жизненный цикл ПС: ISO 12207, ISO 15504, ISO 9126, а k= 4; приложении = 87;роводится сопоставлеl= 5;ие требований этого стандарта с = процессаl= 4; управления = 80; с рекомендацl= 0;ями стандарта ISO 12207.<= span style=3D'mso-spacerun:yes'> <o:p></o:p> Часто создание профилей стандартов крупных программныm= 3; проектов на = 95;инается с определениn= 3; жизненного цикла систе = 84;ы, процессы которого регламентиl= 8;уются стандартом ISO 15288:2002. Пол&#= 1086;жения этого стандарта коррелир = 86;ванны с рекомендацl= 0;ями стандарта ISO 12207, которые детализируn= 2;тся в стандарте ISO 15504:1-9:1998 и в послед&#= 1091;ющей большой группе стан = 76;артов (см. рис. 2.3). <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Профиль жизненного цикла= ; ПС и Б = 44; целесообраk= 9;но определять на основе подмножестk= 4;а процессов, работ и задач стандарта ISO 12207, </span= > выбир= ая их с учетом характерисm= 0;ик проекта конкретной системы. Воз= 084;ожно, что к выбранному подмножестk= 4;у потребуетсn= 3; добавление = 76;ополнитель&#= 1085;ых процессов, работ, задач и нормативн = 99;х документов, = 089;вязанных со спецификой данной системы. Это рекомендуеm= 0;ся в новых Прил= 086;жениях 1 и 2 к этому стандарту, а также в ряде руководств детализируn= 2;щих основные процессы ст = 72;ндарта ISO 12207. Ряд работ, особенно на наиболее творческиm= 3; этапах созда= ;ния прогр= ;аммного средства, не регламентиl= 8;уется стандартамl= 0;. Это не позволя= 077;т разрабатывk= 2;ть и применять профили ЖЦ ПС, основанны = 77; только на базе стандартоk= 4;. Иногда цел = 77;сообразно дополнитеl= 3;ьно регламентиl= 8;овать такие работ = 99; нормативныl= 4;и документамl= 0; и специфика = 94;иями разработчиl= 2;ов проекта систе= ;мы или ведомст = 74;енными нормативныl= 4;и документамl= 0;. <o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = 42; стандарте ISO 12207 и= Приложенияm= 3; 1 и 2 к этому стандарту, изложены основы преобразовk= 2;ния и адаптации базовой стр = 91;ктуры процессов ЖЦ для профил= 03; конкретногl= 6; проек= ;та ПС и БД. В них даны общие рекомендацl= 0;и по адаптаци = 80; процессов ЖЦ, а также конкр = 77;тные рекомендацl= 0;и по возможны = 84; изменениям ряда работ и результируn= 2;щих документов = 74; зависимостl= 0; от характерисm= 0;ик конкретногl= 6; объекта и процесса ег = 86; разработки. В связи с возрастающk= 7;й ролью качества сложных ПС, целес= ;ообразно выделять пр = 86;филь обеспечениn= 3; качества ПС и Б = 44; конкретноl= 1; системы, регламентl= 0;рующий требования = 82; качеству и меры по его обеспечениn= 2;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Модель профиля стандартов = 78;изненного цикла сложных про = 75;раммных средств обычно формируетсn= 3; из 10 –12 базовыm= 3; стандартов. Их количество зависит от целей, сложн= 086;сти и особенностk= 7;й проекта, от назначения и области применения модели, а также от возможностk= 7;й формализацl= 0;и её компонентоk= 4;. Для последующеk= 5;о изложения п = 88;ограммной инженерии при их выбор= 077; и формированl= 0;и модели проф = 80;ля стандартов учитывалосn= 0; наличие международl= 5;ых стандартов (Приложение 1), которые мог = 91;т использоваm= 0;ься при определ = 77;нии жизненного цикла ПС и объединениl= 0; их в профиль, пригодный для последующеk= 5;о использоваl= 5;ия в технологи = 80; создания и развития кр = 91;пного проекта. Поэтому ряд не стандарт = 80;зированных – творчески = 93; процессов явно не отражен в рассматривk= 2;емой модели, однако они существеннm= 9; для реально = 75;о жизненного цикла ПС. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Сформировk= 2;нный и используе = 84;ый далее в лекциях профиль жизненного цикла ПС состоит из трех групп стандартов R= 11; рис. 2.4:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>г = 88;уппы стандартов управления жизненным ц = 80;клом сложных проектов систем и программныm= 3; средств, возглавляеl= 4;ой стандартамl= 0; менеджмент&#= 1072; – CMMI и ISO 9000;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>группы стандартов проектировk= 2;ния, разработки, = 089;опровожден&= #1080;я и управлени= 03; конфигурацl= 0;ей, регламентиl= 8;уемой базовыми стандартамl= 0; жизненногl= 6; цикла систе = 84; и программн = 99;х средств – ISO 15288 и ISO 12207;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>групп&= #1099; стандартов оценивания = 80; обеспечениn= 3; качества, бе= 079;опасности и документи = 88;ования в жизненном цикле программныm= 3; средств, с головными стандартамl= 0; – ISO 9126 и = ISO 25000. <o= :p></o:p> Каждая выделенная группа проф = 80;ля стандартов жизненногl= 6; цикла (см. рис. 2.4) детализирl= 6;вана набором ста = 85;дартов, которые представлеl= 5;ы в Приложени = 80; 1. Эта схема далее рассматривk= 2;ется как базовая = 074; программноl= 1; инженерии, подлежащая конкретизаm= 4;ии и адаптации = 074; проектах в соответствl= 0;и с особеннос = 90;ями развития профиля жизненного цикла прогр = 72;ммного средства (см. рис. 2.2). Большинствl= 6; представлеl= 5;ных стандартов = 80;зложено достаточно детально дл= 03; практическl= 6;го применения = 74; последующиm= 3; лекциях. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102453"></a><a name=3D"_Toc508102226">Лекция 3. Модели и процессы управления проектами программныm= 3; средств</a><= span class=3DIieoeiue><o:p><= /o:p></h1> <= span style=3D'font-size:14.0pt;font-weight:normal;mso-bidi-font-weight:bold'><o:= p> </o:p> <h1><a name=3D"_Toc508102454"></a><a name=3D"_Toc508102227">3.1. Управление проектами программнm= 9;х средств в системе </a>= – С</span= >MMI<o:p><= /o:p></h1> <o:p>&= nbsp;</o:p> Наз= начение методологиl= 0; СММ/= CMMI – системы и модели оценки зрелости – состоит в предоставлk= 7;нии необходимыm= 3; общих реком = 77;ндаций и инструкци = 81; предприятиn= 3;м, производящl= 0;м ПС, по выбору стратегии совершенстk= 4;ования качества процессов и продуктов, путем анализа степени их производсm= 0;венной зрелости и оценивания факторов, в наибольшей степени влияющих на качество ЖЦ ПС, а также посредствоl= 4; выделения п = 88;оцессов, требующих модернизацl= 0;и. Для достижения устойчивых результатоk= 4; программноl= 1; инженерии в процессе развития технологиl= 0; и организациl= 0; управления жизненным циклом ПС в стандарте ISO 15504:1-9 рек = 86;мендуется использоваm= 0;ь эволюционнm= 9;й путь, которы= 081; позволяет совершенстk= 4;овать и постепенн = 86; повышать качество процессов и продуктов, в= 089;крывать преимущесm= 0;ва и недостатк = 80; предприятиn= 3;. В методолог = 80;и СММ выделены пять уровне = 81; зрелости, раскрываеl= 4;ые в этом стандарте де-факто (рис.3= .1). Виды деятельносm= 0;и для высоких = 091;ровней зрелости в соответствl= 0;и с СММ, в стандарте делятся l= 5;а базовые и общие. Базов= 099;е виды деятельносm= 0;и являются обязательнm= 9;ми и сгруппировk= 2;ны в пять катег= 086;рий: к= ;онтрактная; инженерная; управленчk= 7;ская; вспомогатеl= 3;ьная; организациl= 6;нная. Уровни зрелости характеризm= 1;ются степенью формализацl= 0;и, адекватносm= 0;ью измерения и документирl= 6;вания процессов и продуктов Ж = 62; ПС, широтой применения стандартов = 80; инструментk= 2;льных средств автоматизаm= 4;ии работ, налич= 080;ем и полнотой реализации функций системой обеспечениn= 3; качества технологичk= 7;ских процессов и их результа = 90;ов. <o:p></o:p> Описk= 2;ние процессов ЖЦ ПС в СММ сфокус= 080;ровано на поэтапно = 84; определениl= 0;, реально достигаемыm= 3; результатоk= 4; и на оценивании качества их выполнения. Качество п = 88;оцессов зависит от технологичk= 7;ской среды, в которой они выполняютсn= 3;. Зрелость процессов = - это степень их управляемоl= 9;ти, возможностn= 0; поэтапной количествеl= 5;ной оценки каче = 89;тва, контролируk= 7;мости и эффективноl= 9;ти результатоk= 4; (см. рис. 3.1). Модель зрелости предприятиn= 3; представляk= 7;т собой метод = 80;ческий нормативныl= 1; материал, определяющl= 0;й правила создания и функционирl= 6;вания системы управления жизненным циклом ПС, методы и стандарты систематичk= 7;ского повышения культуры и качества производстk= 4;а. Рост зрелос = 90;и обеспечиваk= 7;т потенциальl= 5;ую возможностn= 0; возрастаниn= 3; эффективноl= 9;ти и согласова = 85;ности использоваl= 5;ия процессов создания, со= 087;ровождения и оценивани= 03; качества ко = 84;понентов и ПС в целом. Реальное использоваl= 5;ие регламентиl= 8;ованных процессов предполагаk= 7;т поэтапный контроль и документирl= 6;вание их характер = 80;стик качества. На предприятиn= 3;х, достигших высокого уровня зрел = 86;сти, формализовk= 2;нные процессы ЖЦ ПС должны принимать с = 90;атус стандарта, фиксироватn= 0;ся в организациl= 6;нных структурах = 80; определять производстk= 4;енную тактику и стратегию корпоративl= 5;ой культуры производстk= 4;а и системы обеспечениn= 3; качества ПС. <o= :p></o:p> У= 088;овень 1 - Начальный. Массовые разработки проектов ПС характеризm= 1;ются относительl= 5;о небольшими размерами программ в несколько т = 99;сяч строк, созда= 074;аемых несколькимl= 0; специалистk= 2;ми. Они применяют п = 88;остейшие не формализовk= 2;нные технологии = 89; использова&= #1085;ием типовых инс = 90;рументальн&#= 1099;х компонентоk= 4; операционнm= 9;х систем. Осно= 074;ные процессы ЖЦ ПС на этом уровне не регламентиl= 8;ованы, выполняютсn= 3; не совсем уп= 086;рядоченно и зависят от не координи = 88;ованных индивидуалn= 0;ных усилий и свойств отд = 77;льных специалистl= 6;в. Успех проекта, как правило, зависит от энергичносm= 0;и, таланта и опыта нескольких руководитеl= 3;ей и исполнителk= 7;й. Процессы на первом уровне характеризm= 1;ются своей непре = 76;сказуемост&#= 1100;ю по трудоемкосm= 0;и и срокам в св&#= 1103;зи с тем, что их состав, назначение = 80; последоватk= 7;льность выполнения могут менят= 00;ся случайным образом в за= 074;исимости от текущей ситуации. <o:p></o:p></span= > = Уровень 2 = - Управляемыl= 1; – базовое управление. Для сложных про = 77;ктов ПС объемом в десятки и сотни тысяч = 089;трок, в которых участвуют десятки специалистl= 6;в разной квалификацl= 0;и, необходимы организациn= 3;, регламентиl= 8;ование технологии = 80; унификация процессов деятельносm= 0;и каждого из них. Процесс= 099; на этом уровне заранее планируютсn= 3;, их выполнен = 80;е контролируk= 7;тся, чем достигаетсn= 3; предсказуеl= 4;ость результатоk= 4; и времени выполнения этапов, компонентоk= 4; и проекта в целом. Основной ос = 86;бенностью второго уровня является наличие формализовk= 2;нных и документи = 88;ованных процессов управления проектами, которые пригодны дл= 03; модернизацl= 0;и, а их результ= 072;ты, поддаются количествеl= 5;ной оценке. На этом уровне акценты упр = 72;вления сосредоточl= 0;ваются на предвари = 90;ельном упорядоченl= 0;и и регламентиl= 8;овании процессов создания, сопровождеl= 5;ия и оценивани= 03; качества программноk= 5;о средства, од= 085;ако для крупных проектов ПС = 089; гарантировk= 2;нным качеством, риск провал = 72; может оставаться еще достаточно большим.<o:p></o:p> = Уровень 3 <span style=3D'mso-bidi-font-size:14.0pt;font-family:Symbol;mso-ascii-font-family= :"Times New Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-weight:bold'>- Определеннm= 9;й – стандартизk= 2;ция процессов. При высоки = 93; требованияm= 3; заказчика и пользоватеl= 3;ей к конкретны = 84; характерисm= 0;икам качества сложного ПС = 080; к выполнени= 02; ограничениl= 1; по использо = 74;анию ресурсов, необходимо дальнейшее совершенстk= 4;ование и повышение уровня зрелости процессов Ж = 62; ПС. Процессы ЖЦ ПС на этом уровне долж = 85;ы быть стандартизl= 0;рованы, и представляm= 0;ь собой целос = 90;ную технологичk= 7;скую систему, обязательнm= 1;ю для всех подразделеl= 5;ий. На основе единой технологии поддержки и обеспечениn= 3; качества ЖЦ ПС, для каждо&#= 1075;о проекта могут разрабатывk= 2;ться дополнителn= 0;ные процессы последоватk= 7;льного оценивания качества продуктов с учетом их особенностk= 7;й. Описание каждого процесса должно включать ус = 83;овия его выполнения, входные данные, рекомендацl= 0;и стандартов = 80; процедуры выполнения, механизмы проверки качества результатоk= 4;, выходные данные, усло= 074;ия и документы завершения процессов. В описания процессов включаются сведения об = 080;нструмента&= #1083;ьных средствах, необходимыm= 3; для их выполнения, роль, ответственl= 5;ость и квалифика = 94;ия специалистl= 6;в. <o:p></o:p> = Уроk= 4;ень 4 <span style=3D'mso-bidi-font-size:14.0pt;font-family:Symbol; mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times New Ro= man"; mso-char-type:symbol;mso-symbol-font-family:Symbol;mso-bidi-font-weight:bol= d'>-</span= > Предсказуеl= 4;ый – количествеl= 5;ное управление</spa= n>. Для реализации проектов крупных, особенно сложных ПС, в жестко огра = 85;иченные сроки и с высоким гар = 72;нтированны&#= 1084; качеством, необходимы = 72;ктивные меры для предотвращk= 7;ния и выявления = 076;ефектов и ошибок на всех этапах ЖЦ ПС. Управл&#= 1077;ние должно обеспечиваm= 0;ь выполнение процессов в соответствl= 0;и с текущими требованияl= 4;и к характерисm= 0;икам качества ко = 84;понентов и ПС в целом. На этом уровне, должна прим = 77;няться система дет = 72;льного поэтапного оценивания характерисm= 0;ик качества, ка= 082; технологичk= 7;ских процессов Ж = 62;, так и самого создаваемоk= 5;о программноk= 5;о продукта и его компонентоk= 4;. Должны разрабатывk= 2;ться и применять = 89;я методики ко = 83;ичественно&#= 1081; оценки реализации процессов и их качества. Одновременl= 5;о с повышение = 84; сложности и требований = 82; качеству ПС, следует совершенстk= 4;овать управление проектами з = 72; счет сокращения текущих кор = 88;ектировок и исправлениl= 1; дефектов пр = 80; выполнении процессов. Результаты процессов становятся предсказуеl= 4;ыми по срокам и качеству в связи с тем, что они измеряются = 74; ходе их выполнения = 80; реализуютсn= 3; в рамках заданных ресурсных ограничениl= 1;. <o:p></o:p> = Уровень 5 = - Оптимизациl= 6;нный – непрерывноk= 7; совершенстk= 4;ование и улучшение. Дальнейшее последоватk= 7;льное совершенстk= 4;ование и модернизацl= 0;я технологичk= 7;ских процессов Ж = 62; ПС для повышения качества их выполнения = 80; расширение глубины l= 2;онтроля за их реализациеl= 1;. Одна из основных целей этого уровня -</span= > сокращение проявлений = 80; потерь от случайных дефектов и ошибок путе = 84; выявления сильных и слабых стор = 86;н используемm= 9;х процессов. При этом при= 086;ритетным является анализ рисков, дефектов и о= 090;клонений от заданных требований заказчика. Эти данные также используютl= 9;я для снижени= 03; себестоимоl= 9;ти ЖЦ особо сло= 078;ных ПС в результате внедрения новых техно = 83;огий и инструментk= 2;рия, а также для планированl= 0;я и осуществлеl= 5;ия модернизацl= 0;и всех видов п= 088;оцессов. Технологичk= 7;ские нововведенl= 0;я, которые мог = 91;т принести наибольшую выгоду, должны стандартизl= 0;роваться и адаптиров = 72;ться в комплексн = 91;ю технологию обеспеченl= 0;я и оценивани= 03; системы качества предприятиn= 3; и его продук= 094;ии. <o:p></o:p> В 2003 годm= 1; американскl= 0;й Институт программноl= 1; инженерии (</s= pan>SE= I) опубликовk= 2;л новую комплекснуn= 2; модель CMMI, уточняющу= 02; и совершенс = 90;вующую предшествоk= 4;авшие модели CMM, а также частично уч = 80;тывающую основные требования существующl= 0;х международl= 5;ых стандартов = 74; области менеджментk= 2; программныm= 3; средств. Внедр= ение этой модели акцентировk= 2;но на улучшени = 80; процессов управления проектами П = 57;, обеспечениl= 0; их высокого качества и конкурентоl= 9;пособности, с основной ц= 077;лью – сделать процессы проектов управляемыl= 4;и, а результат = 99; – предсказу = 77;мыми. Значительнl= 6;е внимание в <sp= an lang=3DEN-US style=3D'mso-bidi-font-size:14.0pt;mso-ansi-language:EN-US;mso= -bidi-font-weight: bold'>CMMI уделяется процессам разработки = 80; учету итераций пр = 80; изменении требований заказчиков, их прослеживаl= 5;ию к функциям, компонентаl= 4;, тестам и док= 091;ментам проекта. Кон= 094;епцию, определяющm= 1;ю функционалn= 0;ную пригодностn= 0; и качk= 7;ство продукта, рекомендуеm= 0;ся сопровождаm= 0;ь проверками возможных сценариев событий при его примене = 85;ии. <o:p></o:p> В последне = 77; время появилась информация о модернизаm= 4;ии американскl= 0;м Институтом программноl= 1; инженерии SEI<= span style=3D'font-size:14.0pt'> версии </sp= an>= CMMI-SE/SW/IPPD, V1.1 на основе накопленноk= 5;о опыта и отзывов предприятиl= 1;. Предполагаk= 7;тся выпустить в 2006 году новую, с&#= 1091;щественно модернизирl= 6;ванную, версию модели CMMI-V1.2, после чего постепенно должно прек = 88;атиться применение версии 1.1. До конца 2007 года должен проводитьсn= 3; переход пользоватеl= 3;ей на версию CMMI-V1.2, а k= 4; дальнейшем она станет обязательнl= 6;й для формали = 79;ованной оценки качества (сертификац = 80;и) технологии предприятиl= 1; в области пр= 086;граммной инженерии. При этом сро= 082; действия сертификатk= 2; будет ограничен тремя годам = 80;. К этим измен= 077;ниям следует готовиться после офици = 72;льной публикации </sp= an>Институ= ;том SEI версии 1.2.= <o:p></o:p> = Два варианта модели CMMI – 1.1&nb= sp; созданы дл= 03; обеспечениn= 3; непрерывноk= 5;о оценивания комплекса процессов в = 086;пределенно&= #1081; области создания пр = 86;граммных средств или для поэтапного оценивания = 80; совершенстk= 4;ования зрелости предприятиn= 3;, а также для организациl= 0; ЖЦ комплекс = 86;в программ в целом. Модел= 080; CMMI представляn= 2;т помощь спец = 80;алистам при организациl= 0; технологии = 80; совершенстk= 4;овании их продукто = 74;, а также для упорядоченl= 0;я и обслуживанl= 0;я процессов разработки = 80; сопровождеl= 5;ия ПС. Концепци= 103; этих моделе = 81; покрывает управление = 80; оценивание зрелости сложных систем, инжен= ;ерии программныm= 3; средств, а также проце = 89;сов c</span= >оздания<= /span> интегрировk= 2;нных программныm= 3; продуктов и совершенстk= 4;ования их разработки. Компоненты = 85;епрерывной и поэтапной <sp= an style=3D'mso-spacerun:yes'> модел= ей в значитель = 85;ой степени подобны, могут выбираться = 80; применятьсn= 3; в разном составе и последоватk= 7;льности использоваl= 5;ия в зависимостl= 0; от свойств и характерисm= 0;ик конкретных проектов. <o:p></o:p> Варl= 0;анты описания моделей построены п = 86; единой схем = 77;, которая содержит общие разделы:<o:p></o:p>= предислов= 080;е;<o:p></o:p> 1. введение;<o:p></o:p>= 2. модель компонентоk= 4;;<o:p></o:p> 3. терминологl= 0;я;<o:p></o:p> 4. содержание уровней и главные компоненты = 82;аждого варианта мо = 76;ели (разработка целей и процедур);<o:p></o:p></span= > 5 разде= 083; – структура взаимодейсm= 0;вия процессов. Аннотироваl= 5;ы четыре кате = 75;ории процессов раздела 7, их общий обзор = 080; схемы взаимодейсm= 0;вия CMMI процессов: </spa= n><o:p></o:p> * менеджмент процессов; <sp= an style=3D'font-size:14.0pt'><o:p></o:p> * менеджмент R= 11; управление проектом; <o:p></o:p> * инжиниринг (технология); <= /span><o:p></o:p> * поддержка;<o:p></o:p>= 6 раздел – использоваl= 5;ие модели CMMI – краткие рекомендацl= 0;и для пользов = 72;телей по применению модели и обучению; отмечается совмеl= 9;-тимость и соответст = 74;ие процессов модели, с регламентиl= 8;ованными процессами предыдущей модели CMM в части 2 и 3 стандарта = ISO 15504.<o:p></o:p></s= pan> Последний, седьмой раздел самы = 81; большой в каждом стан = 76;арте, он занимает около 500 страниц из полного объ = 77;ма документа, который сос = 90;авляет свыше 700 страниц. В этом раздел = 77; представлеl= 5;ы подробные р = 77;комендации для реализации каждого из перечисленl= 5;ых в нем множества процессов, которые учи = 90;ывают особенностl= 0; конкретной = 84;одели. <o:p></o:p> = Пk= 7;рвый вариант (непрерывно = 81;) модели отражает документ: Capability Maturity<sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Gothic"; mso-fareast-language:JA;mso-bidi-font-weight:bold;mso-bidi-font-style:itali= c'> Model Integration= (CMMI) for Systems Engineering / Software Engineering= / Integrated Product and Process Development, Version 1.1, Continuous Representation</sp= an> (CMMI-SE/SW/IPPD, V1.1, Continuous) – Интегрировk= 2;нная модель оценивания зрелости ин = 78;енерии систем / прог&#= 1088;аммной инженерии / интегрировk= 2;нных продуктов и процессов разработки R= 11; непрерывноk= 7; представлk= 7;ние. В этой модели= седьмой раздел сост = 72;вляют процессы:<o:p></o:p>= <![if !supportLists]>- = ; <![endif]>менеджмен = 90; процессов:<o:p></o:p> * содержание организациl= 6;нных процессов;<o:p></o:p>= * определениk= 7; организациl= 6;нных процессов; &= nbsp; &nbs= p; &= nbsp; <o:p></o:p> * организациn= 3; обучения;<o:p></o:p>= * организациn= 3; преобразовk= 2;ния (изменений) п&#= 1088;оцессов;<o:p></o:p></= p> * организациn= 3; инноваций и расширений;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>управлени = 77; проектом:<o:p></o:p> * планированl= 0;е проекта; <o:p></o:p> * мониторинг и контроль процессов проекта;<o:p></o:p> * управление соглашенияl= 4;и с поставщикаl= 4;и;<o:p></o:p> * интегрировk= 2;нное управление процессами = 80; продуктами проекта;<o:p></o:p> * управление рисками;<o:p></o:p> * интеграция команды разработчиl= 2;ов;<o:p></o:p> * интегрировk= 2;нное управление поставщикаl= 4;и;<o:p></o:p> * количестве= ;нное управление проектом;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>инженерия</sp= an> (технология= ;):<o:p></o:p> * управление требованияl= 4;и;<o:p></o:p> * разработка требований;<o:p= ></o:p> * техническиk= 7; решения;<o:p></o:p> * интеграция продукта;<o:p></o:p>= * верификациn= 3;;<o:p></o:p> * валидац= ;ия (аттестация, утверждениk= 7;);<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>поддержка</sp= an>:<o:p></o:p> *управление конфигурацl= 0;ей;<o:p></o:p> * обеспечени= ;е качества процессов и продуктов;<o:p></o:p>= * измерение l= 0; анализ процессов и продуктов;<o:p></o:p>= * анализ и принятие решений на изменения;<o:p></o:p>= * организациn= 3; окружения для интеграции;<o:p= ></o:p> * анализ причин и разрешение проблем (устранение дефектов).<o:p></o:p></span= > В пяти приложенияm= 3; приводятся:<o:p= ></o:p> А – состав использоваl= 5;ных литературнm= 9;х источников = 80; документов, = 074; котором, одн= 072;ко, не упоминаютсn= 3; стандарты ISO; <o:p></o:p> В – сокращения;<o:p= ></o:p> С – глоссарий н = 72; основе терминологl= 0;и ISO, применяемоl= 1; только в чет= 099;рех стандартаm= 3; ISO= 9000, ISO 12207, ISO 15504:1-9, ISO 15288;<o:p></o:p> = D <= span style=3D'font-size:14.0pt'>– описания</span= > треб= 086;ваний и предложениl= 1; для формированl= 0;я компонентоk= 4; модели по уровням зрелости;<o:p></o:p>= Е – список участников разработки </sp= an>= CMMI – проекта. <o:p></o:p> В этой модели внимание акцентировk= 2;но на организациl= 6;нных процессах, н= 072; планированl= 0;и, управлении = 80; контроле процессов реализации проектов пр = 86;граммных средств, на разработке = 80; управлении требованияl= 4;и к программныl= 4; продуктам. Ниже представлеl= 5;ы примеры детализациl= 0; в CMMI нек= 086;торых из них. <o:p></o:p> Планироваl= 5;ие проекта в этой, также как и во второй модели вклю = 95;ает: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 94;енку возможного размера – масштаба пр = 86;граммного продукта;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>о = 94;енку сложности функций и характерисm= 0;ик проекта ПС;<o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>о = 87;ределение модели и этапов жизненного = 94;икла комплекса программ; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>т = 77;хнико-эконо&= #1084;ическое обоснованиk= 7; проекта – определениk= 7; стоимости, т= 088;удоемкости и длительносm= 0;и ЖЦ ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>р = 72;зработка поэтапного графика работ и бюдж= 077;та проекта;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>а = 85;ализ, идентификаm= 4;ия и оценка проектных р = 80;сков;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 83;анирование и управлени = 77; документирl= 6;ванием процессов и продуктов в ЖЦ проекта ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 83;анирование и распределеl= 5;ие техническиm= 3; и людских ресурсов по этапам ЖЦ ПС;<o= :p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 83;анирование обеспечениn= 3; знаний и квалификацl= 0;и коллектива специалистl= 6;в для реализации проекта;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;общение и анализ совокупносm= 0;и планов прое = 82;та ПС; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>с = 86;гласование работ и ресурсов по этапам ЖЦ разработчиl= 2;ом с заказчико = 84; проекта ПС;<o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>д = 86;кументиров&#= 1072;ние плана работ = 080; утверждениk= 7; его менедже = 88;ом разработчиl= 2;ов проекта. <o:p></o:p> Процессы разработки требований = 82; программноl= 4;у продукту ан = 72;логичны процессам в обеих модел= 03;х и включают: <o:p></o:= p> <![if !supportLists]>- = &nb= sp; <![endif]>в = 99;явление реальных потребностk= 7;й заказчика и пользоватеl= 3;ей к функциям и характерисm= 0;икам программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>р = 72;зработку и согласованl= 0;е между заказчиком = 80; разработчиl= 2;ом исходных, ба= 079;овых требований = 82; функциям программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>о = 87;ределение доступных ресурсов и ограничениl= 1; проекта ком = 87;лекса программ;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>д = 77;композицию базовых исходных требований = 82; функциям ПС = 074; набор требо = 74;аний к компонентаl= 4; и тестам комплекса п = 88;ограмм;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>ф = 86;рмализацию требований = 82; интерфейсаl= 4; между компонентаl= 4;и, с операцион = 85;ой и внешней средой;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>р = 72;зработку концепции программноk= 5;о продукта и с= 094;енариев его использ = 86;вания;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>р = 72;зработку требований = 82; обобщенным характерисm= 0;икам функционалn= 0;ной пригодностl= 0; и использоваl= 5;ию функций программноk= 5;о продукта по назначению.<o:p= ></o:p> Управлениk= 7; требованияl= 4;и в обеих моделях включает:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>д = 86;стижение однозначноk= 5;о понимания требований = 82; проекту ПС заказчиком = 80; разработчиl= 2;ами;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 86;лучение заказчиком от разработчиl= 2;ов обязательсm= 0;в выполнить все его треб= 086;вания к программноl= 4;у продукту;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>с = 86;гласованно&#= 1077; между заказчиком = 80; разработчиl= 2;ом управление изменениямl= 0; требований = 82; проекту ПС;<o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;еспечение прослеживаl= 5;ия корректносm= 0;и изменений от общих требований = 82; проекту ПС д= 086; требований = 82; компонентаl= 4; и частным процессам;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>в = 99;явление и идентификаm= 4;ия несоответсm= 0;вий между процессами разработки проекта и требованияl= 4;и заказчика.<o:p></o:p>= Второй вариант CMMI преk= 6;ставлен документом: </s= pan>Capability Maturity<sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Gothic"; mso-fareast-language:JA;mso-bidi-font-weight:bold;mso-bidi-font-style:itali= c'> Model Integration= for Systems Engineering / Software Engineering= / Integrated Product and Process Development, Version 1.1, Staged Representation</sp= an> (CMMI-SE/SW/IPPD, V1.1, Staged) – Интегрировk= 2;нная модель оцен = 80;вания зрелости инженерии сложных систем / программноl= 1; инженерии / интегрировk= 2;нных продуктов и процессов разработки R= 11; поэтапное представлеl= 5;ие. Модел= ь базируется на сохранении концепции пяти уровне = 81; зрелости CMM<= span style=3D'font-size:14.0pt'>. Состав процессов практическl= 0; повторяет приведенныl= 1; выше для первого варианта модели, в несколько иной послед = 86;вательност&#= 1080; и с относите= 083;ьно небольшими дополненияl= 4;и. Первый уровень отличается значительнl= 6;й неопределеl= 5;ностью состава и со= 076;ержания процессов в различных относительl= 5;о простых проектах, поэто= ;му он в документе н = 77; описан и не комментируk= 7;тся. Поэтому при уточнении = 80; детализациl= 0; содержания процессов в поэтапном варианте = CMMI рекомендуеm= 0;ся ограничивk= 2;ться ч= ;етырьмя (2-й – 5-й) основными уровнями:<o:p></o:p>= <![if !supportLists]= >- = &nb= sp; <![endif]>второй уровень – формализуеm= 0; базовое управление проектами: <o:p></o:p= > * управление требованияl= 4;и; <o:p></o:p> * планированl= 0;е проекта; <o:p></o:p> * мониторинг = 80; контроль проекта;<o:p></o:p> * управление соглашенияl= 4;и с поставщикаl= 4;и;<o:p></o:p> * измерение и анализ процессов и продуктов; <o:p></o:p= > * обеспечениk= 7; качества процессов и продуктов; <o:p></o:p= > * управление конфигурацl= 0;ей;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>третий уровень – содержит стандартизk= 2;цию основных процессов: <o:p></o:p> * разработка требований; <o:p></o:p> * техническиk= 7; решения;<o:p></o:p> * интеграция продукта; <o:p></o:p></span= > * верификациn= 3;; <o:p></o:p> * в = 72;лидация (аттестация); <= o:p></o:p> * содержание организациl= 6;нных процессов;<o:p></o:p>= * определениk= 7; организациl= 6;нных процессов; <o:p></o:p= > * организациn= 3; обучения; <o:p></o:p></span= > * интегрировk= 2;нное управление процессами = 80; продуктами проекта; <o:p></o:p> * управление рисками;<o:p></o:p> * интеграция команды разработчиl= 2;ов;<o:p></o:p> * интегрировk= 2;нное управление поставщикаl= 4;и; <o:p></o:p> * анализ и разрешение проблем (устрk= 2;нение дефектов);<o:p></o:p></span= > * орга = 85;изация окружения для интеграции; <o:p></o:p> <![if !supportLists]= >- = &nb= sp; <![endif]>четвер= тый уровень – определяет количествеl= 5;ное управление: <o:= p></o:p> * организациn= 3; представлеl= 5;ия качества пр = 86;цессов; <o:p></o:p> * количествеl= 5;ное управление всем проект = 86;м и ресурсами;<o:= p></o:p> - пятый уровень – оптимизациl= 6;нный, непрерывнl= 6;е совершенстk= 4;ование: = &nb= sp; = &nb= sp; * организациn= 3;, инновации, количествеl= 5;ное управление процессами = 80; обеспечениk= 7;м ресурсами;<o:p></o:p>= </spa= n>* анализ причин дефектов, со= 074;ершенствов&= #1072;ние качества и управления процессами = 80; продуктами.<o:p= ></o:p> Прило= жения во втором варианте мо = 76;ели подобны по составу, приведенныl= 4; выше прилож = 77;ниям для первой модели. Рекомендуеm= 0;ся на каждом более высоком уровне зрел = 86;сти применять вl= 9;е процессы предыдущих нижних уровней. В обоих вариантах м = 86;дели каждый, выде= 083;енный выше базовы = 81; процесс, ком= 084;ентируется подробными рекомендацl= 0;ями для его практическl= 6;й реализации, которые содержат унифиц= 080;рованные по структур = 77; описания об = 98;емом около 20 – 30 стр= аниц: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>оk= 3;щие цели процесса, которые должны быть = 076;остигнуты; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>вk= 4;одные замечания и </s= pan>общее описание функций процесса; </span= ><o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>сl= 7;ецифически= 077; цели процесса; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>мk= 7;неджмент процесса;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>р = 72;зработка требований = 82; процессу; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>в = 79;аимодейств&#= 1080;е и интерфейс = 99; с другими пр= 086;цессами; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пl= 8;актические цели – требуемые результаты действий пр = 86;цесса; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пl= 3;анирование действий в определеннl= 6;м процессе; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>а = 85;ализ и валида = 94;ия (утверждени = 77;) результатоk= 4; реализации процесса; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>м = 86;ниторинг и контроль выполнения процесса.<o:p></o:p> Эт&#= 1080; рекомендацl= 0;и по объему, содержанию = 80; полноте описаний базовых процессов подобны ряд = 91; стандартов профиля ЖЦ ПС. Упорядоч= 077;ние и оценка полноты используемm= 9;х процессов в соответствl= 0;и с уровнями зрелости, позволяет устанавливk= 2;ть производстk= 4;енный потенциал предприятиl= 1; – разработч = 80;ков программныm= 3; продуктов п = 86; прогнозируk= 7;мому качеству процессов и результатоk= 4; их деятельн = 86;сти и готовност = 80; к сертифика = 94;ии на соответствl= 0;е определеннl= 6;му уровню зрелости модели CMMI – 1.1.&n= bsp; <o:p></o:p> Особое внимание в моделях CMMI уделяется процессам м = 77;неджмента проекта ПС. Эти требования = 80; процессы моделей практическl= 0; соотв= 077;тствуют, регламентl= 0;рованным и детализироk= 4;анным рекомендацl= 0;ям в стандарта = 93; ISO<= span style=3D'color:windowtext'> 9001:2000,&nbs= p; ISO 12207 и в осн = 86;вных компонентаm= 3; профи= 083;я стандартов жизненного цикла сложных ПС. Требованияl= 4; к процессам = 074; функционалn= 0;ных разделах 4 – 8 стандартов </sp= an>ISO<= span style=3D'color:windowtext'> 9001, ISO 9004, = ISO<= span style=3D'color:windowtext'> 90003 может быть сопоставлеl= 5; адекватный по содержанию = 88;яд разделов в модел= 103;х CMMI – рис. 3.2. Общность процессов и требований состоит в по= 076;обии: состава, терминологl= 0;и, структуры, перечня осн = 86;вных рекомендуеl= 4;ых процессов управления, планированl= 0;я, учета досту = 87;ных ресурсов, реализации процессов программноl= 1; инженерии, оценивания = 80; организациl= 0; специалистl= 6;в. <o:p= ></o:p> С точки зрения поддержки и регламентиl= 8;ования полного жиз = 85;енного цикла крупных проектов программныm= 3; средств к недостаткаl= 4; моделей CMMI относительl= 5;о профиля сущ = 77;ствующих стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> можно о = 90;нести следующие:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>н = 77; все процесс = 99; предусмотрk= 7;ны в составе пр= 086;цессов моделей CMMI – 1.1, котор= ;ые развиваютсn= 3; и детально комментируn= 2;тся для их реали= 079;ации в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9004:2000 и ISO 90003:2004, а также в профиле стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'>;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>н = 77; отражены особенностl= 0; системной инженерии и международl= 5;ые стандарты, регламентl= 0;рующие процессы жизненного цикла сложн = 99;х систем ISO 15288:2002 и ISO 19760:2003; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и анализе процессов обеспечениn= 3; качества используетl= 9;я ряд традиционнm= 9;х характерисm= 0;ик систем и программныm= 3; продуктов, которые применяютсn= 3; в сложных проектах, однако не описаны и не комментируn= 2;тся базовые международl= 5;ые стандарты, систематизl= 0;рующие и регламент = 80;рующие качество программныm= 3; средств = - ISO 9126:1-4, ISO 14598:1-6,&nbs= p; ISO 15939; <= /span><o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 90;сутствуют описания характерисm= 0;ик и конкретны = 93; процессов обеспечениn= 3; информациоl= 5;ной и функционалn= 0;ной безопасносm= 0;и программныm= 3; продуктов и ссылки на мн= 086;гочисленны&= #1077; стандарты в этой област = 80;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>н = 77; отражены регламентиl= 8;ованные интерфейсы Открытых си = 89;тем на взаимоде = 81;ствие программныm= 3; компонентоk= 4;, а также с опе&#= 1088;ационной и внешней средой, в соответствl= 0;и со стандартамl= 0; = - ISO 9945:1= -4;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 86;кументиров&#= 1072;ние процессов и продуктов Ж = 62; ПС комменти = 88;уется только, по мере их реализации, = 080; не представлеl= 5;ы обоб= щенные требования к технологиm= 5;еской и эксплуата = 94;ионной документацl= 0;и на программ = 85;ый продукт в соответствl= 0;и со стандарт = 72;ми - ISO 9294, </= span>ISO<= span style=3D'font-size:14.0pt'> 15910, <= /span>ISO<= span style=3D'font-size:14.0pt'> 18019.<o:p></o:p> Для определениn= 3;, представлеl= 5;ных выше уровне = 81; зрелости пр = 86;цессов обеспечениn= 3; жизненного цикла ПС, разработаl= 5; и первонача = 83;ьно утвержден в 1998 году обширный техническиl= 1; отчет ISO= 15504 – Оценка и аттестация зрелости процессов создания и сопровождеl= 5;ия ПС и систем, состоящий из девяти ча= 089;тей и множества приложений. В нем = 80;зложена модель зрелости CMM<= span style=3D'font-size:14.0pt'> и восем= 00; базовых принципов программноl= 1; инженерии н = 72; основе стандарта ISO<= span style=3D'font-size:14.0pt'> 9000:2000 (см. лекцию 1). Затем в ISO этот документ претерпел коренную переработкm= 1;, сокращение, упрощение структуры и содержания, при пl= 6;лном сохранении целей и конц= 077;пции, и утвержден как стандар = 90; в составе пяти частей (см. Приложен&#= 1080;е 1). Ста = 85;дарт ISO 15504:1-5:2003-2006 регламентиl= 8;ует оценку и аттестацию = 79;релости процессов создания, сопровождеl= 5;ия и совершенс = 90;вования программныm= 3; средств и систем, выполняемыm= 3; предприятиn= 3;ми:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я установленl= 0;я состояния собственнm= 9;х технологичk= 7;ских процессов и их совершен = 89;твования;<o:p></o:p></sp= an> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я определениn= 3; пригодностl= 0; собственныm= 3; процессов для выполне = 85;ия определеннm= 9;х требований или классов требований заказчиков;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>с целью его пригодностl= 0; для выполнения определеннm= 9;х договоров с = 079;аказчиками ПС и систем. <o:p></o= :p> Стандарт способствуk= 7;т: самоаттk= 7;стации зрелости предприятиl= 1;, обеспечениn= 2; адекватногl= 6; управления аттестуемыl= 4;и процессами, определениn= 2; профиля рейтингов процессов и подходит к любым сфера = 84; применения = 80; размерам ПС = 080; систем. Прим= 077;нение стандарта направлено на выработк = 91; предприятиn= 3;ми и специалис = 90;ами культуры постоянногl= 6; совершенстk= 4;ования зрелости технологий обеспечениn= 3; ЖЦ ПС, отвечающих бизнес-целя = 84; проектов и оптимизациl= 0; использоваl= 5;ия доступных ресурсов. Аттестация зрелости пр = 86;цессов предприятиl= 1; обеспечиваk= 7;т возможностn= 0; их сопостав = 83;ения и выбора, предпочтитk= 7;льных для определ = 77;нных проектов:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я заказчиков, покупателеl= 1;, пользоватеl= 3;ей программныm= 3; продуктов и систем – способностn= 0; определять = 90;екущую и потенциальl= 5;ую зрелость процессов жизненного цикла у предприятиn= 3; поставщика;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я поставщикоk= 4; и разработчиl= 2;ов – способнос = 90;ь определять текущую и потенциальl= 5;ую зрелость собственныm= 3; процессов ж = 80;зненного цикла ПС и си&#= 1089;тем, области и пр= 080;оритеты усовершенсm= 0;вования процессов;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я аттестаm= 0;оров зрелости – основу для проведения = 80; совершенстk= 4;ования процессов аттестации.<o:p= ></o:p> Аттестациn= 3; в стандарте рассматривk= 2;ется в двух аспектах: дл= 103; усовершенсm= 0;вования процессов Ж = 62; ПС и систем к&#= 1086;нкретного предприятиn= 3;, и для опреде= 083;ения соответс= ;твия декларироk= 4;анной зрелости процессов обеспечениn= 3; проекта ил = 80; предприятиn= 3;, реальным ис = 87;ользуемым процессам. Это отражен = 86; в следующих пяти частях стандарта ISO<= span style=3D'font-size:14.0pt'> 15504:1-5:2003-2006. <o:p></o:p> Часть 1 – Концепция и словарь – со= 076;ержит общую инфор = 84;ацию о процессах = 072;ттестации зрелости ПС = 080; систем, и рекомендацl= 0;и по использо = 74;анию частей стандарта. И= 079;ложены общие требования = 82; аттестации, терминологl= 0;я, структура и область применения остальных ч = 72;стей стандарта.<o:p></o:p>= Часть= 2 – Выполнение (производст = 74;о) аттестации R= 11; включает де = 90;альные требования = 82; проведению процессов аттестации, = 082;ак основы для совершенсm= 0;вования и определен = 80;я уровня зрелости технологичk= 7;ских процессов обеспечениn= 3; ЖЦ ПС и систем. Докум= ;ент определяет процессы вы = 87;олнения аттестации, модели рекомендуеl= 4;ых процессов аттестации = 80; верификациl= 0; процессов, с тем, чтобы они были объ= 077;ктивными, содержателn= 0;ными и репрезентаm= 0;ивными. <o:p></o:p> Часть 3 – Руководствl= 6; по производ = 89;тву аттестации R= 11; содержит об = 79;ор технологии выполнения процессов аттестации зрелости, и интерпретаm= 4;ии реализации требований. = 042; нем отражен = 86;: исполнение аттестации; = 080;змерительн&= #1099;е средства дл= 03; определениn= 3; процессов зрелости; выбор и прим= 077;нение средств аттестации; оценка комп = 77;тентности аттестаm= 0;оров; вериф= ;икация соответствl= 0;я аттестации декларировk= 2;нным требованияl= 4;. Средс= ;тва аттестации могут использоваm= 0;ься предприятиn= 3;ми при планированl= 0;и, менеджментk= 7;, мониторингk= 7;, контроле и усовершенсm= 0;вовании программныm= 3; продуктов и систем, при их приобретенl= 0;и, разработке, применении = 80; сопровождеl= 5;ии.<o:p></o:p> Часть 4 – Руководствl= 6; пользоватеl= 3;ей для процессов усовершенсm= 0;вования и определениn= 3; зрелости процессов п = 86; этим двум аспекта. Рек= 086;мендуется ряд шагов, которые включают: пр= 080;менение результатоk= 4; процессов аттестации; постановка целей аттестации зрелости; определениk= 7; исходных данных для аттестации; оценка возможного снижения ре = 79;ультирующи&#= 1093; рисков; шаги по усовершенсm= 0;вованию процессов; шаги по опре= 076;елению уровня зрелости; сравнение = 88;езультатов анализа аттестации = 89; требованияl= 4;и.<o:p></o:p> Часть 5 – Образец модели процессов аттестации на соответствl= 0;е требованияl= 4;, представлеl= 5;ным в части 2. Обширный до = 82;умент (162 стр.) содержит пр = 80;меры практическl= 6;го применения предыдущих частей стан = 76;арта для организациl= 0;, оценивания = 80; совершенстk= 4;ования аттестации зрелости процессов жизненного цикла для ра= 079;личных областей ис = 87;ользования, проектов программныm= 3; средств и предприятиl= 1;. <o:p></o:p> При практичесl= 2;ой реализации проектов и обеспечениl= 0; жизне= 085;ного цикла сложн = 99;х ПС разработчиl= 2;ам и поставщикаl= 4; может быть трудно определить, = 080; выделить дл= 03; применения преимущестk= 4;а моделей CMMI. В завис= 080;мости от традиций предприятиn= 3; и особеннос = 90;ей крупного проекта ПС зачастую целесообрk= 2;зно использоваm= 0;ь как основно = 81; полный профиль стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'>, а для оценивания заказчикамl= 0; уровня зрел = 86;сти менеджментk= 2;, организациl= 6;нного и технологи = 95;еского обеспечениn= 3; проектов ПС применять к = 86;нкретные рекомендацl= 0;и CMMI. Эти рекомендацl= 0;и могут эффек = 90;ивно использоваm= 0;ься при с= 077;ртификации<= span style=3D'mso-spacerun:yes'> качества процессов на предприя = 90;иях, обеспечиваn= 2;щих ЖЦ ПС, как альтернатиk= 4;а или наряду с сертификацl= 0;ей по комплекс = 91; стандартов менеджментk= 2; ISO<= span style=3D'font-size:14.0pt'> 9000, в завиl= 9;имости от особенностk= 7;й проекта и требований заявителя н = 72; сертификацl= 0;ю программноk= 5;о продукта ил = 80; технологии обеспечениn= 3; его жизненн = 86;го цикла.<o:p></o:p> <o:p> </o:p> <h1> <= /span><a name=3D"_Toc508102455"></a><a name=3D"_Toc508102228">3.2. Стандарты менеджментk= 2; (администра = 90;ивного управления) = 082;ачеством систем</a> </h1> <o:p= ></o:p> Серия стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> 9000:2000 разработанk= 2;, чтобы помоч= 00; предприятиn= 3;м всех типов и размеров внедрить и использоваm= 0;ь эффективныk= 7; системы мен = 77;джмента (администра = 90;ивного управления) качества. Совместно они образую = 90; комплект согласованl= 5;ых стандартоk= 4; управления системами качества и могm= 1;т применятьсn= 3; как основа процессов управления = 74; программноl= 1; инженерии:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>ISO 9000:2000 – представляk= 7;т введение в системы упр = 72;вления качеством продукции и услуг и слов= 072;рь качества;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>ISO 9001:2000 – устанавливk= 2;ет детальные требования для систем управления качеством, достаточныk= 7; в случае необходимоl= 9;ти продемонстl= 8;ировать способностn= 0; предприятиn= 3;, обеспечить соответствl= 0;е качества продукции и услуг требованияl= 4; заказчика; <o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>ISO 9004:2000 – соk= 6;ержит руководстk= 4;о по внедрени= 02; и применени= 02; широко развитой системы управления качеством, чтобы дости = 95;ь постоянногl= 6; улучшения деловой дея = 90;ельности и результатоk= 4; предприятиn= 3;.<o:p></o:p> Стандарты серии ISO 9000:2000 применяют процессный подход в администраm= 0;ивном управлении системами качес= ;тва предприятиl= 1;, а также рассматривk= 2;ют способы быстрого вы= 03;вления и реализаци = 80; возможностk= 7;й для их улучшения. Процессная модель подчеркиваk= 7;т тот факт, что заказчики и другие заинтересоk= 4;анные стороны играют значительнm= 1;ю роль в проце= 089;се установленl= 0;я исходных требований. = 055;осле этого по отношению к = 86; всем процессам, н= 077;обходимым для создани= 03; необходимоl= 1; продукции, применяетсn= 3; управление процессами = 80; проводится проверка “выходов”. Измерение степени удовлетворk= 7;нности заказчика и других заинтересоk= 4;анных сторон используетl= 9;я в качестве обратной связи для оценки и признания того, что требования заказчика были выполн = 77;ны полностью.<o:p></o:p>= В стандаl= 8;те ISO 9004 детализироk= 4;аны руководящиk= 7; указания и р= 077;комендации по применению системы менеджментk= 2; качества, которые изл = 86;жены в том же порядке, как требования = 74; ISO 9001. Обk= 2; стандарта с = 89;ылаются на ISO 9000, который объясняет используемm= 1;ю терминологl= 0;ю и определениn= 3;. Структура основных требований = 80; рекомендацl= 0;й в этих станд= 072;ртах сведена к четырем объединеннm= 9;м крупным процессам (рис. 3.2): <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 73;язанности и ответственl= 5;ость администраm= 4;ии управления = 82;ачеством (раздел 5); <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 76;министрати&#= 1074;ное управление ресурсами (р= 072;здел 6);<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;оцессы жизненного цикла продукции и управления ее качество = 84; (раздел 7); <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 79;мерения, анализ и совершенстk= 4;ование продукции (раздел 8). <o:p></o:p> Стандар= ;ты серии ISO 9000:2000 рекомендуеm= 0;ся применять в = 076;еятельност&= #1080; предприятиn= 3;, начиная от идентификаm= 4;ии требований = 79;аказчика, и охватыватn= 0; все процесс = 99; системы управления качеством, вплоть до до= 089;тижения соответствl= 0;я требованияl= 4;. Применение = 89;окращенног&#= 1086;, адаптироваl= 5;ного варианта требований не освобожд = 72;ет предприятиk= 7; от ответств = 77;нности предоставлn= 3;ть продукцию, которая удовлетворn= 3;ет всем требов = 72;ниям заказчика. Система качества должна быть внедрена, поддерживаm= 0;ься в рабочем состоянии и подвергатьl= 9;я улучшениям = 89;о стороны спе = 94;иалистов предприятиn= 3;. Масштаб и глубина про = 94;едур должна опре = 76;еляться такими факторами как размер и тип предприятиn= 3;, сложность и взаимосвязn= 0; процессов, применяемыk= 7; методы, а так&#= 1078;е квалификацl= 0;я и степень подготовки персонала, участвующеk= 5;о в выполнени = 80; работ. Они дl= 6;лжны включать:<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>о = 73;щесистемны&#= 1077; процедуры, которые описывают деятельносm= 0;ь, необходимуn= 2; для внедрения и применения системы кач = 77;ства;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;оцедуры, описывающиk= 7; последоватk= 7;льность и внутренне = 77; содержание процессов, необходимыm= 3; для обеспечениn= 3; уверенност&#= 1080; в соответст = 74;ии продукции установленl= 5;ым требованияl= 4;;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>и = 85;струкции, описывающиk= 7; операционнm= 1;ю деятельносm= 0;ь и управлени = 77; процессами.<o:p= ></o:p> Для освоения и облегчения применения стандартов = 74; редакции 2000-го года, в прило&#= 1078;ении к ISO 9001:2000 приведены таблицы, отражающие взаимное соответствl= 0;е требований этого станд = 72;рта и требовани = 81; ISO<= span style=3D'font-size:14.0pt'> 9001:1994. Таблицы могут использоваm= 0;ься при необход = 80;мости подтверждеl= 5;ия в настоящее время сертификатl= 6;в качества, полученных ранее на основании применения стандартов = 74; редакции 1994-го года. Это позволяет с = 86;хранять и практическl= 0; использоваm= 0;ь всю техноло = 75;ическую документацl= 0;ю и рабочие ин= 089;трукции, базирующиеl= 9;я на стандартах качества 1994-го года, дополняя их только этим = 80; таблицами соответствl= 0;я требований.<o:p= ></o:p> Ста= ндарт ISO 9001:2000 – Система менеджменm= 0;а (администра = 90;ивного управления) качества. Требования – является базой для Ру= 082;оводства по их реализ= 072;ции в стандарте ISO 9004:2000 и кратко изло = 78;ены ниже (см. рис. 3.2).<= span style=3D'mso-spacerun:yes'> <o:p></o:p> Общие требования = 82; системе менеджментk= 2; качества. Орган= 080;зация – разработчиl= 2; должна установить = 80; управлять процессами, необходимыl= 4;и для обеспеч = 77;ния уверенностl= 0; в том, что продукция и/или услуга соответствm= 1;ют требованияl= 4; заказчика. В качестве сп = 86;соба внедрения и демонстрацl= 0;и, установлеl= 5;ных процессов, организациn= 3; должна создать систему менеджментk= 2; качества, основываясn= 0; на требованияm= 3; настоящего международl= 5;ого стандарта. Система менеджментk= 2; качества должна быть внедрена, поддерживаm= 0;ься в рабочем состоянии и подвергатьl= 9;я улучшениям = 89;о стороны организациl= 0;. Организациn= 3; должна подготовитn= 0; процедуры системы менеджментk= 2; качества, которые описывают процессы, не= 086;бходимые для внедрения с = 80;стемы менеджментk= 2; качества. Масштаб и гл= 091;бина процедур должна определятьl= 9;я такими факторами как размер и тип организациl= 0;, сложность и взаимосвязn= 0; процессов, применяемыk= 7; методы, а так&#= 1078;е квалификацl= 0;я и степень подготовки персонала, участвующеk= 5;о в выполнени = 80; работ. <o:p></o:p> Высшее руководствl= 6; предприятиn= 3; – разработчиl= 2;а должн= о продемонстl= 8;ировать свои обязательсm= 0;ва заказчику о = 90;носительно:<= o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>создания и поддержаниn= 3; важности удовлетворk= 7;ния требований заказчика;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>разработк = 80; политики качества и целей в обла= 089;ти качества, а также плани = 88;ования качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>создания системы менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>проведения анализа деятельносm= 0;и со стороны руководствk= 2;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечени= ;я уверенностl= 0; в наличии ресурсов.<o:p></o:p>= Требованиn= 3; заказчика – высшее= руководстk= 4;о должно обес = 87;ечить, что:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>потребнос = 90;и и ожидания заказчика установленm= 9; и переведен = 99; в соответствm= 1;ющие требования заказчика;<o:p></o:p>= <![if !supportLists]>= - = &nb= sp; <![endif]>требования заказчика полностью поняты разр = 72;ботчиком и могут быть удовлетворk= 7;ны.<o:p></o:p> Выс&= #1096;ее руководствl= 6; должно разработатn= 0; пол= итику в области ка= 095;ества и обеспечить уверенностn= 0; в том, что она:= <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>соответств= ;ует потребностn= 3;м организации и её заказчиков;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>включает обязательсm= 0;ва по удовлетворk= 7;нию требований = 80; постоянномm= 1; улучшению;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>обеспечива= ;ет основу для разработки = 80; анализа целей в обла= 089;ти качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>распростра= ;нена, понята и внедрена во всей органи = 79;ации;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>анализируе= ;тся с целью постоянногl= 6; поддержаниn= 3; ее пригодно = 89;ти.<o:p></o:p> Пла= нирование – организациn= 3; должна установить = 94;ели в области ка= 095;ества для каждой соответствm= 1;ющей функции и дл= 103; каждого уровня внут = 88;и организациl= 0;. Цели в области качества должны соответствl= 6;вать политике и обязательсm= 0;вам относительl= 5;о непрерывноk= 5;о улучшения качества. Орган= ;изация должна уста = 85;овить и планироватn= 0; деятельнос&#= 1090;ь и ресурсы, необходимыk= 7; для достижения целей в обла= 089;ти качества. Такое планированl= 0;е должно отвечать другим требованияl= 4; к системе менеджментk= 2; качества, а его результаты должны быть документирl= 6;ваны. Планированl= 0;е должно охватывать:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>процессы, необходимыk= 7; в рамках системы менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>процессы создания и необходимыk= 7; ресурсы, а также устан = 86;вленные характерисm= 0;ики качества на различных стадиях, с целью дости = 78;ения планируемыm= 3; результатоk= 4;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>деятельно = 89;ть по проверке, критерии приемлемосm= 0;и и необходим = 99;е отчеты по качеству.<o:p></o:p>= Сl= 0;стема менеджментk= 2; качества – организаm= 4;ия должна создать систему менеджментk= 2; качества, ка= 082; средство реализации = 77;ё политики в о= 073;ласти качества, достижения своих целей = 074; области кач = 77;ства и обеспечениn= 3; уверенностl= 0; в том, что про&= #1076;укция и/или услуга отвечает требованияl= 4; заказчика. Роли сотрудникоk= 4; и их взаимосвязl= 0;, а также отве= 090;ственность и полномочи= 03; персонала должны быть = 091;становлены для того, чтобы спосо = 73;ствовать эффективноl= 4;у управлению качеством, и должны быть доведены до соответствm= 1;ющих уровней орг = 72;низации. Высшее руководствl= 6; должно упол = 85;омочить одного (или нескольких) лиц для:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечени= ;я уверенностl= 0; в том, что система менеджментk= 2; качества внедрена и поддерживаk= 7;тся в рабочем состоянии в соответствl= 0;и с требованияl= 4;и настоящего международl= 5;ого стандарта;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>доклада высшему руководствm= 1; о функциони = 88;овании системы менеджментk= 2; качества, включая вопросы, связанные с необходимоl= 9;тью ее улучшени= 03;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечен = 80;я уверенностl= 0; в осознании во всей организациl= 0; требований = 79;аказчика.<o:p></o:p></sp= an> Организацl= 0;я должна разработатn= 0; Руков= 086;дство по качеству</sp= an>, которое должно включать: описание элементов системы менеджментk= 2; качества и и= 093; взаимосвязk= 7;й; общесистемl= 5;ые процедуры или соответствm= 1;ющие ссылки на них. Следует установить общесистемl= 5;ые процедуры для управле = 85;ия документамl= 0;, необходимыl= 4;и для функционирl= 6;вания системы мен = 77;джмента качества, обеспечиваn= 2;щие уверенностn= 0; в том, что:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>документы проверены н = 72; адекватносm= 0;ь до их применения;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>документы анализируюm= 0;ся, при необходимоl= 9;ти уточняются = 80; переутве = 88;ждаются;<o:p></o:p></sp= an> <![if !supportLists]>- = &nb= sp; <![endif]>соответств= ;ующие выпуски документов находятся в тех местах, где осуществляk= 7;тся деятельносm= 0;ь, имеющая существеннl= 6;е значение дл= 03; эффективноl= 9;ти функционирl= 6;вания системы менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>устаревшие документы изъяты из всех мест их рассылки и применения или предпринятm= 9; другие методы управления, предотвращk= 2;ющие их не= преднамереl= 5;ное использоваl= 5;ие;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>любые устаревшие документы, оставленныk= 7; для юридическиm= 3; целей или в ц&#= 1077;лях сохранения знаний, должным образом иде = 85;тифицирова&#= 1085;ы.<o:p></o:p> Дол&= #1078;ен быть составлен специальныl= 1; перечень ил = 80; эквивалентl= 5;ая процедура управления, идентифициl= 8;ующая статус текущей вер = 89;ии документов, которая был = 72; бы легко = 76;оступна в целях предотвращk= 7;ния использоваl= 5;ия недействитk= 7;льных и/или устаревших документов.<o:p= ></o:p> Для демонстрацl= 0;и соответствl= 0;я требованияl= 4; и эффективн = 86;сти функционирl= 6;вания системы менеджментk= 2; качества должны вест = 80;сь подходящие для организ = 72;ции о&= #1090;четы о качестве. Организациn= 3; должна создать и поддерживаm= 0;ь в рабочем состоянии процедуры о = 73;щесистемно&#= 1075;о уровня по идентификаm= 4;ии, хранению, восстановлk= 7;нию, обеспечениn= 2; сохранностl= 0;, установленl= 0;ю времени и места хране = 85;ия отчетов о качестве. Анализ со стороны руководствk= 2; долже= ;н через установленl= 5;ые периоды времени про = 74;одиться для обеспечениn= 3; уверенностl= 0; в сохранени = 80; её пригодностl= 0;, адекватносm= 0;и и эффективн = 86;сти. По результа = 90;ам анализа должна проводитьсn= 3; оценка необходимоl= 9;ти внесения изменений в систему мен = 77;джмента качества организациl= 0;, включая полити= ку и цели в области кач = 77;ства. <o:p></o:p> У= ;правление ресурсами необходимо для создани= 03; и поддержаниn= 3; в рабочем состоянии системы мен = 77;джмента качества. Организациn= 3; должна пров = 86;дить анализ и назначение персонала с целью обесп = 77;чения уверенностl= 0; в том, что те, кто имеет обязанностl= 0;, определеннm= 9;е системой менеджментk= 2; качества, являются ко = 84;петентными для осуществлеl= 5;ия своей деяте = 83;ьности на основе соответствm= 1;ющего образованиn= 3;, подготовки, мастерства = 80; опыта, создать и поддерживаm= 0;ь в рабочем состоянии общесистемl= 5;ые процедуры по:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>определени= ;ю потребностk= 7;й в компетентнl= 6;м персонале и = 074; его подгото = 74;ке;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечени= ;ю подготовки персонала в соответствl= 0;и с выявленны = 84;и потребностn= 3;ми;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>оценке через установленl= 5;ый период врем = 77;ни эффективноl= 9;ти подготовки кадров;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>ведению соответствm= 1;ющих отчетов об образованиl= 0; кадров, их подготовке, уровне маст = 77;рства и опыта. <o:p></o:p> Организацl= 0;я должна создать и поддерживаm= 0;ь в рабочем состоянии процедуры, обеспечиваn= 2;щие их осознани = 77; работникамl= 0; в соответст = 74;ующих службах и на соответствm= 1;ющих уровнях:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>важности соответствl= 0;я политике в области качества и требованияl= 4; к системе менеджментk= 2; качества важности;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>влияния их деятельносm= 0;и на качество = 211; фактическоk= 7; или потенци = 72;льное;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>выгоды от улучшения работы персонала;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>своей роли = 80; ответственl= 5;ости в достижени = 80; соответствl= 0;я политике в области качества и процедурам, = 072; также требованияl= 4; к системе менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>потенциаль= ;ных последствиl= 1; отклонений от установленl= 5;ых процедур.<o:p></o:p>= О= рганизация должна установить </sp= an>пер= ечень информации</spa= n>, которая необходима для управления процессами, = 072; также для обеспечениn= 3; уверенностl= 0; в соответст = 74;ии продукции и/или услуги. Общесистемl= 5;ые процедуры п = 86; управлению информациеl= 1; должны обес = 87;ечить уверенностn= 0; в доступнос = 90;и и сохранностl= 0; информации.<o:p= ></o:p> Организацl= 0;я должна определить, создать и поддерживаm= 0;ь в рабочем состоянии инф= раструктурm= 1;, необходимуn= 2; для достижения требуемого = 82;ачества продукции:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>рабочие места и соответствm= 1;ющие помещения;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>оборудован= ;ие, вспомогатеl= 3;ьные средства и инструментk= 2;льное программноk= 7; обеспечениk= 7;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пригодные способы поддержаниn= 3; работоспосl= 6;бности инфраструкm= 0;уры.<o:p></o:p> Процессы, необходимыk= 7; для выпуска требуемой продукции, их последоватk= 7;льность и взаимосвя = 79;и должны быть определены, спланироваl= 5;ы и внедрены. При определ = 77;нии таких процессов организациn= 3; должна учес = 90;ь результаты планированl= 0;я качества. До= 083;жна быть уверенностn= 0; в том, что эти процессы ос = 91;ществляютс&#= 1103; в управляемыm= 3; условиях и и= 093; результаты соответствm= 1;ют требованияl= 4; заказчика:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>установить для этих процессов соответствm= 1;ющие методы и практику выполнения, необходимыk= 7; для обеспечениn= 3; постоянной работоспосl= 6;бности процессов;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>определить и внедрить критерии и методы упра = 74;ления процессами для обеспеч = 77;ния соответствl= 0;я продукции требованияl= 4; заказчика;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>удостовери= ;ться, что процесс = 99; могут функц = 80;онировать в той мере, которая поз = 74;оляет обеспечить соответствl= 0;е продукции т = 88;ебованиям заказчика;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>обеспечить уверенностn= 0; в наличии информации = 80; данных, необ= 093;одимых для поддерж = 72;ния эффективноk= 5;о функционирl= 6;вания и мониторин = 75;а процессов;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>фиксироват= ;ь в виде отчетов качество результатоk= 4; измерений, осуществляk= 7;мых в ходе управ= 083;ения процессами, для предоставлk= 7;ния доказательl= 9;тв эффективноk= 5;о функционирl= 6;вания и мониторингk= 2; процессов.<o:p></o:p>= Орга&= #1085;изация должна создать про= цесс идентификаm= 4;ии требований заказчика:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>полноту требований заказчика к продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>требования= ;, не установленl= 5;ые заказчиком, = 085;о необходимыk= 7; для примене = 85;ия продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>обязательс= ;тва по отношени= 02; к продукции, включая регламентиl= 8;ующие и законодат = 77;льные требования;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>требования заказчика относительl= 5;о пригодностl= 0; продукции для её поста= 074;ок и сопровождеl= 5;ия.<o:p></o:p> Требованиn= 3; заказчика, включая любые предлагаемm= 9;е изменения, должны быть проанаl= 3;изированы<sp= an style=3D'font-size:14.0pt;mso-bidi-font-weight:bold'> для обеспечениn= 3; уверенностl= 0; в том, что: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>требования заказчика к продукции четко опред = 77;лены;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>в случае, когда требования заказчика н = 77; оформлены письменно, о= 085; подтвердил их до принятия их разработчиl= 2;ом;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>организаци= ;я располагаеm= 0; возможностn= 3;ми для удовлетворk= 7;ния требований = 79;аказчика к продукции.<o:= p></o:p> Организацl= 0;я должна планирова = 90;ь и управлять проектировk= 2;нием и/или разраб= 086;ткой продукции, подготавлиk= 4;ать планы проектировk= 2;ния, которые вкл= 02;чают:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>этапы процесса проектировk= 2;ния и/или разраб= 086;тки;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>требуемые действия по анализу, проверке и у= 090;верждению качества пр = 86;дукции;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>полномочи= 03; и ответственl= 5;ость за действия по проектир = 86;ванию и/или разраб= 086;тке.<o:p></o:p> </spa= n>Входные данные для проектировk= 2;ния и разработк = 80; должны включать:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>эксплуатац= ;ионные требования заказчика и = 83;и рынка;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>применяемы= ;е нормативныk= 7; и законодатеl= 3;ьные требования;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>применяемы= ;е требования по охране окружающей среды;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>любые другие требования, существеннm= 9;е для проектировk= 2;ния и разработк = 80;.<o:p></o:p> Выход= ные данные процесса проектировk= 2;ния и/или разработки</spa= n> должны быть = 079;арегистрир&= #1086;ваны в форме, дающей возможностn= 0; проверки их по отношени= 02; к входным требованияl= 4;:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>с = 86;ответствов&#= 1072;ть входным требованияl= 4; для проектировk= 2;ния и/или разраб= 086;тки;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>содержать или давать ссылку на критерий пр = 80;емки продукции и/или услуги;<o= :p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>о = 87;ределять характерисm= 0;ики продукции и/= 080;ли услуги, которые являются су = 97;ественными с точки зрения безопасносm= 0;и и правильно = 75;о использоваl= 5;ия.<o:p></o:p> На соответствm= 1;ющих этапах долж = 77;н проводитьсn= 3; систе= 084;атический анализ проекта дл= 03;: оценки возможностl= 0; выполнения требований = 82; качеству; идентификаm= 4;ии проблем – дефектов и выработки предложениl= 1; по разработке решений для = 080;х устранения. <sp= an style=3D'mso-bidi-font-style:italic'> В состав уча = 89;тников анализа проекта должны включаться представитk= 7;ли служб, связа= 085;ных с анализиру = 77;мым этапом проектировk= 2;ния. Должна быть = 089;планирован&= #1072; и выполнена проверка пр = 86;екта и/или разработки, обеспечиваn= 2;щая уверенностn= 0; в том, что выходные да = 85;ные соответствm= 1;ют входным требованияl= 4;. <o:p></o:p> Утвер= 078;дение проекта должно проводитьсn= 3; с целью подтверждеl= 5;ия того, что кон&#= 1077;чная продукция способны отвечать требованияl= 4; для конкретных условий использоваl= 5;ия заказчиком. Когда это возможно, утверждениk= 7; должно быть спланироваl= 5;о и выполнено до начала поставки ил = 80; применения продукции. Результаты утверждениn= 3; и последующиm= 3; действий должны быть зарегистриl= 8;ованы.<o:p></o:p> Изменения проекта или модификациn= 3; должны быть утверждены уполномочеl= 5;ным персоналом = 80; зарегистриl= 8;ованы до их внедре= 085;ия, следует опр = 77;делить влияние изм = 77;нений на:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>взаимодейс= ;твие между элементами проекта и/ил= 080; разработки:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>взаимодейс= ;твие между составными частями конечной продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>имеющуюся продукцию и на функцион = 80;рование ранее поста = 74;ленной продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>необходимо= ;сть проведения повторной проверки ил = 80; утверждениn= 3; для всех или части выходных данных прое = 82;тирования и/или разраб= 086;тки.<o:p></o:p> Организ= ;ация должна управл= ять процессами закупки компонентоk= 4; для обеспечениn= 3; уверенностl= 0; в соответствl= 0;и закупленноl= 1; продукции требо= ;ваниям, установленl= 5;ым заказчиком. Закупочные документы должны соде = 88;жать информацию, четко описывающуn= 2; заказанную продукцию.<o:p></o:p>= Организацl= 0;я должна спl= 3;анировать и управлять производстk= 4;енными и сервисным = 80; операциями обслуживанl= 0;я, включа= 03; те, которые предпринимk= 2;ются после первоначалn= 0;ной поставки, посредствоl= 4;: <o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>п = 88;едоставлен&#= 1080;я техническиm= 3; условий, опр= 077;деляющих характерисm= 0;ики продукции, которые должны быть достигнуты;<o:p= ></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>п = 88;едоставлен&#= 1080;я четко понимаемых производстk= 4;енных требований или инструк = 94;ий для тех видо= 074; деятельносm= 0;и, где они необ= 093;одимы для достиже = 85;ия соответствl= 0;я продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>внедрения надлежащих действий по мониторингm= 1; или проверк = 77; продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>подходящих методов для выпуска, поставки и/и= 083;и монтажа продукции.<o:p></o:p>= &nb= sp; Меры по утверждениn= 2; процессов д = 86;лжны быть направлены на: аттестацию процессов д = 86; их использоваl= 5;ия; аттестацию оборудованl= 0;я и/или персонала. <o:p></o:p= > Следует определить, спланироваm= 0;ь и внедрить проце= 089;сы измерений, мониторингk= 2;, анализа и улучшения = 76;ля обеспечениn= 3; уверенностl= 0; в том, что система менеджментk= 2; качества, процессы и продукция соответствm= 1;ют установленl= 5;ым требованияl= 4;. Эффективноl= 9;ть применяемыm= 3; измерений должна периодичесl= 2;и оцениватьсn= 3;. Результаты анализов данных и действий по улучшению должны служить исходными данными для процесса анализа со стороны рук = 86;водства.<o:p></o:p> <sp= an style=3D'color:windowtext;mso-bidi-font-weight:normal'>Орг= ;анизация должна определить = 80; установить </sp= an>про= цессы измерения и функциониl= 8;ования системы менеджментk= 2; качества. Удовлетворk= 7;нность заказчика должна испо = 83;ьзоваться в качестве одного из из= 084;еряемых параметров результатоk= 4; действия системы. Организ= ;ация должна прим = 77;нять методы измерения и мониторингk= 2; процессов, необходимыk= 7; для удовлет = 74;орения требований заказчика и для демонст = 88;ации постоянной способностl= 0; процессов удовлетворn= 3;ть поставленнm= 9;м целям. Результаты измерений должны использоваm= 0;ься для поддержаниn= 3; в рабочем состоянии и/или улучшения этих процессов. Данные отче = 90;ы должны указ = 99;вать уполномочеl= 5;ных лиц, ответственl= 5;ых за выпуск продукции.<o:p></o:p>= Следует обеспечить уверенностn= 0; в том, что продукция, которая не соответствm= 1;ет требованияl= 4;, находится под управлениеl= 4;, обеспечиваn= 2;щим предотвращk= 7;ние её непредна = 84;еренного использоваl= 5;ия или поставк = 80;. Механизм, обеспечиваn= 2;щий уверенностn= 0; в том, что несоответсm= 0;вующая продукция находится под управлениеl= 4;, должен быть определен в общесистемl= 5;ой процедуре. Продукция, имеющая нес = 86;ответствия, должна быть:<o:= p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>подвергну= 090;а коррекции или исправлениn= 2; с целью обес= 087;ечения соответствl= 0;я требованияl= 4;, или<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>принята<sp= an style=3D'color:windowtext'> на основании разрешения на отклонен = 80;е (с коррекцие= 081; или исправл = 77;нием или без них), или<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>перерас= ;пределена</sp= an> для разрешенноk= 5;о альтернатиk= 4;ного использоваl= 5;ия, или<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>удалена (отбракован = 72;) как неприемлемk= 2;я.<o:p></o:p> Должны быт= 00; определены ответственl= 5;ость и полномочи= 03; по проведен = 80;ю анализа и принятию решений по несоответсm= 0;виям. Там, где это определено контрактом, информация = 86; предлагаемl= 6;м использоваl= 5;ии или ремонте несоответсm= 0;вующей продукции должна напр = 72;вляться заказчику для получен = 80;я разрешения на отклонение. <o:= p></o:p> Для анализа совершенстk= 4;ования процессов должна быть установленk= 2; общесистемl= 5;ая процедура, направленнk= 2;я на определе = 85;ие эффективноl= 9;ти системы менеджментk= 2; качества и выявление мест, где могут быть сделаны улучшения. Организациn= 3; должна соби = 88;ать данные, появ= 083;яющиеся в результат = 77; действий по = 080;змерению и мониторин = 75;у, а также из лю&#= 1073;ых других прие = 84;лемых источников. <o:p></o:p> Следует постоянно улучшать систему менеджментk= 2; качества, установить общесистемl= 5;ую процедуру, которая определяет использоваl= 5;ие политики ка = 95;ества, целей, резул= 100;татов внутреннегl= 6; аудита, анализа дан = 85;ых, корректируn= 2;щих и предупреждk= 2;ющих действий и анализа со стороны руководствk= 2; в целях подд= 077;ржки постоянных улучшений. Установить процесс, направленнm= 9;й на сокращение или исключе = 85;ие причин несоответсm= 0;вий для предотвращk= 7;ния повторения несоответсm= 0;вий.<o:p></o:p> Общесистеl= 4;ная процедура для процеl= 9;са проведения корректируn= 2;щих действий должна определять требования по:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>идентифика= ;ции несоответсm= 0;вий;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>определени= ;ю причин несоответсm= 0;вий;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>р = 77;ализации всех действий, обусловленl= 5;ых необходимоl= 9;тью обеспечениn= 3; уверенностl= 0; в том, что несоответсm= 0;вия не повторят = 89;я;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>регистрац = 80;и результатоk= 4; предпринятm= 9;х действий;<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>а = 85;ализу эффективноl= 9;ти и регистрациl= 0; предпринятm= 9;х корректируn= 2;щих действий.<o:p></o:p>= Следует установить процесс, направленнm= 9;й на исключениk= 7; причин потенциальl= 5;ых несоответсm= 0;вий требованияl= 4; длn= 3; предупреждk= 7;ния их появлени= 03;. Отчеты системы мен = 77;джмента качества и результаты, полученные из анализа данных, должны использоваm= 0;ься в качестве исходных да = 85;ных для предупреждk= 2;ющих действий. <o:p></o:p> Стандарт ISO<= span style=3D'color:windowtext'> 90003:2004 – Рекомендацl= 0;и по применению стандарта ISO<= span style=3D'color:windowtext'> 9001:2000 для программныm= 3; средств – предназначk= 7;ны для регламентиl= 8;ования менеджментk= 2; при приобретенl= 0;и, поставке, разработке, = 087;рименении, сопровождеl= 5;ии слож = 85;ых программныm= 3; средств и при их обслу= 078;ивании. Стандарт н = 77; содержит ограничениl= 1; и изменений базовых требований ISO 9001:2000 и предлагаетl= 9;я при установленl= 0;и соответствl= 0;я требованияl= 4; комплексов программ:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>к = 72;к части коммерческl= 6;го контракта с другими организациn= 3;ми;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и представлеl= 5;ии полезного продукта дл= 03; рынка;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я использоваl= 5;ия при поддержке процессов организациl= 0; проектов ПС;<o:= p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я учета при встраиваниl= 0; программныm= 3; средств k= 4; комплексы аппаратуры;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и организациl= 0; сервиса программныm= 3; продуктов.<o:p></o:p>= Полное или частичное применение стандарта IS= O 90003 целе = 89;ообразно в различных ситуациях, с учетом технологии, модели жизн = 77;нного цикла, проце= 089;сов разработки, последоватk= 7;льности действий и организациl= 6;нной структуры предприятиn= 3;. Его рекомен = 76;уется применять как поддерж = 82;у процессов программноl= 1; инженерии в </s= pan>IS= O 9001:2000, совме= ;стно со стандарт = 72;ми ISO 12207, <= span lang=3DEN-US style=3D'mso-bidi-font-size:14.0pt;mso-ansi-language:EN-US'>IS= O 15504, ISO 9126, ISO 14598, ISO 15939. <o:p></o= :p> Первые четыре раздела практическl= 0; повторяют содержание аналогичныm= 3; разделов в <sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-ansi-language:EN-US'>ISO<= span style=3D'font-size:14.0pt'> 9001:2000. Структура стандарта ISO<= span style=3D'font-size:14.0pt'> 90003:2004 привязана к разделам и требованияl= 4; в ISO 9001:2000, котор&= #1099;е цитируются = 74; начале кажд = 86;го раздела. Пятый разде = 83; определяет ответственl= 5;ость руководствk= 2;: общие обяза = 85;ности руководствk= 2; управления проектом; политику в области обеспечениn= 3; качества пр = 86;дукции; планированl= 0;е управления проектом; ответственl= 5;ость и полномочи= 03; специалистl= 6;в; анализ прое = 82;тирования со стороны руководствk= 2;. Формулировl= 2;и в ISO 90003 повторяют содержание основного стандарта с очень небольшими комментариn= 3;ми.<o:p></o:p> В шестом разделе – менеджмент ресурсов, более полно комментируn= 2;тся особенностl= 0; управления ресурсами в области про = 75;раммной инженерии. В= 085;имание акцентируеm= 0;ся: на проблема = 93; обеспечениn= 3; ограниченнm= 9;ми вычислителn= 0;ными ресурсами инфраструкm= 0;уры проектов; на компетентнl= 6;сти, квалификацl= 0;и и подготовк = 77; специалистl= 6;в; на управлен = 80;и производстk= 4;енной средой. При этом неоднократl= 5;ы подробные ссылки на тр= 077;бования стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> 12207, ISO 15504,= ISO<= span style=3D'font-size:14.0pt'> 9126, ISO 14598 (см. Приложен&#= 1080;е 1). <o:p></o:p> Наиболее обширным и специфичесl= 2;им, практическl= 0; полностью ориентировk= 2;нным на программныk= 7; продукты, является се = 76;ьмой раздел стандарта. В нем изложен = 86; планированl= 0;е и управлени = 77; процессами = 80; качеством жизненного цикла программныm= 3; средств l= 9; попутными ссылками на рекомендацl= 0;и перечисленl= 5;ых выше стандартов. Рекомендацl= 0;и проектировk= 2;ния и разработк = 80; имеют традиционнm= 1;ю структуру жизненного цикла ПС: входные и выходные данные проц = 77;ссов; анализ требований; = 074;ерификация и валида = 94;ия результатоk= 4;; управление изменениямl= 0; и сопровожд = 77;ние; мониторинг = 80; измерение результатоk= 4;. При этом фор= 084;улировки и цитаты раз= 076;елов ISO 9001 отходят на второй план. Небольшой восьмой раз = 76;ел посвящен измерениям, анализу и совершенстk= 4;ованию процессов и результатоk= 4; управления проектами программныm= 3; продуктов и почти не связан с тре= 073;ованиями ISO 9001.<o:p></o:p> В стандарт = 77; ISO<= span style=3D'font-size:14.0pt'> 90003 имеется два оригинальнm= 9;х приложения полностью о = 90;личающихся от приложен = 80;й в ISO 9001. Приложение А состав= 083;яет обширная таблица, в которой процессам стандарта ISO<= span style=3D'font-size:14.0pt'> 90003 сопост= ;авлены полезные детализируn= 2;щие процессы около 20 основных ст = 72;ндартов жизненного цикла сложных программныm= 3; средств. В таблице при = 83;ожения В сопоставлеl= 5;ы рекомендацl= 0;и по планированl= 0;ю программныm= 3; проектов в стандартах </sp= an>ISO<= span style=3D'font-size:14.0pt'> 90003 и ISO 12207, которые вес= 00;ма близки.<o:p></o:p> Практичесl= 2;и все перечисленl= 5;ые процессы и требования стандартов = 74; данном разделе, конкретизl= 0;рованы в очень подробных рекомендацl= 0;ях процессов (около 500 страниц – седьмой раздел) трех выделенных выше уровне = 81; модел= 080; CMMI= (см. п. 3.1). Он&= #1080; соот = 74;етствуют, регламентl= 0;рованным и детализир = 86;ванным рекомендацl= 0;ям в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9001:2000,&nbs= p; ISO 12207 и основных компонентаm= 3; профи= 083;я стандартов жизненного цикла сложных ПС (см. лекцию 2). Требованияl= 4; в функциона = 83;ьных разделах 4 – 8 стандарта ISO<= span style=3D'font-size:14.0pt'> 9001 могут быть сопоставлеl= 5;ы подобные по содержанию разделы в поэта= 087;ной модели CMMI. Общность процессов и требований состоит в подобии: терминологl= 0;и, структуры, рекомендуеl= 4;ых процессов управления, планированl= 0;я, учета доступных ресурсов, ре= 072;лизации процессов, о= 094;енивания и организациl= 0; специалистl= 6;в. Процессы, которые развиваютсn= 3; и детально комментируn= 2;тся процессами их реализац = 80;и в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9004:2000 и ISO 90003:2004, а также в представлеl= 5;ном выше профил = 77;, включающем около пятид = 77;сяти стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> (см. Приложение 1), однако не всегда предусмотрk= 7;ны в рекомендацl= 0;ях и ссылках CMMI= .<o:p></o:p> При практическl= 6;й реализации проектов и о= 073;еспечении ж= ;изненного цикла сложных ПС = 088;азработчик&= #1072;м и поставщикаl= 4; может быть сложно определить = 80; выделить дл= 03; применения преимущестk= 4;а моделей CMMI или= профи= 083;я стандартов </sp= an>ISO. В зависимостl= 0; от традиций предприятиn= 3; и особеннос = 90;ей проекта ПС зачастую целес= ообразно использоваm= 0;ь как основно = 81; полный профил= ь стандартов </sp= an>ISO, а дл&#= 1103; оценивания заказчикамl= 0; уровня зрел = 86;сти менеджментk= 2;, организациl= 6;нного и технологичk= 7;ского обеспечениn= 3; проектов ПС применять конкретные рекомендацl= 0;и CMMI. Эти рекомен = 76;ации могут эффективно использоваm= 0;ься при сертифика = 94;ии качес= ;тва процессов на предприя = 90;иях, обеспечиваn= 2;щих ЖЦ ПС, как альтернатиk= 4;а или наряду с сертификацl= 0;ей по комплекс = 91; стандартов менеджментk= 2; ISO= 9000, в зависимостl= 0; от особенностk= 7;й проекта и тр= 077;бований заявителя н = 72; сертификацl= 0;ю программноk= 5;о продукта и/или технологии обеспечениn= 3; его жизненн = 86;го цикла.<o:p></o:p> При подготовке системы качества предприятиn= 3;, целесообраk= 9;но учитывать и использоваm= 0;ь совокупносm= 0;ь рекомендацl= 0;й ряда станда = 88;тов, поддерживаn= 2;щих и детализируn= 2;щих базовые ста = 85;дарты серии ISO 9000, в которую входят – ISO 10005, ISO 10006, ISO 10013, ISO 10011. <o:p></o:p>= Стандарт ISO<= span style=3D'color:windowtext'> 10006:1997 – Руководствl= 6; по качеству при управле = 85;ии проектом – содержит принципы управления качеством различных п = 86; содержанию крупных про = 77;ктов. В нем изложены рекомендацl= 0;и по админист = 88;ативному управлению качеством процесса проектировk= 2;ния сложных объектов и в том числе программныm= 3; средств. Приводятся определениn= 3; процесса, продукции и плана управления проектом, а также общие = 093;арактерист&= #1080;ки организациl= 0; и фазы проек= 090;ирования. Обеспечениk= 7; качества управления проектом представлеl= 5;о группой про = 94;ессов, для каждого из которых приводятся = 87;одробные рекомендацl= 0;и по их реализ= 072;ции и контролю качества вы = 87;олнения. <o:p></o:p></spa= n> </= span>В стандарте ISO 10013:1= 995 – Руководящиk= 7; указания по = 088;азработке руководств по качеству = 211; изложены рекомендацl= 0;и по подготовке конкретногl= 6; Руководствk= 2; по качеству, адаптироваl= 5;ного к определен = 85;ым потребностn= 3;м предприятиn= 3; и пользоватеl= 3;ей. Созданное в = 088;езультате Руководствl= 6; должно отражать до = 82;ументирова&#= 1085;ные процедуры системы кач = 77;ства конкретногl= 6; предприятиn= 3; или проекта = 074; соответствl= 0;и с общими тре= 073;ованиями стандартов серии ISO 9000. В этом документе должны быть изложены: це= 083;и конкретной = 89;истемы качества проекта или предприятиn= 3;; документирl= 6;ванные процедуры этой систем = 99;; организациn= 3; процессов утверждениn= 3;, изменения и применения данного Руководствk= 2;. В стандарте предложена = 87;одробная типовая структура и рекомендуеl= 4;ое содержание разделов такого документа. <o:p></o:p> = В стандарте ISO 10005:1995 – Администраm= 0;ивное управление качеством. <sp= an style=3D'mso-spacerun:yes'> Руководящи= 077; указания по Программе качества – представлk= 7;ны конкретныk= 7; рекомендацl= 0;и по структур = 77; и содержани= 02; разделов в П= 088;ограмме обеспечениn= 3; качества продукции, в &#= 1089;оответстви= и с базовыми т= 088;ебованиями стандарта ISO 9001,<s= pan style=3D'mso-spacerun:yes'> а также приме = 88;ы документалn= 0;ного оформления таких Программ. Для эффективноk= 5;о применения его следует = 072;даптироват&= #1100; к характерисm= 0;икам объектов и среды применения конкретногl= 6; предприятиn= 3; или проекта. Прежде всег = 86;, необходимо оставить в рабочей версии этог = 86; стандарта разделы и положения, которые целесообраk= 9;но непосредстk= 4;енно использоваm= 0;ь для обеспечениn= 3; качества ко = 85;кретных изделий. Адаптация стандарта для конкрет = 85;ых предприятиl= 1; или проекто = 74; может выполнятьсn= 3; путем сокращения = 80; конкретизаm= 4;ии некоторых положений. После этого Программа качества должна быть сформироваl= 5;а и оформлена как самостоятеl= 3;ьный регламентиl= 8;ующий документ, согласованk= 2; с заказчико = 84;, утверждена = 88;уководство&#= 1084; предприятиn= 3; и доведена д= 086; сведения всех участников проекта для практическl= 6;го применения. При сертифи = 82;ации системы качества предприятиn= 3; должно проверятьсn= 3; наличие и практическl= 6;е использоваl= 5;ие всех положе = 85;ий утвержденнl= 6;й рабочей версии Прог = 88;аммы качества.<o:p></o:p>= = Груп= па стандартоk= 4; = - ISO 10011:1-3:1990 – Руководящиk= 7; положения п = 86; проверке систем качества – определяет основные требования = 82; процессам и специалистk= 2;м по оценке систем качества предприятиn= 3; на соответс = 90;вие стандартам серии ISO 9000. В них изложены основные принципы, критерии и методики, а также руководящиk= 7; положения для разработки, планированl= 0;я и ведения документацl= 0;и при проверк = 77; систем каче = 89;тва предприятиn= 3;. Определены обязанностl= 0; и ответстве = 85;ность независимыm= 3; инспектороk= 4; по проверке системы кач = 77;ства, требования = 82; ним, порядок и критерии оценки и выбора инспектороk= 4;, их аттестац = 80;и и условия выдачи свидетельств для допуска к инспектироk= 4;анию. Для независ = 80;мой и объективн = 86;й оценки системы качества предприятиn= 3; или проекта рекомендуеm= 0;ся проводить специальныl= 1; отбор испытателеl= 1; – инспектор = 86;в по сертифик = 72;ции. В соответст = 74;ии со стандартом </sp= an>ISO<= span style=3D'font-size:14.0pt'> 10011-2 кандидаты в инсп = 77;кторы по проверке = 089;истем качества должны прод = 77;монстриров&#= 1072;ть способностn= 0; четко и быст= 088;о выражать концепции и идеи в устной и письменно = 81; форме. Они должны пройти обуч = 77;ние, дающее им знания и квалификацl= 0;ю, необходимыk= 7; для проведения испытаний и управления проверками систем каче = 89;тва. <o:p></o:p> <o:p> = ;</o:p> <h1><a name=3D"_Toc508102456"></a><a name=3D"_Toc508102229">3.3. Стандарты о = 90;крытых систем, регламентиl= 8;ующие структуру и интер= ;фейсы программнm= 9;х средств</a> <o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'><o:p> </o:p> Рядом зарубежных организациl= 1; и промышленнm= 9;х фирм под руководствl= 6;м IEEE с 1990 года ведется активная разработка последоватk= 7;льных версий стандартов = 80;нтерфейсов открытых систем POSIX (Port= able operating system<= /span> interfaces). Выполнена большая работа по пересмотру, расширению = 80; реорганизаm= 4;ии около двадцати базовых спе = 94;ификаций POSIX 1990 - 1998 года IEEE 1003. Улучшена с = 80;стематизац&#= 1080;я и структура стандартов, усовершенсm= 0;вовано удобство их применения пользоватеl= 3;ями. В результат = 77; подготовлеl= 5; комплексныl= 1; проект фундаментаl= 3;ьного международl= 5;ого стандарта и = 79; четырех крупных час = 90;ей ISO 9945:1-4:2003 (IEEE 1003.1 – 2003), объемом свыше трех т= 099;сяч страниц. Настоящий стандарт –</spa= n> совмесm= 0;ная разработка </sp= an>IEEE= и The Open <sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-ansi-language:EN-US'>Group</span= >, он явля= 077;тся одновременl= 5;о стандартом </sp= an>IEEE= , станда = 88;том ISO и стандартом </sp= an>Open= Group Technical.<o:p></o:p> = Цель документа – стандартизk= 2;ция в программноl= 1; инженерии обеспечениn= 3; переносимоl= 9;ти программ на уровне исходных те = 82;стов. В нем определены основные интерфейсы операционнm= 9;х систем и окружения, и= 085;терфейсы командного интерпретаm= 0;ора, а также прог= 088;аммы общих утилит. Три отдельных к = 88;упных тома включают: ба= 079;овые определениn= 3;; системные интерфейсm= 9;; команды управления = 80; сервисные программы (утилиты). Кроме того, имеется бол= 00;шой четвертый том общего обоснованиn= 3; выбранных решений системы POSIX. Важными свойствами = 88;азработанн&#= 1099;х программныm= 3; интерфейсоk= 4; являются целостностn= 0;, модул= ;ьность их построен = 80;я и параме = 90;ризуемость</= span>. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Стандарты открытых систем – POSIX регламентиl= 8;уют совокупносm= 0;ь базовых, системных сервисов дл= 03; обеспечениn= 3; унифицировk= 2;нных интерфейсоk= 4; прикладных программ, специфицирl= 6;ванных для языка С, командно= 075;о языка и совокупносm= 0;и служебных п = 88;ограмм. Основная цель </spa= n>– <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>сделат= 100; программы переносимыl= 4;и на уровне различных и = 89;ходных языков. У каждого интерфейса программ существует вызывающая = 80; вызываемая = 89;торона, стандарты POSIX ориентировk= 2;ны преимущестk= 4;енно на формализ = 72;цию вызывающей стороны. Мобильностn= 0; приложений должна обеспечиваm= 0;ься благодаря применению большого чи = 89;ла стандартизl= 0;рованных системных интерфейснm= 9;х сервисов и возможностl= 0; динамическl= 6;го выяснения характерисm= 0;ик целевой платформы и подстройки под них инте= 088;фейсов приложений.<o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При формированl= 0;и концепm= 4;ии стандартов POSI= X </span= >были поставl= 3;ены следующие задачи:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>сод= ействовать облегчению = 80; автоматизаm= 4;ии переноса кода готовы = 93; прикладных программ на иные платфо = 88;мы;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>спо= собствоватn= 0; определениn= 2; и унификациl= 0; интерфейсоk= 4; программныm= 3; компонентоk= 4; заранее при проектировk= 2;нии программныm= 3; средств, а не только в процессе их = 088;еализации;<o:p></= o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>сох= ранять по возможностl= 0; и учитывать все главные, созданные ранее, унасл= 077;дованные и используемm= 9;е программнm= 9;е средства и компоненты;<o:p= ></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>опр= еделять необходимыl= 1; минимум интерфейсоk= 4; компонентоk= 4; и комплексо = 74; программ, дл= 103; ускорения создания и расширения программныm= 3; продуктов, а также для анализа, одобрения и утверждениn= 3; документов;<o:p= ></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>раз= вивать стандарты в направлениl= 0; обеспечениn= 3; коммуникацl= 0;онных сетей, распределk= 7;нной обработки данных и защиты= информациl= 0;;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>рек= омендовать ограничиваm= 0;ь использоваl= 5;ие объектного кода для про= 075;рамм в простых системах.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Разработчl= 0;ки новых версий стандартов группы POSIX тщаm= 0;ельно учитывали и = 93; предысториn= 2; и наличие множества унаследоваl= 5;ных, созданных и развиваемыm= 3; компонентоk= 4; и комплексо = 74; программ, удовлетворn= 3;ющих более ранни = 84; версиям эти = 93; стандартов. = 042; процессе развития стандартов соблюдался принцип обратной совместимоl= 9;ти – новые инте= 088;фейсы добавлялисn= 0; так, чтобы они не конфл= 080;ктовали со старыl= 4;и. Однако полностью это не удалось реа = 83;изовать, и некоторые интерфейсы = 74; повторно применяемыm= 3; программаm= 3; необходимо корректироk= 4;ать при их испол= 100;зовании в новых прог= 088;аммных средствах. <o:p></o:p= > Цель данно = 81; версии стандарта состоит в том, чтобы минимизироk= 4;ать дополнителn= 0;ную работу для разработчиl= 2;ов прикладных программ. Те= 084; не менее, поскольку к = 72;ждая историческk= 2;я реализация стандарта н = 77;избежно подвергаетl= 9;я изменению, пусть даже н= 077;значительн&= #1086;му, прикладным программам также неизб = 77;жно предстоит изменяться, чтобы прийт = 80; в соответст = 74;ие. Концептуалn= 0;но, этот стандарт описывает набор фундаментаl= 3;ьных услуг, необходимыm= 3; для эффективноl= 1; разработки прикладныm= 3; программ. Доступ к эти= 084; услугам обеспечиваl= 3;ся определениk= 7;м интерфейса, = 089; использоваl= 5;ием языка программирl= 6;вания Cи, процессора командного языка, и стандартныm= 3; сервисных программ (утилит), кото&= #1088;ые устанавливk= 2;ют стандартнуn= 2; семантику и синтаксис интерфейсоk= 4;. Этот станда = 88;т предназначk= 7;н для всех, кто по роду свое= 081; деятельносm= 0;и связан с операционнm= 9;ми системами, базирующl= 0;мся на UNIX. <o:p></o:p> Цель состояла также в том, чтобы продвинуть мобильностn= 0; прикладных программ по всей област = 80; применения операционнl= 6;й системы UNIX, развивая ясный, после= 076;овательный, и однозначныl= 1; стандарт дл= 03; спецификацl= 0;и интерфейса переносимоl= 1; операционнl= 6;й системы, основанной на документ = 72;ции системы UNIX. Этот стандарт систематизl= 0;рует все существующl= 0;е типовые формулировl= 2;и операционнl= 6;й системы UNIX. Стандарт бы = 83; разработан для того, чтобы прогр = 72;мма, написанная = 80; транслировk= 2;нная для исполне = 85;ия в одной конкретной версии ОС, могла быть также транс = 83;ирована для другой версии ОС. Однако этот стандарт не = 075;арантирует, что используемm= 9;й код (объектн= 099;й) даст соотве = 90;ствующий результат при другой ОС, нежели той, для которой программа была трансл = 80;рована, даже при идентичном аппаратном обеспечениl= 0;.<o:p></o:p> Разработчl= 0;ки данного стандарта стремились добиться возможностl= 0; наиболее широкого применения данного стандарта к = 86; всему диапа = 79;ону уже существ = 91;ющих и потенциал= 00;ных операционнm= 9;х систем. Однако существоваl= 3;о согласованl= 5;ое мнение по поводу того, какой набор функций, типов, определениl= 1; (дефиниций) и концепций предназначk= 7;н для формиро = 74;ания того интерфейса, который является об = 97;им для большинствk= 2; историческl= 0; сложившихсn= 3; типов реали = 79;ации ПС. Предыдущие стандарты и их модифика = 94;ии выявили множество несогласовk= 2;нных областей, чт= 086; в основном устранено = 74; данном вари = 72;нте. Пересмотреl= 5;ное издание стандарта стремится минимизироk= 4;ать количество изменений, касающихся реализаций, которые соответствm= 1;ют более ранни = 84; версиям одобренных стандартов, необходимыm= 3; для приведения их в соответ= 089;твие с настоящим стандартом. <o:= p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Новую версию международl= 5;ых стандартов POSIX составляют аннотироваl= 5;ные ниже четыре части стандартов </sp= an>ISO 9945:1-4:2003 – ИТ. Интерфейсы = 87;ереносимых операционнm= 9;х систем. Ч.1. Базовые определениn= 3;. Ч.2. Системные интерфейсы. Ч.3. Команды управления = 80; сервисные программы. Ч 4. Обоснованиk= 7;.<o:p></o:p> Стандарт ISO 9945-1:= 2003 <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- содержит основные концептуалn= 0;ные определениn= 3; и подробные пояснения м = 77;тодов реализации интерфейсоk= 4; для обеспеч = 77;ния мобильностl= 0; компонентоk= 4; и комплексо = 74; программ, общее для всех томов оглавление стандарта, в том числе сервисные соглашения = 80; определениn= 3; заголовков языка Си. В большом разделе <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- концепция изложены: базовые директории; файловая иерархия; сетевое взаимодейсm= 0;вие; измерение времени и синхронизаm= 4;ия; процессы повторного использоваl= 5;ия компонентоk= 4;; политика очередей и применение семафоров. Далее выдел = 77;ны разделы:<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>описание синтаксиса = 80; организациl= 0; данных в файлах для с= 080;стемных интерфейсоk= 4; и взаимодейсm= 0;вия с терминаламl= 0;;<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>характериl= 9;тики переносимm= 9;х компонентоk= 4;, язык кодиро = 74;ания, описание фа = 81;лов;<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>локальные переменные, определениn= 3; и грамматик = 72;;<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>описание переменных окружения, интер= ;национализ = 72;ция переменных;<o:p= ></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>контекстнl= 6;-независимы&#= 1081; синтаксис представлеl= 5;ия характерисm= 0;ик переменных компонентоk= 4;, определениn= 3; регулярных выражений, генерация требований, базис и грам= 084;атика выражений, продленные выражения; <o:p></o:p= > <![if !supportLists= ]>- = &nb= sp; <![endif]>структура директорий, файлов и устройств, т= 080;пы терминалов;<o:p= ></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>базовые интерфейсы типов терминалов, параметры в = 86;зможных устройств;<o:p></o:p>= <![if !supportLists= ]>- = &nb= sp; <![endif]>конвенция и руководствl= 6; по синтаксису аргументов утилит;<o:p></o:p> <![if !supportLists= ]>- = <![endif]>содержаниk= 7; функций прототипов, описа= ;ние символьных констант, макросы, препроцессl= 6;ры, типы опреде = 83;ений, форматы вхо = 76;ов. <o:p></o:p> </spa= n>Сm= 0;андарт ISO 9945-2:2003 <sp= an style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- Системные интерфейсы – уто= чняет и детализир = 91;ет: концепцию переносимоl= 9;ти и принципы е= 105; обеспечениn= 3; путем унифи = 82;ации интерфейсоk= 4; прикладных программ с о= 087;ерационным&= #1080; системами, </s= pan>функции обслуживанl= 0;я, ориентировk= 2;нные на язык программирl= 6;вания Си, функционалn= 0;ные вопросы, в том числе мобильностn= 0;, обработка ошибок, и устранение ошибок.&nbs= p; Он содержи = 90; три крупных раздела:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>введение; <o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>содержани= ;е основной информации; <o:= p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>системные интерфейсы. <o:= p></o:p> Документ предназначk= 7;н для разрабо = 90;чиков приложений, = 074; которых необходимо обеспечить мобильностn= 0; программ и данных, для разработчиl= 2;ов и пользоватеl= 3;ей операционнm= 9;х систем, а также для покупателеl= 1; вычислитеl= 3;ьной техники и программныm= 3; средств. Основная цель станда = 88;та <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-fareast-font-family:"MS Mincho";mso-hansi-font-family: "Times New Roman";mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > унифицировk= 2;ть интерфейсы приложений и связи= с окружением ядра операционl= 5;ой системы путем формализацl= 0;и описаний внутренних = 80; внешних интерфейсоk= 4; на базовом языке программирl= 6;вания Си. Концептуаl= 3;ьно представлеl= 5;о описание синтаксиса = 80; семантики взаимосвязk= 7;й, испол= ;ьзуемых при проектировk= 2;нии переносимыm= 3; прикладных программ. Унификациn= 3; ориентировk= 2;на на версии UNIX, а такk= 8;е на другие операционl= 5;ые системы, совместимыk= 7; по интерфей = 89;ам с версиями UNIX. Разработчиl= 2;и стандарта стремились предусмотрk= 7;ть все потенциалn= 0;но возможные фун-кции</sp= an> взаимодейl= 9;твия прикладных программ с ядром ОС на различных аппаратных платформах, = 074; автономных, сетевых и ра= 089;пределенны&= #1093; информациоl= 5;ных системах. Для этого предс = 90;авлено содержание 1123 интерфейсоk= 4;, включающих: описание, типовую структуру, возможные ошибки, примеры и обоснованиk= 7; каждого. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Языково-ор = 80;ентированн&#= 1099;е услуги= и интерфейсы для языка Си в стандарте = 89;остоят из двух частей: ядра взаимодейсm= 0;вующего с ядром опера= ;ционной системы на языке Си и расширения для взаимодейсm= 0;вия с прикладны = 84;и программамl= 0;, реализоваl= 5;ными на различны = 93; языках. Первоначаl= 3;ьная, жесткая ори = 77;нтация стандартоk= 4; POSIX на ОС UNIX&n= bsp; в последую = 97;ем изменилась = 80; расшириласn= 0; на любые опе= 088;ационные среды, обесп= 077;чивающие реализацию концепции о = 90;крытых систем. Отмечается целесообраk= 9;ность применения для взаимод = 77;йствия с внешней средой= концепции и совокупноl= 9;ти стандартов, являющихся развитием базовой эталонной модели взаимосвяk= 9;и открытых систем (ВОС) <= span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- ISO 7498<s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>.<o:p></o:p> В третьей части стандаl= 8;та ISO 9945-3:2003 – Основные кома= нды управления = 80; сервисные программы (Shell and utilities) – изложено конкретное представлеl= 5;ие команд опер = 72;ционной системы и утилит, обесп= ;ечивающих унифицировk= 2;нное взаимодейсm= 0;вие с мобильным = 80; прикладнымl= 0; программаl= 4;и, опред= еления для стандартноk= 5;о источника кодового уровня интерфейса командного интерпретаm= 0;ора ("shell") и стандартныk= 7; утилиты для прикладных программ. С= 090;андарт содержит че = 90;ыре раздела: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>введение; <o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>описание языка управления; <o:= p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пакет обслуживанl= 0;я окружения; <o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>сервисные программы – утилиты. <o:p></o:p> Цель этой части стандарта к = 86;нкретизиро&#= 1074;ать интерфейсы прикладных программ на уровне команд, для интерпретаm= 0;ора командного языка, и полный набо = 88; сервисных п = 88;ограмм – утилит. Он специфицирm= 1;ет интерфейсы операционнm= 9;х систем на уровне прог = 88;аммных текстов и к= 086;дов. Стандартизl= 0;рованный командный язык = Shell – средство дл= 03; подготовки небольших мобильных процедур и и= 093; быстрой интерактивl= 5;ой отладки. В ра&#= 1079;витой среде, возможн= ;о объединять команды в цепочки с фильтрациеl= 1; промежуточl= 5;ых результатоk= 4;. Каждая утилита содержит: оп= 080;сание структуры; применение; операнды; вх= 086;дные файлы; окруж= 077;ние. Факультатиk= 4;ные утилиты расширяют возможностl= 0; для пользоватеl= 3;ей мобильных приложений по связи с внешним окр = 91;жением. В терминах я= 079;ыка Си (стандарт <s= pan style=3D'mso-bidi-font-weight:bold'>ISO 9899:1990) описаны языково-нез = 72;висимые услуги инте = 88;фейсов для переносимыm= 3; приложений = 80; связи с внешним окруж= ;ением при представлеl= 5;ии интерфейсоk= 4; приложений на различны = 93; языках высо = 82;ого уровня. Команды и утилиты содержат конкретные механизмы н = 72; уровне операторов для выполнения операций: сравнения, вывода на пе= 095;ать и на экран файлов, редактироk= 4;ания файлов, вычисления выражений, сортировки данных, опре= 076;еления очередностl= 0; исполнения сигналов и д= 086;ступа к информациl= 0; о среде. Можно выде = 83;ить:<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ути= литы среды взаимодейсm= 0;вия программ;<o:p></o:p>= <![if !supportLis= ts]>- = <![endif]>упр= авляющие утилиты, поддерживk= 2;ющие мобильностn= 0; программ и связь внешних пользоватеl= 3;ей с асинхронн = 99;ми терминалаl= 4;и;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ути= литы для взаимодейсm= 0;вия комплексов = 87;рограмм;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>язы= ково-незави = 89;имые системные услуг= ;и для прикладных программ на = 085;ескольких языках программирl= 6;вания высокого уровня. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> Четвертая часть стандарта ISO 9945-4:2003 – Обоснованиk= 7; – содержит группу из пя= 090;и крупных приложений:<o:p= ></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>обоснованl= 0;е базовых определениl= 1; – приложени = 77; А;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>обоснованl= 0;е системных интерфейсоk= 4; – приложени = 77; В;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>обоснованl= 0;е команд управления = 80; сервисных программ-ут = 80;лит – приложени = 77; С;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>рассмотреl= 5;ие переносимоl= 9;ти – приложени = 77; D;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>рассмотреl= 5;ие субпрофl= 0;лей – приложени = 77; Е.<o:p></o:p> В перечисленl= 5;ых приложенияm= 3; подробно разъясняютl= 9;я базовые положения с = 90;андартов POSIX, обосновываn= 2;тся формализовk= 2;нные в них решения. Простра= ;нные пояснения, которые не слишком вписывалисn= 0; в остальные части документа, содержат историческl= 0;е комментариl= 0; по тексту стандарта, разъяснениn= 3; причин, по которым те или иные сво= 081;ства, признаки и компоненты были включены в стандарт или были отвергнуты разработчиl= 2;ами.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Параллельl= 5;о с подготовкоl= 1; и внедрение = 84; новых четырех ста = 85;дартов группы POSIX, действуют = 80; применяютсn= 3;, представлеl= 5;ные ниже, утвержденнm= 9;е базовые междунаро = 76;ные стандарты, углубляющl= 0;е некоторые возможностl= 0; и облегчающиk= 7; создание мо = 73;ильных приложений.</sp= an><o:p></o:p></span= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = 42; стандарте </s= pan>ISO 14252:1996</s= pan> <span style=3D'font-size:14.0pt;font-= family: Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font-family:"MS = Mincho"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > Руководствl= 6; по POSIX окруженl= 0;ю открытых си = 89;тем (OSE) – изложена идеология и модел= ;ь создания м = 86;бильных программныm= 3; средств, которое детализируk= 7;т для пользов = 72;телей модель комплекса стандартов POSI= X, а также взаимодейсm= 0;вующих с нимl= 0; стандартов де-юре, де-фак&= #1090;о и спецификацl= 0;й, необходимыm= 3; для создани= 03; переносимыm= 3; приложений. Модель отра = 78;ает принципы построения интерфейсоk= 4; прикладных программ с платформой </sp= an><span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- операционнl= 6;й системой, через которую осуществлn= 3;ется взаимодейl= 9;твие с компонентаl= 4;и внешнего окружения. С= 095;итается, что прикладные программы н = 77;посредстве&#= 1085;но не взаимодейсm= 0;вуют с внешним окружением, а связаны с ни= 084; только чере = 79; операционнm= 1;ю систему. Разработка приложений предполагаk= 7;тся в кросс-р = 77;жиме, то есть платформа разработки R= 11; инструментk= 2;льная может не сов= 087;адать с платформо = 81; исполнения (применения) программ (объектной – целевой). Результат компиляции программы н = 72; инструментk= 2;льной платформе может быть перенесен для исполне = 85;ия на целевую платформу. <o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Определяюm= 7;ими являются дв = 72; интерфейса между тремя = 073;азовыми компонентаl= 4;и: между прикладныl= 4;и программаl= 4;и и платформой <span style=3D'font-size:14= .0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font= -family: "MS Mincho";mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"T= imes New Roman"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > операционl= 5;ой системой (API) l= 0; между платф = 86;рмой и внешним ок= 088;ужением (EEI). Определенm= 9; общие= ; функции <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- услуги платформы для этих k= 4;заимодейст= 074;ий. Внешнее окружение включает ко = 84;поненты человеко-ма = 96;инного взаимодейсm= 0;вия с пользоватеl= 3;ями, компоненты информациоl= 5;ного взаимодейсm= 0;вия с внешними устройстваl= 4;и ЭВМ и с компонентаl= 4;и, обеспечиваn= 2;щими коммуникацl= 0;ю с внешней средой. Эти интерфейсы и услуги более детально формализовk= 2;ны соответствm= 1;ющими стандартамl= 0; POSIX.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = Стандар= ;т включает также общие принципы и руководствl= 6; по формированl= 0;ю и описанию сложных согласованl= 5;ых профилей и по обеспеченl= 0;ю непро= ;тиворечиво = 89;ти их интерфейсоk= 4; с внешним окружением.<o:p= ></o:p> <![if !supportLis= ts]>- = <![endif]>под= держивающиk= 7; непосредстk= 4;енное взаимодейl= 9;твие прикл= ;адных программ с пользоватеl= 3;ями, регламентиl= 8;ующие интерфейсы = 89; виртуальныl= 4;и терминаламl= 0; и графическ = 80;е системы;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>обеспечи&= #1074;ающие администраm= 0;ивное управление файловыми с = 80;стемами и различным = 80;, в том числе, распределеl= 5;ными базами данных;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>регламен&= #1090;ирующие телекоммуl= 5;икацию и обмk= 7;н данными на верхних уровнях эталонной модели ВОС;</s= pan><o:p></o:p> <![if !supportLis= ts]>- = <![endif]>обе= спечивающиk= 7; аттестацию и безl= 6;пасность применения = 80;нформацион&#= 1085;ых технологий, программ и данных в соответствl= 0;и со стандарт = 72;ми ВОС и криптографl= 0;и.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> Станд= 072;рт ISO 13210:1998</s= pan> <span style=3D'font-size:14.0pt;font-= family: Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font-family:"MS = Mincho"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > Методы тестированl= 0;я для оценки соответстk= 4;ия стандартам POSI= X <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- со&= #1076;ержит общую методологиn= 2; тести= ;рования для проверки соответстk= 4;ия интерфейсоk= 4; прикладных программ ст = 72;ндартам POSIX. Представлk= 7;ны принципы формироваl= 5;ия наборов тесто= ;в и предлагаетl= 9;я методика развития си = 89;темы тестов для контроля со = 79;даваемых приложениl= 1; на соl= 6;тветствие ISO 9945. В методе тестированl= 0;я выделены: по= 076;готовка тестов; процедуры тестироваl= 5;ия; оформление докум= ;ентов, удостоверяn= 2;щих соответстk= 4;ие станд= ;артам. Определены и кратк= ;о представлеl= 5;ы три основны = 93; уровня сложности тестированl= 0;я: исчер= ;пывающий; достаточнl= 6; полный; оцен= 086;чный – для установленl= 0;я общих характерисm= 0;ик качества. Подчеркивk= 2;ется, что предлагаемm= 9;е методы не гарантируn= 2;т абсолютное соответствl= 0;е стандартам, так как исчерпываюm= 7;ее тестированl= 0;е невозможно по техническиl= 4; и экономиче = 89;ким причинам. Приводятся рекомендацl= 0;и по:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>кла= ссификации тестовых сценариев и утверждениl= 1;;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>под= готовке описаний детерминиl= 8;ованных тестов и тестов для проверки структурныm= 3; конструкциl= 1;;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>код= ированию и представлk= 7;нию результатl= 6;в тестироваl= 5;ия во взаимосвязl= 0; с исходными тестами;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>фор= мированию удостовереl= 5;ия о соответст = 74;ии интерфейсоk= 4; прикладных программ стандартам POSI= X.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = 42; стандартах POSIX даются ссылки на многие стандарты ISO, ANSI и де-факто. В ре&= #1079;ультате полная совокупносm= 0;ь стандартов, поддерживаn= 2;щих проектировk= 2;ние мобильl= 5;ых программ в разных классах отк = 88;ытых систем, возрастает. В конкретных прикладных разработкаm= 3; каждый раз необходима только неко = 90;орая, относителn= 0;но небольшая часть= ; из ниm= 3;, которую цел = 77;сообразно выделять в соответствm= 1;ющий проблемно-о = 88;иентирован&#= 1085;ый профиль. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n><o:p></o:p> <o= :p></o:p> <h1> <= /span><a name=3D"_Toc508102457"></a><a name=3D"_Toc508102230">Лекция 4. Системное проектировk= 2;ние программныm= 3; средств</a></h1> <o:p> </o:p> <h1> &n= bsp; <a name=3D"_Toc508102458"></a><a name=3D"_Toc508102231">4.1. Цели = 80; принципы системного проектировk= 2;ния программнm= 9;х средств</a></h1> </spa= n><o:p></o:p> Комплекс ф = 86;рмально организоваl= 5;ных мероприятиl= 1; по достижен = 80;ю единой цели создания сложной системы с требуемыми = 93;арактерист&#= 1080;ками качества при ограниченнm= 9;х ресурсах получил название = - проект. Цель управления проектом = - рациональнl= 6;е использоваl= 5;ие и предупрежk= 6;ение потер= ;и ресурсов путем сбалансироk= 4;анного распределеl= 5;ия их по частны= 084; работам на протяжении всего жизненного цикла объек = 90;а с заданным качеством. Управлениk= 7; проектом = - это особый вид деятельносm= 0;и, включающий = 87;остановку задач, подготовкm= 1; решений, плани= ;рование, организациn= 2; и стимулировk= 2;ние специалистl= 6;в, контроль хода работ и использоваl= 5;ия ресурсов пр = 80; создании сложных систем.<o:p></o:p> = Целевое управление проектами возникло из необходимоl= 9;ти разрабатывk= 2;ть и реализовывk= 2;ть сложные системы с заданными функциями в максимальнl= 6; короткие сроки при ограниченнm= 9;х ресурсах. Критическl= 0;м параметром планированl= 0;я и управлени= 03; проектами обычно является вр = 77;мя. Поэтому в лекциях по программноl= 1; инженерии большое внимание со = 89;редоточено на конкретном планированl= 0;и сложных проектов, длительносm= 0;ь разработки которых могут= ; соста= ;влять несколько месяцев или даже годы. Задачи целев= ;ого управлениn= 3; такими работами = - сводитn= 0; воедино усилия исполнителk= 7;й - сп = 77;циалистов разной квал = 80;фикации, подрядчикl= 6;в и субподряд = 95;иков, добиваясь, чтобы они выступали как команда при создани = 80; компонентоk= 4; систем, а не как разрозн = 77;нная группа функ = 94;иональных специалистl= 6;в. В результате должны обеспечиваm= 0;ься концептуаl= 3;ьная целос= ;тность системы и высокое кач = 77;ство решения главных задач при сб= 072;лансирован&= #1085;ом использоваl= 5;ии ресурсов на все функционаl= 3;ьные задачи. <o:p></o:p> Для интеграции усилий спец = 80;алистов и эффективноk= 5;о использоваl= 5;ия ресурсов проекта долже= ;н выделяться лидер -</span= > менеджер, управляющиl= 1; проектом. Он должен акти = 74;но участвоватn= 0; в планированl= 0;и, организациl= 0; и контроле основных внутренних = 80; внешних организациl= 6;нных мероприятиl= 1;, необходимm= 9;х для достиже = 85;ия основной цели проект = 72;. Все рk= 7;сурсы и исходные данные, необходимыk= 7; для эффекти = 74;ного выполнения проекта, управ= ;ляющий получает от функционалn= 0;ных подразделk= 7;ний и специалистl= 6;в. Задача= менеджера проекта наряду с прямыми воз = 76;ействиями на подчиненныm= 3; и координациk= 7;й их работ = - стимулироk= 4;ать и контролир = 86;вать активность прямых= горизонтаl= 3;ьных связей межд = 91; исполнителn= 3;ми частных работ. Для того чтобы п= 088;оцесс достижения целей был рациональнm= 9;м, лицо, принимающеk= 7; решение (управляющи = 81;) должно имет= 00; выбор среди альтернатиk= 4;ных действий, ведущих к цели. Наличи= 077; альтернатиk= 4; и сомнения п= 086; поводу того,<sp= an style=3D'mso-spacerun:yes'> какая из них лучше,<s= pan style=3D'mso-spacerun:yes'> определяюm= 0; возможностn= 0; эффективноk= 5;о решения проблем и оптимизациl= 0; путей их дос= 090;ижения.<o:p></o:p> Методологl= 0;ческой базой целев = 86;го планированl= 0;я и управлени= 03; проектами П = 57; является системный а = 85;ализ, который предполагаk= 7;т:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 73;следование объектов и среды проектировk= 2;ния, для предваритеl= 3;ьной формализацl= 0;и целей, назначения = 80; задач проекта ПС;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>и = 89;следование и сопоставлk= 7;ние альтернатl= 0;вных действий, к= 086;торые должны приводить к достижению поставленнm= 9;х целей проек = 90;ирования;<o:p></o:p></sp= an> <![if !supportLists]>- &nb= sp; <![endif]>с = 88;авнение альтернатиk= 4; по велич= ;ине достигаемоk= 5;о эффекта проекта в за= 074;исимости от затра= ;т на его достижениk= 7; (желательн = 86;, по показателn= 2; "эффективно= ;сть/<sp= an style=3D'font-size:14.0pt'>стоимос= ;ть");<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 95;ет и анализ влияния неопределk= 7;нностей характериl= 9;тик альтернатиk= 4;, определяющl= 0;х их выбор, на эффект проекта.<o:p></o:p> Чтобы найт = 80; и проанализиl= 8;овать все разумны = 77; альтернатиk= 4;ы, обычно нед = 86;статочно одного специалистk= 2;, и неоk= 3;ходимо участие в сисm= 0;емном анали= ;зе специалистl= 6;в разной квалификацl= 0;и. Не во всех систем = 72;х и задачах оказываетсn= 3; доступным точный коли = 95;ественный анализ. Во многих, чаще всего особенно сл = 86;жных случаях, приходится ограничиваm= 0;ься качественнm= 9;м анализом свойств, фак= 090;оров и их влияния<sp= an style=3D'mso-spacerun:yes'> на конеч= ;ный результат и возможный эффект прое = 82;та. Поэтому оптимизациn= 3; решений и выбора альтернатиk= 4; может ограничиваm= 0;ься оценкой логических суждений экспертов. Б= 072;зой эффективноk= 5;о управления проектом является план, в котором задачи исполнителk= 7;й частных работ должн = 99; быть согласованm= 9; с выделяемы = 84;и для них ресурсами, а также между собой по результатаl= 4; и срокам их достижения. <o:p></o:p> Основна= ;я цель системного проектировk= 2;ния в программноl= 1; инженерии = - подготl= 6;вить, обосновать = 80; согласоватn= 0; замыслы и ре= 096;ения заказчика (потребител= 03;) и разработч = 80;ка (поставщика) о необходимоl= 9;ти, направлениn= 3;х и концепции создания ил = 80; модернизацl= 0;и существующk= 7;го ПС и изменен= 080;ях его качества. Мет&= #1086;ды и средства системного проектировk= 2;ния должны подготавлиk= 4;ать эффективнуn= 2; технологичk= 7;скую базу для обеспечениn= 3; всего жизненного цикла ПС тре= 073;уемого качества. Характерисm= 0;ики комплексов = 87;рограмм должны анализировk= 2;ться и формулиро = 74;аться в начале их жизненного цикла и определять эффективноl= 9;ть всех послед = 91;ющих процессов. Результатоl= 4; этих работ должны быть = 089;истемный проект, техн= 080;ческое задание и контракт на продолжениk= 7; разработки ПС или решен= 080;е о её нецелес= 086;образности и прекращениl= 0;. <o:p></o:p> Системное проектировk= 2;ние сложных комплексов программ яв = 83;яется фундаментоl= 4; для обеспечениn= 3; функционалn= 0;ной адекватносm= 0;и требованияl= 4; всего жизненного цикла ПС. От полноты и тщательносm= 0;и системного проектировk= 2;ния зависит эффективноl= 9;ть реализации функций сис = 90;емы и степень удовлетворk= 7;ния ожиданий и требований заказчика и пользоватеl= 3;ей. В последоватk= 7;льности выработки и подготовки = 82; реализации этих требов = 72;ний далее рассматривk= 2;ются в оснl= 6;вном три крупных этапа: <o:p></o:p> <![if !support= Lists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>о = 73;следование, системный анализ существующk= 7;й системы и выяk= 4;ление её недостат = 82;ов; <o:p></o:p> <![if !support= Lists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>о = 73;общение результатоk= 4; системного анализа и создание предваритеl= 3;ьной концепции новой или модернизирl= 6;ванной системы и её программныm= 3; средств;<o:p></o:p> <![if = !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>&#= 1088;азработка системного проекта комплекса программ и базы данных, определяющk= 7;го и конкретиз = 80;рующего цель, назнач= 077;ние и методы дальнейшегl= 6; детального проектировk= 2;ния и всего жизненного цикла ПС. <o:p></o:p> На этих этапах при относительl= 5;о небольших затратах должна определятьl= 9;я экономичесl= 2;ая эффективноl= 9;ть и рентабельнl= 6;сть всех послед = 91;ющих больших затрат ресурсов в жизненном цикле системы и могут быть предотвращk= 7;ны значительнm= 9;е потери ресурсов вследствие плохого пла = 85;ирования и неопредел = 77;нностей при реализации проекта. Системное проектировk= 2;ние способно остановить = 85;ерентабель&#= 1085;ое развитие проектов систем и изб= 077;жать заказчикам = 80; разработчиl= 2;ам на них крупных затрат. В то ж = 77; время, на базе рекоме = 85;дуемых при проектировk= 2;нии методов, инс= 090;рументальн&= #1099;х средств и стандартов, может и должен быт= 100; подготовлеl= 5; и обеспечен = 076;лительный, эффективныl= 1; жизненный цикл и совер= 096;енствовани&= #1077; множества версий высо = 82;окачествен&#= 1085;ых ПС и их компонентоk= 4; при реализа = 94;ии на различны = 93; аппаратных = 80; операционнm= 9;х платформах. = 050;онечный результат с = 80;стемного проектировk= 2;ния должен такж = 77; положительl= 5;о отражаться на системах обеспечениn= 3; качества, безопасносm= 0;и и защиты, на р&= #1072;ционально организоваl= 5;ных коллективаm= 3; квалифицир&#= 1086;ванных специалистl= 6;в, способных обеспечить весь жизнен = 85;ый цикл ПС. <o:p></o:p> Тщательноk= 7; и полноценноk= 7; системное проектировk= 2;ние выгодно с позиции ускорения разработок, предотвращk= 7;ния ошибок, обеспечениn= 3; эффективноl= 9;ти всего жизне = 85;ного цикла и высокого качества сл = 86;жных проектов комплексов программ в у= 089;ловиях ограниченнm= 9;х ресурсов. = Инициа = 83;изация системного проектировk= 2;ния может осуществляm= 0;ься заказчикамl= 0;, потенциальl= 5;ыми пользоватеl= 3;ями или разрабо = 90;чиками проектов ПС, которые желают получить достаточно четкое представлеl= 5;ие о возможных функциях и будущем жизненном цикле определеннl= 6;го проблемн= ;о-ориен-ти= 088;ованного комплекса программ и б= 072;зы данных. <o:p></o:p></span= > Системное проектировk= 2;ние далее структурирl= 6;вано, и методолог = 80;я его реализа = 94;ии отражает следующие проблемы, процессы и м= 077;тоды: <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>ц = 77;ли и принципы системного проектировk= 2;ния сложных про = 75;раммных средств для обеспечениn= 3; их последующеk= 5;о жизненного цикла в информациоl= 5;ных системах;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>п = 86;дготовку к непосредстk= 4;енному детальному проектировk= 2;нию, разработке = 80; всему жизненному циклу компл = 77;кса программ и базы данных для информа = 94;ионной системы; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 89;новы предваритеl= 3;ьного структурноk= 5;о проектировk= 2;ния и совl= 8;еменных технологий системного анализа и проектировk= 2;ния сложных комплексов программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды разработки требований = 82; характерисm= 0;икам качества и распределеl= 5;ия ресурсов, необходимыm= 3; для реализации проектов сложных ПС и баз данных;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>з = 72;дачи и принципы системного проектировk= 2;ния обеспечениn= 3; безопасносm= 0;и и защиты комплексоk= 4; программ от различных у = 75;роз;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1087;ланировани= е жизненного цикла и управление качеством ПС, а также выбор инструментk= 2;льных средств для поддержки всего их ЖЦ;<o:p></o:= p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тодики системного проектировk= 2;ния сложных ПС и требований = 82; их качеству, а также структура и содержание документов, отражающих = 88;езультаты выполненныm= 3; работ;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;рганизацию и подготовк = 91; специалистl= 6;в, способных обеспечить создание де = 90;ального проекта и всего жизненного цикла ПС, с требуемым качеством. <o:p></o:p> Непреры= ;вное повышение уровня автоматизаm= 4;ии в ряде систе= 084; при подготовке = 80; принятии ответственl= 5;ых решений возлагает все большие = 092;ункции на программ = 85;ые средства с соответствm= 1;ющими базами данных. В результате проблема обеспечениn= 3; качества и б= 077;зопасности их функцион = 80;рования l= 9;двигается к лицам, разрабатывk= 2;ющим системные проекты, мет= 086;ды и программн = 99;е средства дл= 03; автоматизаm= 4;ии, подготовки = 80; реализации ответственl= 5;ых решений. Одновременl= 5;о повышаются требования к уро= вню ответственl= 5;ости и системной квалификацl= 0;и лиц, реализующиm= 3; комплексы программ, от которых зачастую зависят ошибки стра = 90;егически важных решений, так как некотор = 99;е простейшие системные и техническиk= 7; ошибки этих лиц при создании программ мо = 75;ут приводить к большому ущербу или даже катаст = 88;офам. <o:p></o:p> Непреду= ;смотренные при системном проектировk= 2;нии ситуации и возможные дефекты про = 75;рамм являются по = 90;енциальным&#= 1080; источникамl= 0; отказов и аварий= при примен = 77;нии ряда систем. Массовая практика, ко= 075;да заказчик не может сформулироk= 4;ать четкие требования = 82; функциям и б= 077;зопасности ПС, а разработчиl= 2; не понимает,<sp= an style=3D'mso-spacerun:yes'> что нужно заказчику, п= 088;иводит к длительномm= 1; процессу разработки проектов с множеством дефектов и ошибок, на устранение которых расходуютсn= 3; большие ресурсы. В результате многие системы не соответствl= 6;вали исходному назначению = 80; первоначалn= 0;ным спецификацl= 0;ям, не укладывалиl= 9;ь в графики и бюджет разр = 72;ботки. Поэтому значительнl= 6; возросла необходимоl= 9;ть освоения всех соврем = 77;нных методов и методик предупреждk= 7;ния системных дефектов, об= 077;спечения высокого качества программ с самого начала их разработки. Многие ошибки, обусловленl= 5;ые неопределk= 7;нностью или некорректl= 5;остью техническиm= 3; заданий и спецификацl= 0;й, могут и должны быть выявлены на ранних= стадиях системного проектировk= 2;ния, что способствm= 1;ет его ускорению и повышению качества. Обширной практикой доказано, чт= 086; обнаружениk= 7; и устранени = 77; ошибок и дефектов в комплексах программ на начальных этапах системного проектировk= 2;ния в десятки и сотни раз бы= 089;трее и дешевле, чем в процессе завер= ;шения разработки и испытаний. <o:= p></o:p> = В последни = 77; десятилетиn= 3; быстро возрастаеm= 0; сложность объек= ;тов и систем, создаваемm= 9;х в разли= ;чных областях индустрии. Для их разра= 073;отки привлекаютl= 9;я специалистm= 9; разной квалификацl= 0;и и большие финансовыk= 7; и материальнm= 9;е ресурсы. Использовk= 2;ние этих ресурсов должно коорд= ;инироватьс= 03; и объединятn= 0;ся комплексом мероприятl= 0;й для достижениn= 3; общей= ; цели </spa= n>= - создания соответствm= 1;ющего сложн= ;ого объек= ;та или системы с заданным качеством в условиях ог = 88;аниченных ресурсов. Современныk= 7; сложные системы и соответствk= 7;нно проекты, обеспечивk= 2;ющие их создание,<sp= an style=3D'mso-spacerun:yes'> имеют ряд в= ажных особенносm= 0;ей:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>е = 76;иную цель разработки = 80; последующеk= 5;о функционирl= 6;вания всей систем = 99; для определеннm= 9;х пользоватеl= 3;ей;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 72;личие совокупносm= 0;и нескольких, тесно взаим = 86;действующи&#= 1093;, компонентl= 6;в - подсистем, имеющих свои локальные задачи и цел= 080; функционирl= 6;вания;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 77;рархическу&#= 1102; структуру с = 74;язей и взаимодейсm= 0;вия компонентоk= 4;, обеспечивk= 2;ющую концептуалn= 0;ное единство и устойчивоl= 9;ть функц= ;ионировани= 03; всей систем = 99;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 77;рархическу&#= 1102; совокупносm= 0;ь критериев качества функционирl= 6;вания компо= ;нентов и системы в целом, обеспечивk= 2;ющих достижение главн= ;ых целей= ; создания и после= ;дующего применениn= 3; системы пользоватеl= 3;ями.<o:p></o:p> Одной из особенностk= 7;й сложных систем является трудность выбора и фор= 084;ализации единого критерия качества и оцен= ки эффективноl= 9;ти функционирl= 6;вания, адекватно отраж= ;ающего главные цели систе= ;мы. Обычно выделяетсn= 3; несколько боле= е или менее равнозначнm= 9;х характериl= 9;тик, каждая из которых може= т стать домин = 80;рующей для оценки эффективноl= 9;ти системы в зависимосm= 0;и от этапа ее проектировk= 2;ния, состояния = 80;ли некоторых внешних условий. Это обусловленl= 6; тем, что каждая сложная сис = 90;ема, зачастую, является частью системы большего ма = 89;штаба и высшего уровня, и подчинена е = 81;.<o:p></o:p> = Для управления проек= ;том системы, прежде всег = 86;, должен быть адекватно о = 87;исаны цели и объек= 090; проектировk= 2;ния. Для сложных систем формализаm= 4;ия и детализациn= 3; характерисm= 0;ик объекта разработки происходит одновременl= 5;о с процессом его проекти = 88;ования. Последоватk= 7;льно уточняются архитектурk= 2; объекта, основные функции и их характерисm= 0;ики, требующиесn= 3; показатели качества функционирl= 6;вания и методы решения за = 76;ач. Все эти данные отражаются = 74; концепции, т= 077;хническом задании, спецификацl= 0;и требований = 80; описании проекта, котор= ;ые детализирm= 1;ются и конкретизиl= 8;уются по мере развития пр = 86;екта. Это определяет принципиалn= 0;ную особенностn= 0; планироваl= 5;ия проектов сложных систе= ;м, состоящую в наличии влияния на план изменяющихl= 9;я значений и достоверноl= 9;ти знаний разработчиl= 2;ов о требуемых характерисm= 0;иках объекта разработки. С этиl= 4; связана необходимоl= 9;ть итерационнl= 6;го уточнения планов на всех этапах проектировk= 2;ния, разработки = 80; совершенстk= 4;ования систем.<o:p></o:p> План проекта должен отражать рациональнl= 6;е сочетание целей, стратегий д = 77;йствий, конкретных процедур и доступных р = 77;сурсов, необх= ;одимых для достижения = 87;оставленно&#= 1081; основной цели проект = 72; с заданным качеством. Планированl= 0;е проектов должно обеспечиваm= 0;ь компромисс = 84;ежду требующимиl= 9;я характерисm= 0;иками создаваемоl= 1; системы и ограниченнm= 9;ми ресурсами, необходимыl= 4;и на ее разраб= 086;тку и применени = 77;. По мере уточ= 085;ения исходных данных об объекте разработкl= 0;, внешней среде применения и ресурсах, в проm= 4;ессе системного анализа и проектировk= 2;ния возрастает достоверноl= 9;ть планированl= 0;я. <o:p></o:p> Первичное прогнозироk= 4;ание характерисm= 0;ик проекта и подготовка плана при си= 089;темном проектировk= 2;нии происходит при некоторых ф = 80;ксированны&#= 1093; исходных данных, не полностью учитывающиm= 3; динамику возможного исполнения плана. На этой стадии отс = 91;тствует оперативнаn= 3; обратная связь процесса ре = 72;льного выполнения плана с его первичным в = 72;риантом. Важне= ;йшая задача= при разработке такого плана -</span= > минимизироk= 4;ать число связе = 81; и сложность взаимодейсm= 0;вия между компонентаl= 4;и проекта, а также между исполнителn= 3;ми отдельных компонентоk= 4;. Уже пl= 8;и первичном прогнозироk= 4;ании развития си = 89;темного проекта оцениваютсn= 3; альтернатиk= 4;ные характерисm= 0;ики объекта и ср= 077;ды разработки и выбl= 0;раются наиболее подходящие = 74; соответствl= 0;и с поставлен = 85;ыми целями и име= 102;щимися ресурсами.<o:p></o:p>= После создания системного проекта появляетсn= 3; и дейст= ;вует динамичесl= 2;ая обратная связь на пла= 085; со стороны процесса ег = 86; исполнения. Реализация проекта зависит от результатоk= 4; выполнения частных работ и може= 090; требовать оперативноl= 1; корректироk= 4;ки плана. При реализациl= 0; плана определяющl= 0;ми являю= ;тся координацl= 0;я, стиму= ;лирование и контроль развития проекта. Для этого необходимо следить за х= 086;дом исполнения проекта на всем протяжении его жизне= ;нного цикла и сравнивать запланировk= 2;нные и фактическ = 80;е результаты работ. Контр= ;оль является орган= ;ической функцией управлениn= 3; и должен иметь средс = 90;ва регулироваl= 5;ия поведения отдельных личностей и коллектива проектировm= 7;иков в целом. Одновременl= 5;о обеспечиваk= 7;тся наблюдение за состоянием системы и ее характерисm= 0;иками качества, что позволяет устанавлиk= 4;ать частные компромиссm= 9; с используе = 84;ыми ресурсами. Объектами к = 86;нтроля при этом являются:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>т = 77;хнические характерисm= 0;ики реали= ;зованных компонентоk= 4; проекта, показателl= 0; качества процессов и результатоk= 4; выполнения отдел= ;ьных работ;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;траты ресурсов на выполнение частных раб = 86;т и реаl= 3;изацию компонентоk= 4; проекта (трудоемкос = 90;ь, стоимость, время, материальнm= 9;е ресурсы);<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>г = 88;афики работ, степень их выl= 7;олнения, наличие и причины отклонений реализации частных работ от планов, угроза нарушения сроко= ;в контракта.<o:p></o:p>= Для получения, накопления = 80; применения достоверныm= 3; данных об об= 098;ектах управлениn= 3; и альm= 0;ернативах необходима информациоl= 5;ная система обе = 89;печения проекта. Такая система пре = 76;ставляет собой комплекс формальных и неформальl= 5;ых каналов обмен= ;а информациk= 7;й между участникамl= 0; проекта, её накопления = 80; обработки. Следует учиты= ;вать, что любая групповая деятельноl= 9;ть связана со сложным ком = 87;лексом неформальнm= 9;х отношений между исполнителn= 3;ми. Степень фор = 84;ализации может варьироватn= 0;ся от утвержда = 77;мых руководитеl= 3;ями планов и подробных техническиm= 3; заданий до личных бесе = 76; между разра = 73;отчиками. Регулярный обмен информациеl= 1; позволяет осуществляm= 0;ь:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 73;ор исходных данных о состоянии, достигнутl= 6;м качестве компонентоk= 4; проекта и использоваl= 5;ных ресурсах;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>д = 80;спетчерско&#= 1077; управление ресурсами и частными исполнителn= 3;ми работ;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 88;авнение текущих результатоk= 4; частных работ с техн= 080;ческими заданиями, с= 087;ецификация&= #1084;и и планом;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;рректировк&#= 1091; техническиm= 3; резул= ;ьтатов работ= ;, сроков= и использу = 77;мых ресур= ;сов в соответствl= 0;и с изменение = 84; требований = 74; процессе развития пр = 86;екта.<o:p></o:p> Таким образом, целевое системное управление проектами п = 86;зволяет планироватn= 0;, контролирl= 6;вать и анализиро = 74;ать информацию = 86; состоянии и тенденциях изменения объекта разработки, его качестве и з= 072;траченных ресурсах. Пр= 080; этом непрерывно = 76;олжны сохранятьсn= 3; основные цели проект = 72; и главные пути ее достижения. Это позволя = 77;т рассматривk= 2;ть альтернатиk= 4;ы техническиm= 3; решений и предотвращk= 2;ет от со= средоточенl= 0;я внимания на частных задачах или вариантах решений, которые кажутся полезными и = 080;нтересными, но мало отражаются на достижен = 80;и главной цел = 80; проекта ПС. <o:p></o:= p> <o:p> </o:p> <h1><a name=3D"_Toc508102459"></a><a name=3D"_Toc508102232">4.2. Процессы системного проектировk= 2;ния программныm= 3; средств</a></h1> <o:p> </o:p> Системное проектировk= 2;ние в программноl= 1; инженерии охватывает период жизн = 77;нного цикла сложных комплексов программ, начиная от формулировk= 2;ния первичного замысла на создание ил = 80; модернизацl= 0;ю системы и до начала детального проектировk= 2;ния и разработк = 80; ПС. Результатl= 6;м этого периода работ должн = 86; быть соглас = 86;ванное и формализо = 74;анное разработчиl= 2;ом и заказчико = 84; представлеl= 5;ие о целях, назначении, функционалn= 0;ных задачах и ка= 095;естве будущего программноk= 5;о продукта, способногl= 6; удовлетворl= 0;ть надежды и запросы пользоватеl= 3;ей. В системном проекте должны быть обобщены и отражены следующие основные результаты = 74;ыполненных системных исследоваl= 5;ий и разработо = 82; (рис. 4.1): <o:p></o:p= > <![if !supp= ortLists]>- = &nb= sp; = <![endif]>обобщенный анализ проведенноk= 5;о обследованl= 0;я объекта информатизk= 2;ции, функций существующk= 7;й информациоl= 5;ной системы, кач= 077;ства ее основных программныm= 3; компонентоk= 4; и базы данных;<o:p></o:p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>совокупнос= ;ть предваритеl= 3;ьных исходных тр = 77;бований к функциям и характерисm= 0;икам комплекса программ;<o:p></o:p>= <![if !supp= ortLists]>- = &nb= sp; = <![endif]>оценки имеющихся и потенциальl= 5;о доступных р = 77;сурсов (финансовых, вычислителn= 0;ных средств, специалистl= 6;в) для обеспечениn= 3; всего жизненного цикла и треб= 091;емого качества проекта комплекса п = 88;ограмм; <o:p></o:p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>результаты= ; предваритk= 7;льного анализа возможной архитектурm= 9; комплекса программ на основе моделей и прототипов аналогичныm= 3; систем, позв= 086;ляющие наметить планы разработки = 80; всего жизне = 85;ного цикла проекта ПС; <o:p></o:= p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>цели, задач = 80; и функции предполагаk= 7;мой новой или мо= 076;ернизирова&= #1085;ной системы, обобщенные = 74; концепции создания соответствm= 1;ющего программноk= 5;о средства; <o:p></o:p></span= > <![if !supp= ortLists]>- = &nb= sp; = <![endif]>проекты планов жизненного цикла, гарантировk= 2;ния требуемого качества ПС, защиты и обеспечениn= 3; безопаснос&#= 1090;и его функцио = 85;ирования;<o:p></o:p></sp= an> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>результаты технико-эко = 85;омического обоснованиn= 3; целесообраk= 9;ности и основных направлениl= 1; продолжениn= 3; проектировk= 2;ния и всего ЖЦ ПС;<= o:p></o:p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>результаты анализа существующk= 7;й и возможной = 080;нструмента&= #1083;ьной среды разработки, = 072; также систе = 84;ы обеспечениn= 3; качества, пе= 088;спективы их развития = 080; совершенстk= 4;ования;<o:p></o:p> <![if !supportLists]>- = &nb= sp; = <![endif]>предвари&= #1090;ельный план организациl= 0; работ, требо= 074;ания к составу и квалификацl= 0;и специалистl= 6;в для выполнения проекта и всего жизненного цикла ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; = <![endif]>проект формализовk= 2;нного техническоk= 5;о задания и спецификацl= 0;и требований = 82; ПС, а также предложениn= 3; по его финан= 089;ированию и обеспечениn= 2; ресурсами; <o:p></o:p= > <![if !supp= ortLists]>- = &nb= sp; = <![endif]>системный проект, обобщающий = 87;роведенные исследованl= 0;я и разработк = 80;, позволяющиl= 1; заключить контракт между разработчиl= 2;ом и заказчико = 84; на финансировk= 2;ние и продолжениk= 7; проектировk= 2;ния и/или на весь жизненный цикл ПС. <o:p></o:p> Сl= 0;стемное проекти= рование сложных ПС начинается = 89; обследованl= 0;я объекта инф = 86;рматизации, системного анализа п= ;редметной области и выявления п = 86;требности в создании или модернизацl= 0;и комплекса п = 88;ограмм с определеннm= 9;ми функциями и качеством. При создани = 80; сложных ПС важно учитывать, что только заказчик и п= 086;тенциальны&= #1081; пользоватеl= 3;ь системы вправе и способен корректно формулировk= 2;ть требования = 80; впоследствl= 0;и судить наск = 86;лько успешно проведена разработка = 89;оответству&#= 1102;щего ПС. Аналитики-к = 86;нсультанты совместно с потенциальl= 5;ыми разработчиl= 2;ами и заказчико = 84; или пользоватеl= 3;ями должны пров = 86;дить анализ прикладной области и объекта информатизk= 2;ции, разрабатывk= 2;ть стратегию разработки = 80; технико-эко = 85;омическое обоснованиk= 7; реализуемоl= 9;ти выдвигаемыm= 3; требований. <o:= p></o:p> Разр= аботка исходных требований для техниче = 89;кого задания на проект ПС начинается = 89; анализа результатоk= 4; обследованl= 0;я объекта инф = 86;рматизации и оценки доступных ресурсов дл= 03; реализации проекта. Эта деятельносm= 0;ь требует специальноl= 1; организациl= 0; специалистl= 6;в наивысшей квалификацl= 0;и и тесной сов= 084;естной работы пред = 89;тавителей заказчика и разработчиl= 2;а. Они должны подготовитn= 0; исходные данные и документы, в которых сод = 77;ржатся предваритеl= 3;ьные требования = 80; пожелания к функционалn= 0;ным и конструкт = 80;вным характерисm= 0;икам качества программноk= 5;о комплекса. Далее ими должна проводитьсn= 3; сложная раб = 86;та по предвари = 90;ельному упорядоченl= 0;ю, селекции, обобщению и ранжированl= 0;ю приоритетоk= 4; требований для их реализации = 74; проекте. Наличие обычно ряда неформализl= 6;ванных, неструктурl= 0;рованных и противоре = 95;ивых содержателn= 0;ных требований заказчика и разработчиl= 2;а требует их совместной обработки, с= 086;гласования и корректир = 86;вки. <o:p></o:p> Функ= циональные требования заказчика к = 087;роцессам и результат = 72;м обработки информации необходимо скоординирl= 6;вать с конструкт = 80;вными требованияl= 4;и и возможностn= 3;ми их эффектив = 85;ой реализации разработчиl= 2;ами в спецификацl= 0;ях требований = 82; комплексу программ и его программныl= 4; и информаци = 86;нным компонентаl= 4;. Должна быть предусмотрk= 7;на корректироk= 4;ка, конкретизаm= 4;ия и развитие совокупносm= 0;и предваритеl= 3;ьных требований = 74; процессе системного проектировk= 2;ния и в дальнейшем по мере реализации проекта при = 090;есном взаимодейсm= 0;вии заказчика и разработчиl= 2;а. Для крупных проектов ПС целесообраk= 9;но использоваm= 0;ь специальныl= 1; инструментk= 2;рий и хранилище решений в пр= 086;цессе отработки требований, которые сле = 76;ует учесть в системном проекте и техническоl= 4; задании, а также приме = 85;ять для контрол= 03; их реализац = 80;и.<o:p></o:p> Предваритk= 7;льный анализ и мод= 077;лирование процессов обработки данных при с= 080;стемном проектировk= 2;нии должны проходить этапы от простого ус = 90;ановления базовых отн = 86;шений между понят = 80;ями, через определениk= 7; интерфейсоk= 4; доступа и атрибутов, к проекту модели сост = 86;яний и взаимодейсm= 0;вий между реаль = 85;ыми объектами и процессами ПС. Эти модел&#= 1080; должны служить базой при разработке = 89;хем потоков упр = 72;вления и данных, описывающиm= 3; процессы их = 086;бработки, а впоследствl= 0;и интегрировk= 2;ться с отработан = 85;ыми моделями процессов для комплек = 89;ного исследованl= 0;я функционирl= 6;вания прототипов </sp= an><span style=3D'font-size:14.0pt;font-family:Symbol; mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times New Ro= man"; letter-spacing:.2pt;mso-char-type:symbol;mso-symbol-font-family:Symbol; font-weight:normal;font-style:normal'>- пилотных проектов ПС = 074; целом. Ите= ративный характер построения формализовk= 2;нного описания проекта системы, предо= ;пределен изначально не только потому, что не удается с= 088;азу получить непротиворk= 7;чивое и полное описание из-за неясно= 089;тей в исходном описании, но и потому, что сложную систему можно описывать только, начи= 085;ая с основной части ее предметной области, котор= ;ая затем постепенно расширяетсn= 3; и детализир = 91;ется. <o:p></o:p> Моде&= #1083;ирование процессов обработки данных при системном проектировk= 2;нии преследует две основные цели:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 86;делировани&#= 1077; проблемно-о = 88;иентирован&#= 1085;ых процессов и конкретных функционалn= 0;ных задач с цель= 102; исследованl= 0;я принципов, методов и характерисm= 0;ик обработки и = 85;формации и принятия решений для последующеk= 5;о их использоваl= 5;ия в проектах; <o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>м = 86;делировани&#= 1077; архитектурm= 9; объектов и п= 088;оцессов, а также их взаимодейсm= 0;вия, предп= ;олагаемых для применения = 74; конкретном проекте, без акцента на особенностl= 0; функционалn= 0;ных характерисm= 0;ик компонентоk= 4;. <o:p></o:p> &#= 1055;ри построении формализовk= 2;нного описания системы, выполняемоl= 4; её разработ = 95;иком, принципиалn= 0;ными являются дв = 72; организациl= 6;нных момента: спе= 094;иалисты - заказчики или пользоватеl= 3;и создаваемоl= 1; системы должны активно участвоватn= 0; в процессе анализа и реализации её описания; каждый шаг описания должен обязательнl= 6; документирl= 6;ваться. Наглядны= ми и удобными в работе являются графическиk= 7; представлеl= 5;ия описаний проектных решений, которые поз = 74;оляют создавать прототипы П = 57;. Они обеспеч = 80;вают эффективнуn= 2; визуализацl= 0;ю и обратную связь между разработчиl= 2;ом и потенциал= 00;ным пользоватеl= 3;ем с целью оценки реализации требований, = 082;орректиров&= #1082;и функций и качества компонентоk= 4;, а также форм пользоватеl= 3;ьского интерфейса. </s= pan>Для этого разра = 73;отана целая гамма = 084;етодологий<= span style=3D'mso-spacerun:yes'> для мl= 6;делировани= 103;, структурноk= 5;о анализа и визуальногl= 6; проектировk= 2;ния. Современ= ные инструментk= 2;льные CASE-средства об= ;еспечивают широкие возможностl= 0; выбора проц = 77;ссов моделироваl= 5;ия, автоматизиl= 8;ованного анализа системных п = 88;едложений и выработки первичных требований = 82; предполагаk= 7;мому проекту ПС. Схемы поток = 86;в данных, пото= 082;ов управления, сущность-св= 03;зь и другие – составляют комплекс удобных и гибких граф = 80;ческих методов и средств описания систем, облегчающиm= 3; взаимопониl= 4;ание между разра = 73;отчиками и заказчика = 84;и на разных ур= 086;внях детализациl= 0; функций, качества и архитектурm= 9; ПС. <o:p></o:p> Конце= пция создаваемоk= 5;о комплекса программ (см. рис. 4.1) на естественнl= 6;м языке данно = 81; предметной области должна включать пр = 77;дварительн&#= 1099;е требования = 82; ПС, основные понятия и термины. Она является первым исходным документом, согласуемыl= 4; с заказчико = 84; для создани= 03; комплекса программ. На основе этог = 86; описания формируетсn= 3; предваритеl= 3;ьное техническоk= 7; задание на систему и её основные компоненты. При использоваl= 5;ии формализовk= 2;нных методов раз = 88;аботки программныm= 3; средств текстуальнl= 6;е описание системы подлежит переводу на соответствm= 1;ющий, возможно, графическиl= 1; язык. Наряду с = разработчиl= 2;ами, специалистm= 9;-заказчики или пользов = 72;тели создаваемоl= 1; концепции П = 57; должны активно участвоватn= 0; в процессе анализа и реализации её описания.<o:= p></o:p> Одни= м из наиболее эффективныm= 3; направлениl= 1; сокращения = 79;атрат и повышения качества комплексов программ является активное использоваl= 5;ие методическl= 6;го, технологичk= 7;ского, алгоритмичk= 7;ского и программн = 86;го задела из предшествуn= 2;щих проектов, которое может быть названо = прототипирl= 6;ванием= в широком смысле слов = 72;. Математичеl= 9;кие модели и прототипы различных компонентоk= 4; и функций систем= обеспечивk= 2;ют возможностn= 0; применять готовые апробироваl= 5;ные решения, а та&#= 1082;же выделять и исследоватn= 0; принципиалn= 0;но новые метод = 99; и процессы для реализации их в ПС. = Прототипирl= 6;вание позволяет наглядно пр = 77;дставить заказчику и пользоватеl= 3;ю функции системы, вид= 099; и динамику применения экранов, меню, отчето= 074; и форм запросов, а также откорректиl= 8;овать их для развития ПС на всех этапах ЖЦ. Методами математичеl= 9;кого моделироваl= 5;ия должны создаватьсn= 3; варианты, фрагменты и компоненты прототипа П = 57; и выделятьс= 03; возможные методы реализации предполагаk= 7;мых функций и обеспечениn= 3; их качества. </= span>Для этого следу = 77;т анализировk= 2;ть и выбирать прототипы к = 86;мплексов программ, характерисm= 0;ики которых наиболее близки к создаваемоl= 1; версии ПС и которые позволили б = 99; получить в результате объекты с необходимыl= 4;и характерисm= 0;иками. На их основе,<s= pan style=3D'mso-spacerun:yes'> во= зможно прогнозироk= 4;ать процессы разработки = 80; достигаемыk= 7; показатели качества вн = 86;вь создаваемоk= 5;о ПС. Этим же целям способствуk= 7;т предваритеl= 3;ьное распределеl= 5;ие ресурсов, доступных для создани= 03; проекта.<o:p></o:p></s= pan> Страт&#= 1077;гическое планированl= 0;е проекта дол = 78;но содержать долгосрочнm= 9;е цели развит = 80;я ЖЦ ПС определеннl= 6;го функционалn= 0;ного назначения. Планы должн = 99; отражать пр = 77;дварительн&#= 1099;е проекты всего будущ = 77;го жизненного цикла ПС, обеспечениn= 3; их качества, защиты и без= 086;пасности функционирl= 6;вания, верификациl= 0; и тестирова = 85;ия, управления конфигурацl= 0;ей и сопровождеl= 5;ия. На базе требований = 82; ПС и первичн= 099;х планов появляется возможностn= 0; оценить объем подле = 78;ащих разработке компонентоk= 4; программ и б= 072;з данных, а также некоторые дополнителn= 0;ные характерисm= 0;ики возможного объекта и ср= 077;ды разработки. На этом этап= 077; инструментk= 2;льные средства должны обеспечить наглядное представлеl= 5;ие каждого плана, оценк= 091; возможной трудоемкосm= 0;и и длительно = 89;ти разработки, необходимоk= 5;о числа специалистl= 6;в и других ресурсов дл= 03; их реализации. </s= pan> По этим данным руководитеl= 3;ем разработки = 80; заказчиком принимаетсn= 3; решение о целесообраk= 9;ности продолжениn= 3; проектировk= 2;ния и осуществляk= 7;тся стратегичеl= 9;кое планированl= 0;е проекта, которое фор = 84;ализуется в системном проекте и в техническоl= 4; задании на ПС.<o:p></o:p> &nbs= p; Такое постепенноk= 7; повышение д = 86;стоверност&#= 1080; прогнозов приводит к целесообраk= 9;ности оценки достигаемыm= 3; значений ка = 95;ества по этапам и к возможностl= 0; разработки укрупненноk= 5;о, поэтапного плана выполнения всего комплекса работ в ЖЦ ПС. Эти данные позволяют принимать р = 77;шения по корректироk= 4;ке требований = 82; ПС, по измене&#= 1085;ию среды разработки или состава коллектива специалистl= 6;в. Таким образом, пос= 083;едовательн&= #1086;е прогнозироk= 4;ание, планированl= 0;е и системное управление проектом обеспечиваn= 2;т рациональнl= 6;е использоваl= 5;ие ресурсов в процессе со = 79;дания сложных ПС гарантировk= 2;нного качества. <o:p></o:p></span= > Прог= нозы и анализ вариантов технологичk= 7;ских процессов проектировk= 2;ния ПС, их технико-эко = 85;омических показателеl= 1; и характери = 89;тик объекта разработки являются ос = 85;овой для выбора, предваритеl= 3;ьного планированl= 0;я и последующеk= 5;о системного анализа все = 75;о жизненного цикла ПС. Достоверноl= 9;ть планов и про= 075;нозов определяетl= 9;я точностью с = 74;едений об объекте разработки, характерисm= 0;иках технологичk= 7;ской среды и прототипов, принятых за основу при планированl= 0;и. Таким образ = 86;м, производитl= 9;я технико-эко = 85;омическое обоснованиk= 7; проекта (см. лекцию 5), определяюm= 0;ся приближеннm= 9;е значения трудоемкосm= 0;и и длительно = 89;ти всей разработки ПС, а также число необх = 86;димых специалистl= 6;в, что позволяет оценить предваритеl= 3;ьный укрупненныl= 1; план создан = 80;я ПС в заданны= 093; условиях, ре= 089;урсах и сроках. Вследствие творческогl= 6; характера большинствk= 2; работ на это= 084; этапе невоз = 84;ожно составить жесткий пла = 85; их выполнения. Помочь може = 90; типовой перечень ча = 89;тных работ, представлеl= 5;ный в стандартах ЖЦ ПС и ориентировl= 6;чный график, иллюстрируn= 2;щий их взаимосв= 03;зь.<o:p></o:p> Пров= еденные таким образом оценки проекта ПС позволяют осуществитn= 0; предваритеl= 3;ьный выбор основных методов и инструментk= 2;льных средств для провед = 77;ния последующеk= 5;о детального = 80; рабочего проектировk= 2;ния и поддержки всего ЖЦ ПС. Кроме того, должна подготавлиk= 4;аться адаптация средств автоматизаm= 4;ии, применителn= 0;но к особеннос = 90;ям объекта и среды проектировk= 2;ния. Разрабатывk= 2;ются проекты рук = 86;водств для специалистl= 6;в, выделяемых на данный проект, и осуществляk= 7;тся их обучение. </= span>Интегри= ;рованные инструменm= 0;альные средства служат для ф= 086;рмализации знаний зака = 79;чика на этапе проведения обследованl= 0;я, анализа и подготовки техническоk= 5;о задания, а та&#= 1082;же для проектировk= 2;ния концептуалn= 0;ной и логическо = 81; структуры комплекса программ и б= 072;зы данных. При этом должно активно использоваm= 0;ься моделироваl= 5;ие и тестированl= 0;е корректносm= 0;и системных решений. Благодаря высокому качеству проработки = 80; документирl= 6;вания системного проекта, создается о = 89;нова для снижени= 03; трудоемкосm= 0;и тестированl= 0;я, испытаний, а также сопровождеl= 5;ия и модификац = 80;и ПС. <o:p></o:p> В процессе системного проектировk= 2;ния должны предваритеl= 3;ьно определятьl= 9;я состав и стр= 091;ктура основных технологичk= 7;ских и эксплуата = 94;ионных документов для поддерж = 82;и всего ЖЦ ПС. Эти документы должны обес = 87;ечивать реализацию процессов ж = 80;зненного цикла ПС, планированl= 0;я и управлени= 03;, регистрироk= 4;ать выполнение требуемых действий, фо= 088;мализовать систему качества. Пр= 080; этом следуе = 90; подготовитn= 0; первоначалn= 0;ные требования = 82; документацl= 0;и и обеспечит= 00; их реализац = 80;ю, которая должна быть однозначноl= 1; <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";letter-spacing:.2pt;mso-char-type:s= ymbol; mso-symbol-font-family:Symbol'>- написана в стандартизl= 0;рованных терминах, которые допускают только единственнm= 1;ю интерпретаm= 4;ию, уточняемую, = 077;сли необходимо, соответствm= 1;ющими комментариn= 3;ми.<o:p></o:p> Сист= емный проект программноk= 5;о средства но = 74;ой или модерни = 79;ированной системы должен содержать достаточно полные требования = 82; функциям и характерисm= 0;икам качества комплекса программ, оп= 080;сание и графическоk= 7; представлеl= 5;ие его архитектурm= 9;, базы данных = 080; взаимодейсm= 0;вия компонентоk= 4;, предполагаk= 7;мую модель жизненного цикла, предв= 072;рительные планы последующиm= 3; этапов и раб= 086;т. Кроме того, в него должны входить про = 77;кты техническоk= 5;о задания и контракта н = 72; детальное проектировk= 2;ние и весь жизненный цикл ПС. Если заказчик уд = 86;влетворен результатаl= 4;и системного проектировk= 2;ния, то возможно оформление акта завершения работ и утверждениk= 7; системного проекта ком = 87;лекса программ с требуемыми характерисm= 0;иками качества новой или мо= 076;ернизирова&= #1085;ной системы, а также контракта (договора) на детальное проектировk= 2;ние или на весь жизненный цикл ПС. <o:p></o:p> = <o:p></o:p> <h1><sp= an style=3D'mso-spacerun:yes'> <a name=3D"_Toc508102460"></a><a name=3D"_Toc508102233">4.3. Структурноk= 7; проектировk= 2;ние сложных про = 75;раммных средств</a><o:p></o:p></sp= an></h1> = <o:p></o:p> При разработке структуры п = 88;ограммного средства в процессе системного проектировk= 2;ния, прежде всег = 86;, необходимо сформулироk= 4;ать критерии её формированl= 0;я. Важнейшими критериями могут быть: модифицируk= 7;мость, отлаживk= 2;емость и удобство управления разработкоl= 1; ПС, обеспечениk= 7; возможностl= 0; контролируk= 7;мого изменения конфи= ;гурации, состава и функций компонентоk= 4; с сохранениеl= 4; целостностl= 0; структурноk= 5;о построениn= 3; базовых версий ПС. В з= 072;висимости от особенностk= 7;й проблемной области, критериями при выборе архитектурm= 9; ПС могут также применятьсn= 3;: эффективнl= 6;е использоваl= 5;ие памяти или производиm= 0;ельности реализующk= 7;й ЭВМ, трудоемкоl= 9;ть или длительносm= 0;ь разработки, надежность, безопасносm= 0;ь и защищенносm= 0;ь. В соответст = 74;ии с целями и за= 076;ачами проектировk= 2;ния на стадии системного анализа и формированl= 0;я структуры П = 57; необходимо ранжироваm= 0;ь и выделить доминирующl= 0;е критерии. <o:p></o:p></span= > Гибкость модификациl= 0; и расширяем = 86;сть комплексов программ пр = 80; их совершен = 89;твовании обеспечиваk= 7;тся рядом принц = 80;пов и правил структурноk= 5;о построения = 55;С и их компонентl= 6;в, а также взаи= 084;одействия между ними. Эти правила направлены на стандарт = 80;зацию и уни= фикацию структуры и взаим= ;одействия компонентоk= 4; ПС разного ранга и назначения = 74; пределах проблемной области. Некоторая часть принципов и правил имее = 90; достаточно общий= ; характер, и может применятьсn= 3; практическl= 0; всегда. Другая част= 00; отражает проблемную и/или машин= ;ную ориентироk= 4;анность класса ПС и подлежит от = 88;аботке при системн = 86;м проектировk= 2;нии для эффективноk= 5;о применения = 74; соответствm= 1;ющей области. Основные принципы<o:p></o:p><= /p> &#= 1080; правила стр= ;уктурирова = 85;ия ПС и БД можно объединить = 74; группы, кото= 088;ые отражают:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 90;андартизир&#= 1086;ванную структуру целостного построения ПС и/или БД определеннl= 6;го класса;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила структурнl= 6;го построения функционалn= 0;ных программныm= 3; компонентоk= 4; и модулей;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>с = 90;андартизир&#= 1086;ванную структуру базы данных, обрабатывk= 2;емых программамl= 0;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила структурноk= 5;о построения информациоl= 5;ных модулей, заполняющl= 0;х базу данных;<o:= p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила организациl= 0; и структурн = 86;го построения межмо= ;дульных интер= ;фейсов программныm= 3; компонентоk= 4;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила внешнего интерфейсk= 2; и взаимодей = 89;твия компонентоk= 4; ПС и БД с внешней средой, с операционнl= 6;й систе= ;мой и другими типовыми средствами организациl= 0; вычислителn= 0;ного процесса, за= 097;иты и контроля системы.<o:p></o:p> = Методологl= 0;я структурноk= 5;о анализа и предваритеl= 3;ьного структурноk= 5;о проектировk= 2;ния ПС начинается = 89; общего обзора функ = 94;ий системы. Далее функции должны дета = 83;изироватьс&#= 1103; сверху вниз = 074; виде иерарх = 80;ческой структуры таким образом, чтобы проце = 76;уры сбора, хранения и п= 077;реработки информации, рассматривk= 2;емые сначала как нечто едино = 77; целое, расчленялиl= 9;ь на отдельны = 77; элементы да = 85;ных, компонентоk= 4; и действия, с&#= 1086;вершаемые над этими данными. Структурныl= 1; анализ, исходя из функционалn= 0;ного описания системы в целом, позво= 083;яет разделить е= 05; на функцион = 72;льные части, выделить функционалn= 0;ные описания отдельных частей, иссл= 077;довать в них информациоl= 5;ные потоки и фор= 084;ализовать структуры д = 72;нных.<o:p></o:p> </spa= n>Разделение общей задач = 80; системы и программноk= 5;о средства на компоненты </sp= an>= - это использоваl= 5;ие принципа здравого см = 99;сла, который должен быть применен в системной разработке крупного ПС для преодол = 77;ния свойственнl= 6;й ему сложности. Очень часто многи = 77; решения прочно взаимосвязk= 2;ны и взаимозав = 80;симы. Когда различные проек= ;тные решения прочно взаимосвязk= 2;ны, то бывает полезно, чтобы всеми ими сразу занимались = 74; одно и то же время одни и те же люди, но = на практике эт = 86; обычно невозможно. Единственнm= 9;й способ сl= 7;равиться со сложностью проекта - разделить задачи. Прежде всег = 86;, необходимо пытаться из = 86;лировать функции, которые менее всего связаны с другими. Зат= 077;м рассматривk= 2;ть раздельно функции, учитывая имеющ= 080;е отношения между собой и деm= 0;али связанных п = 88;облем.<o:p></o:p> Спецификац= 080;я требований = 82; предваритеl= 3;ьной архитектурk= 7; комплекса программ формируетсn= 3; в процессе детализациl= 0; и уточнения спецификацl= 0;и требований = 82; характерисm= 0;икам ПС в результате проверки последних н = 72; непротиворk= 7;чивость и полноту. Задача спец = 80;фикации требований архит= ;ектуры состоит в том, чтобы представитn= 0; достаточно = 03;сное и удобное общее описание внешнего по = 74;едения системы и свойств, а также её внутренней структуры и механизмов функционирl= 6;вания. В общем сл= 091;чае формализовk= 2;нные методы, применяемыk= 7; при специфицирl= 6;вании системной архитектурm= 9; ПС, должны обеспечиваm= 0;ь:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>э = 92;фективные и удобные средства описания св = 86;йств и особеннос = 90;ей структуры создаваемоl= 1; системы – но= 090;ации описания;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>м = 77;тодику последоватk= 7;льного, итерационнl= 6;го уточнения с = 87;ецификаций требований = 80; проектных спецификацl= 0;й компонентоk= 4;, позволяющуn= 2; проверять и = 93; корректносm= 0;ь;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]> = 89;редства и методику для возможностl= 0; прослеживаl= 5;ия реализации требований = 80; тестированl= 0;я, позволяющеk= 5;о устанавливk= 2;ть соответствl= 0;е свойств реа = 83;изуемого ПС и компоне= 085;тов его специфи = 82;ациям.<o:p></o:p>= Описания проектных решений должны содержать первичные спецификацl= 0;и крупных функционалn= 0;ных компонентоk= 4; ПС, подлежащ= 080;х разработке = 74; детальном проекте соз = 76;аваемой системы, и спецификацl= 0;й используемm= 9;х готовых компонентоk= 4;, состав кото = 88;ых определяетl= 9;я при декомпо = 79;иции общей струк = 90;уры системы. В требованияm= 3; спецификацl= 0;и к системной архитектурk= 7; комплекса п = 88;ограмм должно обес = 87;ечиваться:<o:p></o= :p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;ответствие функций и структуры П = 57; аппаратной = 80; операционнl= 6;й среде, их ресурсам и интерфейсаl= 4;; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;вместимос = 90;ь ПС с другими системами п = 86; источникам = 80; потребител= ям информации; <o:= p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1089;оответстви= е стандартам структурноk= 5;о построения = 80; интерфейсоk= 4; комплекса программ, функционалn= 0;ных компонентоk= 4; и модулей; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ая организациn= 3; информациоl= 5;ного обеспечениn= 3; и структура базы данных; <o= :p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;став, структура и способы обмена данными между функц = 80;ональными компонентаl= 4;и и внешней средой ПС;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>в = 88;еменной регламент и предваритеl= 3;ьные характерисm= 0;ики процессов реализации функций, интенсивноl= 9;ть и объемы потоков информации базы данных;<o:= p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;нтроль, хранение, обновление, защита и вос= 089;тановление программ и данных;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 90;андартизир&#= 1086;ванные, предваритеl= 3;ьные требования = 82; составу и содержанию технологичk= 7;ской документацl= 0;и.<o:p></o:p> Таким образом, для обеспечениn= 3; эффективноk= 5;о управления разработкоl= 1; прогр= ;амм необходимl= 6; при системном п = 88;оектирован&#= 1080;и стандартизl= 0;ровать и соблюдать ряд принципов архитектурl= 5;ого построения ПС. Эти принципы могут иметь особенностl= 0; для проекто = 74; ПС в различных проблемно-о = 88;иентирован&#= 1085;ых областях. Однако их стандартизk= 2;ция обеспечиваk= 7;т значительl= 5;ый эффект в сни= 078;ении трудоемкосm= 0;и и длительносm= 0;и последующеl= 1; детальной разработки программноk= 5;о продукта и версий. Част= 080;чная потеря гибк = 86;сти архитектурm= 9; ПС, некоторо= 077; возрастаниk= 7; ресурсов, необходимыm= 3; для реализации этих принци = 87;ов, обычно полностью компенсируn= 2;тся повышением управляемоl= 9;ти процесса разработки, = 072; также качес = 90;ва ПС.<o:p></o:p> Структурнl= 6;е проектировk= 2;ние программныm= 3; средств осно= вано на модульно = 84; принципе. Многоуровнk= 7;вое, иерархичесl= 2;ое пост= роение сложных пр = 86;граммных комплексов позволяет ограничиваm= 0;ь и локализов = 72;ть на каждом из уровней соответствm= 1;ющие ему компоне = 85;ты. Нижнему иерархичесl= 2;ому уровню представлеl= 5;ия прогр= ;амм соответстk= 4;уют прогр= ;аммные и информациоl= 5;ные модули (модули данн= 099;х). Эти компоненты объединяютl= 9;я в группы программ оп = 88;еделенного<s= pan style=3D'mso-spacerun:yes'> функционаl= 3;ьного назначения = 89; автономной целевой задачей. Несколько групп функционалn= 0;ных программ образует комплекс пр = 86;грамм. В особо сложных слу = 95;аях возможно создание программноk= 5;о средства из нескольких взаимодейсm= 0;вующих комплексов. Всем иерарх = 80;ческим системам (в частности, ПС) присущ ряд общих свойс = 90;в, важнейшими из которых являются:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>в = 77;ртикальная соподчиненl= 5;ость, заключающаn= 3;ся в последова = 90;ельном упорядоченl= 5;ом расположенl= 0;и взаимодейсm= 0;вующих компонентоk= 4;, составляющl= 0;х ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;аво вмешательсm= 0;ва и приоритетнl= 6;го воздействиn= 3; сверху вниз на компонен = 90;ы нижних уровней;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 79;аимозависи&#= 1084;ость действий компонентоk= 4; верхних уро = 74;ней от реакций на воздействl= 0;я и от функционирl= 6;вания компонентоk= 4; нижних уровней, инф= 086;рмация о которых передается верхним уровням.<o:p></o:p> = В результате в иерархичеl= 9;ких структураm= 3; ПС образуются два потока взаим= ;одействий между компонентk= 2;ми разных уров= ней: сверх= ;у вниз </spa= n>= - координируn= 2;щие и управляющиk= 7; воздействиn= 3; верхних уровней и снизу вверх </s= pan>= - информация о состоянии и реализации предписаннm= 9;х сверху функ = 94;ий компонентаl= 4;и нижних уровней. Координируk= 7;мые компоненты обычно имею = 90; некоторую автономносm= 0;ь поведения и подготовки локальных решений. Степень автономносm= 0;и компонентl= 6;в и интен= ;сивность координирm= 1;ющих возд= ействий устанавливk= 2;ются в результате компромиссk= 2; при выделении числа и размеров ие = 88;архических уровней. Вза= 080;модействие компонентоk= 4; в пределах у= 088;овня целесообраk= 9;но максимальнl= 6; ограничиваm= 0;ь, что позволяет упростить о = 73;щее координирl= 6;вание компо= ;нентов и прово= ;дить его только по ве= ;ртикали.<o:p></o:p> = Менее наглядными являются иерархия данных, обраб= ;атываемых ПС, и их&nbs= p; взаимодейl= 9;твие с прогр= ;аммными компонентk= 2;ми. Функционалn= 0;ная иерархия данных отражаетсn= 3; расстояниеl= 4; между расче = 90;ом или изменением переменной = 80; её использо = 74;анием, или условно = 81; длительносm= 0;ью хранения неизменяемm= 9;х значений переменной. Взаимодейсm= 0;вие двух программныm= 3; модулей мож = 77;т осуществляm= 0;ься так, что некоторые перем= ;енные используюm= 0;ся тольк= ;о этими модулями. Такие обменные переменные имеют более широк= ;ую облас= ;ть применениn= 3; и должны хран = 80;ться все время, пока не буду= 090; вызваны вза = 80;модействую&#= 1097;ие модули. Ряд переменных = 80; массивов ис = 87;ользуется многими модулями и групп= ;ами программ в комплексе = - это глобальные переменные. Они характеризm= 1;ются наиболее широким использоваl= 5;ием и соответстk= 4;уют высшему иерархичесl= 2;ому уровню сред = 80; данных. <o:p></o:p> Анализ концепции, требований техническоk= 5;о задания и технико-эко = 85;омических оценок должен позволять выполнить предваритеl= 3;ьное структурноk= 7; проектировk= 2;ние ПС = и оценку вычислителn= 0;ных ресурсов не = 86;бходимых для решения основных функционалn= 0;ных задач. Повышению э = 92;фективност&#= 1080; структурирl= 6;вания могут значи = 90;ельно способствоk= 4;ать заимствоваl= 5;ие из предыдущих проектов спецификацl= 0;й прототипов, версий и отдельных компонентоk= 4; ПС. Для обеспечениn= 3; системного проектировk= 2;ния на этом этап= 077; большое значение имеют графическиk= 7; методы визу = 72;лизации техническиm= 3; решений и логическогl= 6; контроля пр = 86;екта.<o:p></o:p> = Характериl= 9;тики внешней среды= ; применениn= 3; ПС и особенностl= 0; реализующеl= 1; ЭВМ в значительнl= 6;й степени определяют архит= ;ектуру и структуру применяемl= 6;й операционнl= 6;й системы, средств контроля и организациl= 0; вычислителn= 0;ного процесса. Пр= 080; разработке версий ПС дл= 103; некоторой прикладной области целесообраk= 9;но выбирать и унифицировk= 2;ть внешний интерфейс и операционнm= 1;ю систему. Это обеспечивk= 2;ет многократнl= 6;е использоваl= 5;ие одних и тех же организу= 02;щих программ, дисци= ;плинирует структурнl= 6;е постр= оение версий ПС и способствуk= 7;т унификации межмодульнl= 6;го интерфейса. Переход на н= 086;вую операционнm= 1;ю систему, так же как и переход на реализующуn= 2; ЭВМ другого = 090;ипа, может приве = 89;ти к необходимоl= 9;ти некоторого изменения структурноk= 5;о построения ПС и базы данны= ;х. Это способно повлиять н = 72; возможностn= 0; использоваl= 5;ия готовых ком = 87;онентов, а, следователn= 0;но, и на эффекти= 074;ность всей разраб = 86;тки.<o:p></o:p> Учет возможностl= 0; изменений = - это принцип, который более всего отличает пр = 86;граммное средство от большинствk= 2; других типо = 74; промышленнm= 9;х продуктов. В= 086; многих случаях структура П = 57; разрабатывk= 2;ется, когда требования заказчика к нему осознаны не полностью. Позже, при детализациl= 0; и после поставки, ПС должно развиватьсn= 3; на основе откликов за = 82;азчика и пользоватеl= 3;ей, поскольку о = 73;наруживают&#= 1089;я новые требования, = 072; старые уточняются. = 042; дополнение = 82; этому, программныl= 1; продукт часто встраиваетl= 9;я в среду, которая воздействуk= 7;т на него, и это воздействиk= 7; генерирует новые требования, которые не были изнача = 83;ьно известны. Таким образом, воз= 084;ожности изменений </sp= an>= - это принцип, кот= 086;рый следует использоваm= 0;ь при системном проектировk= 2;нии структуры для достижения способностl= 0; к её развити= 102; - эволюционн&#= 1086;сти структуры П = 57;.<o:p></o:p> Повторная применимосm= 0;ь - является ещ = 77; одним качеством структуры п = 88;ограммного продукта, на которое заметно воздействуk= 7;т принцип возможностl= 0; изменений. Компонент является многократнl= 6; применимым, если он може= 090; быть непосредстk= 4;енно использоваl= 5; для произво = 76;ства нового продукта ил = 80; версии. На практике, компонент может прете = 88;петь некоторые изменения прежде, чем будет использоваl= 5; повторно. Отсюда, мног= 086;кратное использоваl= 5;ие можно рассматривk= 2;ть как эвол= 02;ционность системной структуры П = 57; на уровне компонентоk= 4;. Если можно предвидеть изменения контекста, в который будет встроен программныl= 1; компонент, т= 086; и компонент можно спроектироk= 4;ать таким образом, что изменения будут им учт= 077;ны.<o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102461"></a><a name=3D"_Toc508102234">4.4. Проектировk= 2;ние программныm= 3; модулей и ко= 084;понентов<= /span></a><o:p></o:p></= span></h1> <o:p> </o:p> = Сложная система обычно може = 90; быть разделена н = 72; более прост = 99;е части -</span= > = 84;одули. Модульностn= 0; является важным качеством инженерных процессов и продуктов. Большинствl= 6; промышленнm= 9;х процессов я = 74;ляются модульными = 80; составлены из комплекс = 86;в работ, которые комбинируюm= 0;ся простыми способами (последоват = 77;льными или перекры = 74;ающимися) для достижения требуемого результата. = 043;лавное преимущестk= 4;о модульностl= 0; заключаетсn= 3; в том, что она позволяет п = 88;именять принцип раз = 76;еления задач на дву= 093; этапах: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и работе с элементами каждого модуля отде = 83;ьно (игнорируя э= 083;ементы других модулей);<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и работе с общими характерисm= 0;иками групп модулей и от= 085;ошениями между ними с целью объединить, = 080;х в конкретны = 81;, более крупный и сл= 086;жный компонент. <o:p></o:p= > Если данны = 77; этапы выполняютсn= 3; в последоватk= 7;льности, предусматрl= 0;вающей сначала концентрацl= 0;ю процессов н = 72; модулях, а затем -</span= > их объединениk= 7;, то система п= 088;оектируетс&= #1103; сниз = 91; вверх. Если сначала сис = 90;ему разбивают н = 72; модули, а потом работают на = 76; их индивидуалn= 0;ным проектировk= 2;нием, то это -</span= > проектl= 0;рование свер = 93;у вниз.<o:p></o:p> При структурноl= 4; построении = 82;омплексов программ важное знач = 77;ние имеет разме = 88; и сложность компонентl= 6;в для каждого уро = 74;ня иерархии и соответствk= 7;нно число иерархичесl= 2;их уровней k= 6;ля крупных ПС. По принципа = 84; построения, языку описания, размеру и другим характерисm= 0;икам компонентоk= 4; в структуре ПС можно выделить иерархичесl= 2;ие уровни:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;ограммных модулей, оформляемыm= 3; как законченныk= 7; компоненты текста программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>ф = 91;нкциональн&#= 1099;х групп (компоненто = 74;) или пакетов программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>к = 86;мплексов программ, оформляемm= 9;х как законченныk= 7; программныk= 7; продукты определеннl= 6;го целевого назначения. <o:p></o:p> С повышением иерархичесl= 2;ого уровня увеличиваеm= 0;ся размер текс = 90;а программ, реализующиm= 3; компоненты этого уровн= 03; и количеств = 86; обрабатываk= 7;мых переменных. = 054;дновременн&= #1086; совокупносm= 0;и команд все более специализиl= 8;уется и снижается возможносm= 0;ь повторного применения компонентоk= 4; в различных комбинацияm= 3; для решения аналогичныm= 3; задач.<o:p></o:p> Программнm= 9;е модули= решают относительl= 5;о небольшие функционалn= 0;ные задачи, и каждый реализуетсn= 3; 10-100 операторамl= 0; языка= ; прогр= ;аммировани= 03;. Каждый мод = 91;ль может использоваm= 0;ь на входе около десят = 82;а типов переменных. Если для решения небольшой функционалn= 0;ной задачи требуется более 100 опера= торов, то обычно целесообраk= 9;но проводить декомпозицl= 0;ю задачи= на несколько более прост = 99;х модулей. <o:p></o:p> Функционаl= 3;ьные группы прог = 88;амм (компоненты) формируютсn= 3; на базе нескольких или десятко = 74; модулей и решают дост = 72;точно сложные автономные задачи. На их = 88;еализацию целесообраk= 9;но использоваm= 0;ь до десятка тысяч строк текста программы. Соответстk= 4;енно возрастают число используемm= 9;х типов перем = 77;нных и разнообразl= 0;е выходных да = 85;ных. При этом быстро растет числ = 86; типов переменныm= 3;, обрабатывk= 2;емых модул= ;ями и локализующl= 0;хся в пределах одного или нескольких = 84;одулей.<o:p></o:p> Комплексы программ – программныk= 7; продукты создаются для решения сложн= ;ых задач= ; управлениn= 3; и обработки информации. = 042; комплексы о = 73;ъединяются несколько или десят= ;ки функционаl= 3;ьных групп прогр = 72;мм для решения общей целевой задачи сист = 77;мы. Размеры ПС зачастую исчисляютсn= 3; сотнями модул= ;ей, десятками и сотнями тысяч операторов. Встречаютl= 9;я ПС, содержащи= 077; до двух-трех десятков струк= ;турных иерархичеl= 9;ких уровн= ;ей, построеннm= 9;х из модулей.<o:p></o:p> <s= pan style=3D'mso-spacerun:yes'> </sp= an> = П = 88;оектирован&#= 1080;е модулей включает в себя разраб = 86;тку локальных функций и по= 076;робных описаний алгоритмов обработки д = 72;нных; межмодульнm= 9;х интерфейсоk= 4;; внутренних = 89;труктур данных; структурныm= 3; схем переда = 95; управления; средств управления = 74; исключителn= 0;ных ситуациях. С их помощью определяютl= 9;я функции: порядок следования отдельных ш = 72;гов обработки, ситуации и типы данных, вызывающие изменения процесса об = 88;аботки, а также повт= 086;рно используемm= 9;е функции программы. </s= pan>Программны&= #1077; модули для и= 093; многократнl= 6;го использоваl= 5;ия должны бази = 88;оваться на унифицировk= 2;нных правилах структурноk= 5;о построения, оформ= ;ления спецификацl= 0;й требований = 80; описаний текстов программ и комментариk= 7;в. Кроме того, целесообраk= 9;но для каждого проекта дир = 77;ктивно ограничиваm= 0;ь размеры модулей по числу строк = 090;екста с учетом языка прогр = 72;ммирования, например, 30-ю или 50-ю операторамl= 0; (см. лекцию 13). <o:p></o:p> Основная цель такой унификации облегчить разработку модулей, обеспеченl= 0;е их качества = 080; тестированl= 0;я, а также упростить управление их функциям = 80; и характерисm= 0;иками. Эти правила = 074; значительнl= 6;й степени стандартизl= 0;рованы в современныm= 3; языках прог = 88;аммировани&#= 1103;. Однако при и= 093; применении целесообраk= 9;но выделять типовые ас = 89;оциации операторов = 80; ограничениn= 3; их использоваl= 5;ия, а также, вводить правила описа= ;ния текстов программ, комментарl= 0;ев, данных и заголовков модулей, ограничениn= 3; их размеров = 080; сложности. Эти правила наиболее полно должн = 99; соблюдатьсn= 3; при разрабо = 90;ке основной массы функционаl= 3;ьных программ, подлежащиm= 3; повторному использоваl= 5;ию в модифицир = 91;емых версиях программныm= 3; продуктов. Компонентm= 9; организациl= 0; вычислителn= 0;ного процесса, контроля функциониl= 8;ования, ввода-выво = 76;а и некоторые другие могу = 90; иметь отлич = 80;я в правилах структурноk= 5;о построения модулей.<o:p></o:p> Для обеспечениn= 3; управляемоl= 1; модификаци&#= 1080; и развития конфигурацl= 0;й версий программноk= 5;о продукта ва = 78;но стандартизl= 0;ровать структуру базы данных, в которой накапливаk= 7;тся и хранится исходная, промежутоm= 5;ная и результир = 91;ющая информация = 74; процессе функционирl= 6;вания ПС. Основными компонентk= 2;ми этой структуры являются информациоl= 5;ные модули или пакеты данных. В них = 90;акже целесообраk= 9;но использовk= 2;ть типовые структуры, ориентировk= 2;нные на эффектив = 85;ую обработку данных в кон= 082;ретной проблемной области. Объед= ;инение информациl= 6;нных модулей позволяет создавать более сложные структуры данных определеннl= 6;го целевого назначения. Иерархия связей межд = 91; этими компонентаl= 4;и в некоторой степени соответстk= 4;ует процессу обработки и = 087;отокам данных и отн= 086;сительно слабо связана со структурой = 87;рограммных<s= pan style=3D'mso-spacerun:yes'> компонентl= 6;в в ПС. Структуры информациоl= 5;ных модулей цел = 77;сообразно координирl= 6;вать между собой с учетом цели = 080; места их исп= 086;льзования программныl= 4;и компонентаl= 4;и. <o:p></o:p> Особое значение дл= 03; качества модулей и компоненто&#= 1074; крупных ПС имеет станд = 72;ртизация структуры межмодульнm= 9;х интерфейсоk= 4; по передача = 84; управления и по инфор= ;мации. Эти правила формируютсn= 3; на базе описаний языков программирl= 6;вания или оформляютl= 9;я на основе прави= ;л структурнl= 6;го построения программ и базы данных конкретных проектов ПС. В последнем случае соглашения = 86; связях конкретизиl= 8;уются в макрокома = 85;дах межмодульнl= 6;го взаимодейсm= 0;вия. Структурноk= 7; проектировk= 2;ние сложных ком = 87;лексов программ активно развиваетсn= 3; на основе концепции и стандартов = 86;ткрытых систем. Применение стандартоk= 4; открытых систем следует начинать пр = 80; создании ар = 93;итектуры исходных модулей мобильных ПС и БД, а далее неукоснитеl= 3;ьно использоваm= 0;ься при всех процессах ЖЦ. Во всех случая = 93; создание архитектурm= 9; модулей и компонентоk= 4; современныm= 3; сложных систем целесообраk= 9;но вести с использоваl= 5;ием профилей международl= 5;ых стандартоk= 4;, значительl= 5;ая часть= ; которых обесп= ;ечивает мобильносm= 0;ь и возможнос = 90;ь повторного использоваl= 5;ия готовых программныm= 3; средств и ба= 079; данных (см. лекцию 3). <o:p></o:p> Основными целями созд= ;ания и применени= 03; концепции, м= 077;тодов и стандарто = 74; открытых систем явля = 77;тся повышение общей экономичеl= 9;кой эффек= ;тивности разработкl= 0; и функциони = 88;ования систем, а также логич = 77;ской и техническоl= 1; совместимоl= 9;ти их компонен = 90;ов, обеспечениk= 7; мобильностl= 0; и повторног = 86; применения готовых про = 75;рамм и данных. Они реализуют спецификацl= 0;и на интерфейсы, проце= ;ссы и форматы данных, доста= ;точные для того, чтобы обеспечить:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 86;зможность расширения ПС, а также переноса (мобильност= 00;) программныm= 3; компонентоk= 4; и систем, разра= ;ботанных должным образом, с минимальныl= 4;и изменениямl= 0; на широкий диапазон аппаратныm= 3; и операцион = 85;ых платформ;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;вместную работу с другими программныl= 4;и продуктами = 80; системами н = 72; локальных и удаленных платформах;<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 79;аимодейств&#= 1080;е с пользоватk= 7;лями в стиле, облегчающk= 7;м последним, переход от системы к системе (мобильнос = 90;ь пользоватk= 7;лей).<o:p></o:p> = Для достижения этих целей р= 072;звиваются и применяютl= 9;я разли= ;чные проблемно-о = 88;иентирован&#= 1085;ые технологии = 80; комплексы средств авт = 86;матизации ЖЦ мобильны = 93; программ и баз данных, основанные на повторно = 84; использовk= 2;нии готовых апробировk= 2;нных модулей, программныm= 3; компонентоk= 4; и данных, их эффективноl= 4; переносе на различные аппаратные = 80; операционнm= 9;е платформы = 80; согласованl= 5;ом взаимодейсm= 0;вии в распредел = 77;нных информациоl= 5;ных системах. Профессионk= 2;лы в области от= 082;рытых систем акцентируюm= 0; усилия на поиске и создании гибкой, способной к наращиваниn= 2; среды, что базиру = 77;тся на трех напр= 072;влениях стандартизk= 2;ции в области систем (см. лекцию 2):<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 87;паратных и операционнm= 9;х платформ;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тодов и технологи = 80; обеспечениn= 3; жизне= ;нного цикла прикл = 72;дных программныm= 3; средств и ба= 079; данных;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 85;терфейсов компонентl= 6;в и модулей между собой, с операцион = 85;ой и внешней средой. = &nb= sp; = = <o:p></o:p> Методы открытых систем обеспечиваn= 2;т эффективныk= 7; по трудоемкосm= 0;и и качес= ;тву структурноk= 7; проектировk= 2;ние, расширение = 80; перенос готовых про = 75;раммных средств обработки информациl= 0; и баз данных на различные аппаратные = 80; операционнm= 9;е платформы. Эти методы можно разделить н = 72; три части:<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>о = 73;щая концепция и методы непосредстk= 4;енного обеспечениn= 3; мобильностl= 0; компонентоk= 4; программныm= 3; средств и ба= 079; данных в процессе разработки систем за с= 095;ет унификации интерфейсоk= 4; с операционнl= 6;й и аппаратно = 81; средой;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды, поддерживаn= 2;щие мобильностn= 0; компонентоk= 4; и комплексо = 74; программ и данных в распределеl= 5;ных системах и совме= ;стимость их взаимоде = 81;ствия с внешней средой;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды создания текстов программныm= 3; средств, баз данных и их компонентоk= 4; на стандарт = 80;зированных языках= программиl= 8;ования высок= ;ого уровня, обеспечиваn= 2;щие потенциальl= 5;ую возможностn= 0; их переноса на различны = 77; аппаратные платформы.<o:p></o:p>= Первая группа методов соз= ;давалась с ограниченнl= 6;й и определенl= 5;ой целью локализоваm= 0;ь и унифицировk= 2;ть интерфейсы = 87;рограммных компонентоk= 4; между собой, с зара&#= 1085;ее выделеннымl= 0; операционнm= 9;ми системами и = 089; внешней средой. Интерфейснm= 9;е стандарты являются базой для обеспечениn= 3; структурноk= 5;о проектировk= 2;ния, свободного перемещениn= 3; и расширени= 03; программныm= 3; проду= ;ктов и компонентоk= 4; в различные по архитект = 91;ре и функциям операционнm= 9;е окружения и аппаратные платформы. Эти методы п= 086;зволяют разделить функционалn= 0;ную часть комплексов = 87;рограмм и их связи с организац = 80;онным окружением, обеспечиваn= 3; технологичk= 7;скую, архитектурl= 5;ую и языковую независимоl= 9;ть функционалn= 0;ной части= ; прогр= ;амм и данных. Тем самым они являются базой для ре= 072;лизации концепции открытости = 74; системах и обеспечиваn= 2;т свободу разработчиl= 2;ам при выборе методов структурноk= 5;о проектировk= 2;ния и языков программирl= 6;вания для создани= 03; компонентоk= 4; программ и описаний данных. Стандарты этой группы включают группу стандартов POSI= X, в которой определены концепция и функции интерфейсоk= 4; переносимm= 9;х операционl= 5;ых систем, команды управления = 80; сервисные программы, а также расширение = 76;ля переносимыm= 3; операционнm= 9;х систем.<o:p></o:p> Вторая группа методов име= ;ет целью= ; поддержатn= 0; мобил= ;ьность программныm= 3; продуктов в откры= ;тых системах путем унификации их интерфей = 89;ов с внешней средой. Они обеспечиваn= 2;т совместимl= 6;сть обмена данными в различных файловых си = 89;темах и базах данных, унифи= ;кацию администраm= 0;ивного управления и взаимодейl= 9;твия с пользоват = 77;лями, а также методов обеспечениn= 3; безопасносm= 0;и и защиты информации. Таким образом, создается стандартизl= 0;рованная по интерфейсk= 2;м внешн= ;яя среда на различных г = 77;терогенных аппаратных платформах, в которую могут эффективнl= 6; погружатьl= 9;я различные п = 88;ограммы, согласованl= 5;ые по интерфей = 89;ам с этими стандартамl= 0;. Стандарты этой группы = 088;егламентир&= #1091;ют функции и процессы, поддерживаn= 2;щие взаимодейсm= 0;вие с внешней ср= 077;дой:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;нцепции и архитектурm= 1; визуализацl= 0;и информации для взаимодейl= 9;твия с пользоватеl= 3;ями и её предста= 074;ления в базовых системах графическоk= 5;о отображениn= 3;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 88;хитектуру, интерфейсы, базовые пр = 86;цессы и языки управления файловыми системами = 80; базами данных, обеспечивk= 2;ющими их совмести = 84;ость и унификаци= 02; в сложных системах;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>а = 76;министрати&#= 1074;ное управление локал= ;ьными и распределk= 7;нными компонентаl= 4;и систем в процессе решения функционаl= 3;ьных задач обраб = 86;тки информации.<o:p= ></o:p> Третья группа= методов создаваласn= 0; в значительнl= 6;й степени независимо от первой и второй. Эти методы преследуют = 94;ель унифицировk= 2;ть тексты прог = 88;аммных модулей, компонентоk= 4; и описания д= 072;нных, созда= ;ваемых для различных аппаратных платформ пр = 80; любой их архитектурk= 7;, независимо от операцио = 85;ной и внешней ср= 077;ды. Первоначаl= 3;ьное огромное чи = 89;ло языков программирl= 6;вания (свыше 200),= каждый из которых име = 83; несколько диалектов, в результате сократилосn= 0; до 6 - 10 массовых языков, ограниченl= 5;ых станд= ;артами, не допускающиl= 4;и диалектов. Создание современныm= 3; модулей и компонентоk= 4; ПС и БД поддерживаk= 7;тся методами и и= 085;струментал&= #1100;ными средствами технологий, методами тестированl= 0;я и аттестаци = 80; программ и и= 093; интерфейсоk= 4;, а также стандартизl= 0;рованным составом и содер= ;жанием документаm= 4;ии на программ = 99; и базы данных. Эти мk= 7;тоды и средства обеспечиваn= 2;т необходимоk= 7; качество мо = 76;улей и компонk= 7;нтов сложных ПС и БД. В результате обеспечена = 84;обильность функционалn= 0;ной части текстов про = 75;рамм, однако они могут требовать доработок интерфейсоk= 4; для сопряжения = 89; новой средо = 81; аппаратногl= 6; и операционнl= 6;го окружения систем.<o:p></o:p> = <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p></sp= an> <h1><a name=3D"_Toc508102462"></a><a name=3D"_Toc508102235">Лекция 5. Технико-эко = 85;омическое обоснованиk= 7; проектов программныm= 3; средств</a></h1> <o= :p> </o:p> <h1><a name=3D"_Toc508102463"></a><a name=3D"_Toc508102236">5.1. Цели и процессы технико-эко = 85;омического обоснованиn= 3; проек= ;тов программныm= 3; средств</a></h1> <o:p></o:p> Выбор и формированl= 0;я требований = 82; функционалn= 0;ной пригодностl= 0; ПС наиболее ответственl= 5;ая, стратегичеl= 9;кая задача начальных этапов технико-эко = 85;омического обоснованиn= 3; проекта программноk= 5;о продукта, си= 089;темного проектировk= 2;ния и всего последующеk= 5;о развития ег = 86; жизненного цикла. Жизненный цикл ПС можн= 086; разделить н = 72; две части, существеннl= 6; различающиk= 7;ся экономичесl= 2;ими особенностn= 3;ми процессов и ресурсов, ха= 088;актеристик&= #1072;ми и влияющими на них факторами. В первой части ЖЦ ПС производятl= 9;я системный анализ, проектироk= 4;ание, разработка, тестированl= 0;е и испытания базовой версии программноk= 5;о продукта. Номенклатуl= 8;а работ, их трудоемкосm= 0;ь, длительносm= 0;ь и другие экон = 86;мические характерисm= 0;ики на этих этапах ЖЦ существеннl= 6; зависят от характерисm= 0;ик объекта, технологии = 80; инструмент&= #1072;льной среды разработки. Особенно важно учиты = 74;ать возможное возрастаниk= 7; суммарных з = 72;трат при завышении требований = 82; качеству пр = 86;граммного продукта. Ка= 082; и для других видов промы = 96;ленной продукции, улучшение качества комплексов программ обычно дост = 80;гается не пропорци = 86;нальным, а более значительнm= 9;м возрастаниk= 7;м требуемых для этого ресурсов. Сокращение этой потребностl= 0; в ресурсах ч= 072;сто возможно только за счет принци = 87;иального изменения и совершенстk= 4;ования технологии проектировk= 2;ния и разработк = 80;.<o:p></o:p> Ориентираl= 4;и для оценива = 85;ия необходимыm= 3; ресурсов трудоемкосm= 0;и, длительносm= 0;и и числа специалистl= 6;в по крупным этапам рабо = 90;, при создани = 80; сложных ПС высокого качества, могут служить дан = 85;ые приведенныk= 7; ниже в п. 5.2 – п. 5.4. Максимум трудоемкосm= 0;и и числа специалистl= 6;в приходится = 85;а этапы прогр = 72;ммирования и тестирова = 85;ия компонентоk= 4;, когда привлекаетl= 9;я основная масса программисm= 0;ов-кодировщ&#= 1080;ков для разрабо = 90;ки компонентоk= 4; ПС. При активном использоваl= 5;ии и совершенстk= 4;овании технологий системного анализа и проектировk= 2;ния, проис= ;ходит перераспреk= 6;еление всех видов затрат в сто= 088;ону увеличения трудоемкосm= 0;и начальных э = 90;апов разработки. Это дает значительнl= 6;е снижение использовk= 2;ния совокупных ресурсов дл= 03; всего проек = 90;а. Менее изучены распределеl= 5;ия необходимыm= 3; ресурсов по этапам рабо = 90;, с учетом реа= 083;изации требуемых конкретных характерисm= 0;ик качества ПС. Опубликоваl= 5;ные данные и зависимостl= 0; для различных к = 83;ассов ПС, позволяю= 090; прогнозироk= 4;ать совокупные затраты и другие основные технико-эко = 85;омические показатели (ТЭП), планы и графики раб = 86;т вновь созда = 74;аемых проектов пр = 86;граммных продуктов.<o:p></o:p>= = Вторая часть ЖЦ, отражающаn= 3; эксплуатаm= 4;ию, сопровождеl= 5;ие, модификациn= 2;, управление конфигурацl= 0;ей и перенос ПС на иные платформы, в меньшей степени зав = 80;сит по величине требуемых ресурсов от = 092;ункциональ&= #1085;ых характерисm= 0;ик объекта и среды разработки. = 053;оменклатур&= #1072; работ на эти= 093; этапах боле = 77; или менее определеннk= 2;я, но их трудоемкосm= 0;ь и длительносm= 0;ь могут сильн = 86; варьироваm= 0;ься, в зависимосm= 0;и от массовости = 80; других внешних фак = 90;оров распростраl= 5;ения и применени= 03; конкретных версий программноk= 5;о продукта. Успех ПС у пользоватеl= 3;ей и на рынке, а также будущий процесс раз = 74;ития версий трудно предсказатn= 0;, и он н = 77; связан напрямую с экономичесl= 2;ими параметрамl= 0; процессов разработки ПС. Определяющl= 0;ми становятся потребителn= 0;ские характерисm= 0;ики продукта, а их экономичесl= 2;ие особенностl= 0; с позиции разработчиl= 2;ов и вложенные ресурсы на очередную версию отходят на второй план (см. первую часть ЖЦ). <o:p></o:p> Вследствиk= 7; этого в широк= ;их пределах могут изменяться = 90;рудоемкост&#= 1100; и число специалистl= 6;в, необходимоk= 7; для поддержки этих этапов ЖЦ. Это затрудн= 03;ет статистичеl= 9;кое обобщение ТЭП разл= ичных проектов и прогнозироk= 4;ание на их основе аналогичныm= 3; характерисm= 0;ик новой разработки. Поэтому планы на эти= 093; этапах имею = 90; характер об = 97;их взаимосвязk= 7;й содержания работ, которые требуют рас = 87;ределения во времени, индивидуалn= 0;но для каждого проекта. В резул= ;ьтате прогнозироk= 4;ание и планироваl= 5;ие трудоемкосm= 0;и и длительносm= 0;и этапов= приходитсn= 3; производиm= 0;ь итерационl= 5;о на базе накопл = 77;ния опыта и анализа раз = 74;ития конкретных версий ПС, а также от их у&#= 1089;пеха на рынке.<o:p></o:p> = Для прогнозирl= 6;вания и планированl= 0;я любых процессов или характе = 88;истик объектов (в частности П = 57;) используютl= 9;я исходные да = 85;ные двух типов: <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>ф = 91;нкции и номенклатуl= 8;а характерисm= 0;ик самого прог = 85;озируемого объекта или процесса, для которого необходимо спланироваm= 0;ь жизненный цикл;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>х = 72;рактеристи&#= 1082;и прототипов = 80; пилотных пр = 86;ектов, в некоторой степени, под= 086;бных планируемоl= 4;у объекту, о которых известны реализованl= 5;ые планы и необходимыk= 7; экономичесl= 2;ие характерисm= 0;ики уже заверше = 85;ных аналогичныm= 3; процессов или объектов. <o:p></o:p> Совместнаn= 3;, корректная обработка исходных данных этих двух типов позволяет при проектировk= 2;нии оценивать и получать новые= ;, прогнозируk= 7;мые характерисm= 0;ики процессов, планов и экономичесl= 2;их показателеl= 1; создания ПС. Исходные данные= первого ти = 87;а отражают характерисm= 0;ики конкретногl= 6; создаваемоk= 5;о объекта или процесса, доступные методы и инс= 090;рументальн&= #1099;е средства автоматизаm= 4;ии труда при их создании. Эт= 080; данные посл = 77;довательно детализируn= 2;тся и уточняютс= 03; в процессе проектировk= 2;ния и дальнейшегl= 6; ЖЦ ПС, что, в частности, позволяет уточнять выбор компонентоk= 4; аналогичныm= 3; объектов и и= 093; характерисm= 0;ик для исходных данных второ= ;го типа. <o:p= ></o:p> = Второй тип исходных данных для обоснованиn= 3; и планирова = 85;ия разработки ПС составляют обобщенный = 86;пыт проектировk= 2;ния и экономиче = 89;кие характерисm= 0;ики прото= ;типов нового программноk= 5;о продукта. Для достоверноk= 5;о планированl= 0;я необходимо накопление, обобщение и изучение конкретных данных о реаl= 3;изованных планах, затратах и использоваl= 5;ных ресурсах завершенныm= 3; разработок ПС в различных аспектах. Та= 082;ие ТЭП и факторы, их определяющl= 0;е, изуче= ;ны в процессе обработки значи= ;тельного стати= ;стического материала реальных отечественl= 5;ых и зарубежны = 93; проектов программныm= 3; продуктов и использоваl= 5;ы ниже в метод= 080;ках прогнозироk= 4;ания (см. п. 5.2 - п. 5.4). <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> При технико-эко = 85;омическом обоснованиl= 0; проекта ПС н= 072; любом уровн = 77; целесообраk= 9;но применять методы и методики ад = 77;кватные целям и этапам его реализации. <sp= an style=3D'letter-spacing:.35pt'>Следуе&#= 1090; согласовывk= 2;ть цели оценивания ТЭП с потребностn= 3;ми в информаци = 80;, спосо = 73;ствующей принятию решений для план = 80;рования затрат труд = 72; и других ресурсов. В общем случае необходимо достигать </sp= an>сбалансиро= 074;анного состава целей оценивания разных характерисm= 0;ик, которые бы давали прим = 77;рно одинаковую </sp= an>абсолютl= 5;ую величину уровня неоп = 88;еделенност&#= 1080; оценок для всех компонентов ПС. Кроме того, к= 072;ждая оценка ТЭП долж&#= 1085;а сопровождаm= 0;ься, указанием степени ее неопределеl= 5;ности. По мере разработки проекта их необход= 080;мо пересматриk= 4;ать и изменять, к&#= 1086;гда это становится выгодным. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Привлеченl= 0;е заказчика помогает менее болезненно решать проб = 83;емы управления масштабом проекта и ре= 072;лизуемыми функциями с учетом ограничениl= 1; ресурсов. В зависимостl= 0; от этапа разработки сложного комплекса программ и достоверноl= 9;ти исходных да = 85;ных о характери = 89;тиках и особенностn= 3;х проекта ПС целесообраk= 9;но выбирать и применять разные мето = 76;ики и сценарии технико-эко = 85;омического обоснованиn= 3; проекта и пр= 086;гнозирован&= #1080;я ТЭП. </span= >С самого начала рабо = 90;ы над проекто = 84; ПС важно вести посто= ;янный учет данных = 086; его &#= 1076;ействитель= ной трудоемкосm= 0;и, стоимости и развитии затрат и сравнивать эти данные с реальными оценками характерисm= 0;ик проекта l= 7;о сл= едующим причинам:<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1085;есовершенс= тво исходных данных при оценивании ТЭП (оценки размера, рей= 090;инги влияния фак = 90;оров) определяеm= 0; важность дл= 03; руко= водителя проекта пересматриk= 4;ать их оценки, учитывая новую инфор = 84;ацию, чтобы обеспечить более реальную основу для дальнейшегl= 6; управления проектом; <o:p></o:p></span= > <![if = !supportLists]>- = <![endif]>&#= 1074;следствие несовершенl= 9;тва методов оце = 85;ивания ПС следует сравнивать = 86;ценки с действителn= 0;ными значениями = 80; использоваm= 0;ь эти результ = 72;ты для улучшен = 80;я методов оце = 85;ивания ТЭП;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;оекты ПС имеют тенденцию к изменению х = 72;рактеристи&#= 1082; и экономичесl= 2;их факторов и р= 091;ководителю проекта необходимо идентифици= ровать эти изменения и выполнять реалистичнl= 6;е обновление оценок затра= ;т.<o:p></o:p> При разработке ПС необходимо учитывать, ч= 090;о экономичесl= 2;ие, временные, вычислителn= 0;ные и другие ресурсы на разработку = 80; весь ЖЦ прог= 088;амм в= ;сегда ограниченнm= 9; и используе = 84;ые затраты для улучшения каждой хара = 82;теристики должны учитывать эти огранич = 77;ния. Для рациональнl= 6;го распределеl= 5;ия этих ресурс = 86;в необходимо знать как отражается изменение затрат на улучшении каждой характерисm= 0;ики качества ПС. Эта взаимос = 74;язь затрат ресурсов и значений каждой хара = 82;теристики зависит от н= 072;значения, а также от ряда свойст = 74; и других осо= 073;енностей комплекса п = 88;ограмм, что усложняет учет влияни= 03; таких связе = 81;. Тем не менее,<s= pan style=3D'mso-spacerun:yes'> выявлены основные тенденции т = 72;кого взаимодейсm= 0;вия, которые мог = 91;т служить ори = 77;нтирами при выборе и установленl= 0;и требований = 82; определеннm= 9;м характерисm= 0;икам качества в конкретных проектах ПС. <o= :p></o:p> Оl= 9;новными ресурсами у разработчиl= 2;ов при создани = 80; сложных комплексов программ являются: допустимые тl= 8;удозатраты (стоимость) на разработку ПС с требуемым к = 72;чеством; время R= 11; длительносm= 0;ь полного цикла создания программноk= 5;о продукта; необходимоk= 7; и доступное <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>чl= 0;сло специалистl= 6;в соответствm= 1;ющей квалификацl= 0;и. Потребностn= 0; в этих ресур= 089;ах в наибольше = 81; степени зависит от размера – масштаба и сложности р = 72;зрабатывае&#= 1084;ого ПС. Уто&#= 1095;нения размеров ПС = 080; компонентоk= 4; могут быть решены последоватk= 7;льно к концу детального проk= 7;ктирования,<s= pan style=3D'mso-spacerun:yes'> однако при этом сохран= 03;ется неопределеl= 5;ность оценки размера комплекса п = 88;ограмм и его трудоемкосm= 0;и поря = 76;ка 5 – 10%, связанная = 89; тем, насколько хорошо программисm= 0;ы пони = 84;ают спецификацl= 0;и, в соответствl= 0;и с которыми они должны <sp= an style=3D'letter-spacing:.35pt'>кодиро&#= 1074;ать программу, при этом це= 083;есообразно учитывать:<o:p></o:p>= <![if= !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>цели оцениk= 4;ания ТЭП должны быть согласованm= 9; с потребнос = 90;ями в информаци = 80;, сп&= #1086;собствующе= ;й принятию решений на соответствm= 1;ющем этапе проекта ПС;<o:= p></o:p> <![if= !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>достове = 88;ность оценок= ТЭП должны быть сбалан = 89;ированы для различных компонентоk= 4; системы и величина уровня неопределеl= 5;ности для каждого компонента должна быть примерно одинаковой, если в процессе принятия решения все компоненты имеют одина = 82;овый вес;<o:p></o:p> <![if !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>следует возвращ = 72;ться к предшествуn= 2;щим целям оцени = 74;ания ТЭП и изменя= 090;ь их, когда это не= 086;бходимо для ответст = 74;енных бю= джетных решений, принимаемыm= 3; на ранних эт= 072;пах и влияющих на следующие э = 90;апы.<o:p></o:p> Достат = 86;чно трудно оценить объем трудозатраm= 0;, необходимыm= 3; для выполнения = 79;адачи, без достоверноl= 1; информации относительl= 5;о её размера. Таким образ = 86;м, изме&#= 1088;ение размера (сложности) предшествуk= 7;т оценке ТЭП, а эта оценка, в свою очеред= 00;, предшествуk= 7;т составлениn= 2; график= 072; работ. Недостатоm= 5;но достоверныk= 7; оценки влекут проблемы вз = 72;имодействи&#= 1103; разработчиl= 2;а с заказчико = 84; и увеличива= 02;т степень риска проек = 90;а. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> <sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext; mso-bidi-font-weight:normal;mso-bidi-font-style:italic'>Исm= 3;одные данные реальных завершенныm= 3; разработок</spa= n> для оценива = 85;ия ТЭП, собираю= 090;ся, накапливаn= 2;тся и обрабатыв = 72;ются, с начала 70-х годов в разн= 099;х отечественl= 5;ых организациn= 3;х и за р= ;убежом. Они позволили получать и прогнозироk= 4;ать основные об = 86;бщенные ТЭП процессов р = 72;зработки ПС. При этом обычно рассматривk= 2;лся полный= технологиm= 5;еский процесс разработки = 55;С от начала подготовки техническоk= 5;о задания до заk= 4;ершения испытаний базовой вер = 89;ии программноk= 5;о продукта. Учитывалисn= 0; все категории специалистl= 6;в, участвующиm= 3; в создании программ и обеспечиваn= 2;щих разработку, а также все виды работ, связанные с созда= ;нием программноk= 5;о продукта на выделенном интервале времени. Тео= 088;етические работы и системный анализ до подготовки требований = 79;аказчика в значениях ТЭП не учитывалисn= 0;. В общем случае для оценки техн = 80;ко-экономич&= #1077;ских характерисm= 0;ик новых проек = 90;ов необхl= 6;димы исход= ;ные данные:<o:p></o:p>= <![i= f !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>обобщенн&= #1099;е характерисm= 0;ики использоваl= 5;ных ресурсов и т= 077;хнико-эконо= мические показатели завершенныm= 3; разработок </sp= an><span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > прототипов ПС, а также оценки влия = 85;ия на их характерисm= 0;ики различных факторов объекта и среды разра = 73;отки;<o:p></o:p> <![i= f !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>реализов&= #1072;нные и обобщенны = 77; перечни вып = 86;лненных работ, и реальные графики про = 74;еденных ранее разра = 73;оток различных классов ПС;<o:p></o:p= > <![if !supportLis= ts]>-&nb= sp; = <![endif]>цели и содержание частных работ в процессе создания сложн= ;ых комплексов программ и требования = 82; их выполнен = 80;ю для обеспечениn= 3; необходимоk= 5;о качества ПС = 074; целом;<o:p></o:p> <![i= f !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>структур&= #1072; и содержани = 77; документов, являвшихсn= 3; результатоl= 4; выполнения частных работ.<o:p></o:p> В качестве базового в = 72;рианта целесообраk= 9;но принять статистиm= 5;ес-кие данные ТЭП, перечень работ и документов жизненного цикла созда = 85;ия наиболее слl= 6;жного встроенногl= 6; комплекса программ реального времени. Н= 072; основе этих исходных данны= ;х могут быть оценен = 99; ТЭП для полн= 086;го цикла разработки ПС конкретногl= 6; вида в более простых случаях путем исключения = 80;з базового варианта работ и документоk= 4;, в которых отс = 91;тствует необходимоl= 9;ть. По оставшим = 89;я работам могут быть о= 094;енены ТЭП для анализируеl= 4;ых вариантов, и<sp= an style=3D'mso-spacerun:yes'> вы= бран из них предпочтиm= 0;ельный. Для технико-эко = 85;омического анализа процесса создания программ ва = 78;нейшей составляющk= 7;й являются соk= 4;окупные трудовые затраты – трудо= ;емкость на непосредстk= 4;енную разработку ПС. <o:p></o:p></= span> Трудоемкос= ;ть разработки программныm= 3; средств наиболее сильно зависит от <sp= an style=3D'display:none;mso-hide:all'>- раз = 84;ера – масштаба комплекса прогр= амм, выраж= енного: числом оператор= ;ов,- строк на языке программирl= 6;вания или функцио-нал= 00;ных точек (см. стандарт ISO 14143:1-5:1998-2004.<= span style=3D'mso-no-proof:yes'> –= Измерениk= 7; функционалn= 0;ного размера). Реальное= ; изменени= ;е созда= ваемых в настояще= ;е время= сложн= ых ПС от </spa= n>104 до 107 строк (LOC</sp= an>) определя= ;ет диапа= зон трудоем= ;ко- сти= разработки </sp= an>таких программ= ; от человеко-го = 76;а до десятков= ; тысяч человеко-ле = 90;. Подтв= ерждена по большому= ; числу проектов= ; высок= ая ст= атис-тическ = 72;я к= орреляция между размером комплексов </sp= an> прогр= амм и т&= #1088;удоем-костью </sp= an>их ра= ;зра- ботки= . <o:p></o:p> Эффективно= ;сть затрат при повторном использоваl= 5;ии комполнентl= 6;в (ПИК) и сборк&= #1077; ПС в з= ависимости от их </spa= n>доли, зачас= тую оцениваласn= 0; путем анализа </spa= n>эквивалентн= 086;й произво- дител= ьности труд= а разработ-чик= ;ов и= длительн= ;ости созда= ния ПС. В ряде случае = 74; особое знач = 77;ние имеет не столько использоваl= 5;ие готовых программныm= 3; компонентоk= 4;, сколько перенос баз данных. Информация = 86; процессах, п= 088;оисходящих во внешней среде, может иметь большой объем и труд= 086;емкость первичного накопления = 80; актуализацl= 0;и, что определ= 03;ет необходимоl= 9;ть ее тщательн = 86;го хранения. Практическl= 0; вl= 9;егда необходимо время и труд= 086;емкость на: <o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>первичны&= #1081; системный анализ целесообраk= 9;ности применения ПИК; <o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>поиск, ада= ;птацию и процессы использоваl= 5;ия готовых ком = 87;онентов;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>оценку затрат с учетом стоимости приобретенl= 0;я и адаптации переносимыm= 3; программ и баз данных; <o:p></o:= p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>интегрир&= #1086;вание в новой операционнl= 6;й или внешней среде;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тестиров&= #1072;ние и испытания компонентоk= 4; в комплексе = 089; унаследоваl= 5;ными программамl= 0;. <o:p></o:p> Для планированl= 0;я разработки сложных ПС важно знать = 080; использоваm= 0;ь эксперименm= 0;альные статистичеl= 9;кие распределеl= 5;ия основных ТЭ = 55; – трудоемко = 89;ти, длительносm= 0;и и числа специалистl= 6;в п= ;о этапам рабо = 90; и по реальному времени реа = 83;изации компонентоk= 4; проектов. Относительl= 5;ые значения распределеl= 5;ия этих величи = 85; на интервале реализации крупных проектов несколько различаютсn= 3; в зависимос = 90;и от размера и типа комплекса п = 88;ограмм, однако наибольший = 80;нтерес представляn= 2;т сложные встроенные = 55;С реального в = 88;емени размером порядка 500 тысяч строк. <o= :p></o:p> <s= pan style=3D'font-size:14.0pt;color:windowtext'> В совокупных затратах на создание полностью новых ПС дом= 080;нирует трудо= ;емкость непосредсm= 0;венной разра= ;ботки программнm= 9;х компонентоk= 4;. &#= 1056;аспределен= ие необходимоl= 1; трудо= ;емкости на этапы разработки программ сложного П = 57; реального времени пре = 76;ставлено в таблице 5.1. Этап технологичk= 7;ской подготовкl= 0; разработкl= 0; включен в техническоk= 7; проектировk= 2;ние, а документи = 88;ование объединено с компл= ;ексной отладкой. В распределk= 7;нии учтены под = 84;ножества работ, соотв= 077;тствующие разным кате = 75;ориям специалистl= 6;в. Все специалисm= 0;ы были разделены на трl= 0; категории: руководитеl= 3;и разработки = 80; системные аналитики; непосредстk= 4;енные разработчиl= 2;и программнm= 9;х компо= ;нентов и специ= ;алисты по комплексирl= 6;ванию; вспомогатеl= 3;ьный персонал, обеспечиваn= 2;щий разработку = 80; документирl= 6;вание программ. Первая и третья кате = 75;ории специалистl= 6;в непосредстk= 4;енно не взаимоде = 81;ствуют с текстом пр= 086;грамм при их отраб= 086;тке, однако их труд является неотъемлемl= 6;й частью всего= ; процесса разработки и в крупных проектах с = 86;ставляет около полов = 80;ны затрат на к= 072;ждом этапе. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = Основ= ное содер= жание, размер= и требуемое = 82;а- честв= о, со&= #1079;даваемых</span= > ПС, практическl= 0; всегда определяют </sp= an>затраты</span= >, связа= нные с их непос-реk= 6;ственной<sp= an style=3D'mso-no-proof:yes'> р= азработкой. Влияние это = 81; части затрат определяет</spa= n> ся наиболее= ; сложным </spa= n>творческ= ;им проце= ссом созда= ния программ, котор= ый завис= ит от многих m= 2;акторов= ;. Некоторы= ;е из них могут из= - менят= ь з= атраты даже в= ; нескольк= ;о раз, но в боль&= #1096;инстве своем изменяют их на десят= ки проце= нтов. Накоп= ленный опыт </span= >создания ПС и l= 6;бобщени= ;е прове= денных иссле= дований позво- лили </span= >выделить= ; четыре основные группы факто= ров, влия= ющих на оценки затра= т при н= ;епосред= ;ственной разработке </sp= an>программ= ;: <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, </span= >от&= #1088;ажающие особе= нности созда= ваемого компл= екса прогр= амм, как объекта</span= > разработ= ;ки, требо= вания к е<sp= an style=3D'mso-no-proof:yes'>го функционалn= 0;ным ха- ракте= рис-тикам и к качеству; </s= pan><o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, определяющи= е организа= ;цию проце= сса разработ= ;ки комп-лексов </s= pan>про- грамм= и его обеспече= ;ние квали= фицированнm= 9;ми специ= алистами; <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, характеризу= ющие технолог= ;ическую среду и <= /span> оснащ= енность инс&#= 1090;рументальн= ыми средст= вами автом= атизации проце= сса разра= ботки прогр= амм; <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, отражающие оснащ= енность проце= сса созда= ния ПС ап- паратурныl= 4;и вычислителn= 0;ными средства= ;ми, на которых реализуютсn= 3; комплексы программ и = 073;азируют= ;ся инструментk= 2;льные систе= мы авто- матиз= ации разработки. <o:= p></o:p> В пре= ;дставленны = 93; четыре= х групп= ах распр= еделены факто= ры, котор= ые наиболее важны при анализе основных затрат на проекты ПС.<sp= an style=3D'mso-no-proof:yes'> В эти г<sp= an style=3D'mso-no-proof:yes'>руппы k= 4;ключены= ; факторы, </sp= an>которые </spa= n>могут изменять оценку = 87;роиз- во-дит= ;ельности т= руда при с= ;оздании ПС не </spa= n>менее чем на 10% в ту ил= и иную </span= >сторону. = 42; то же время= имеющийс= ;я опыт </span= >показыва= ;ет, что отсутств= ;уют отдел= ьные факто= ры или м= ;етоды</span= >, способны= ;е измен= ять на порядок </spa= n> или более основные ТЭ= ;П п= роцесса разра= ботки прогр= амм. Боль- шинст= во факторов изменяет= ; экономич= ;еские харак= теристики разра- ботки программ на десятки проце= нтов и не более чем в= ; 1,5 раза. Для оценивания ТЭП ниже в п.п. 5.2 – 5.4 последоваm= 0;ельно рассмотренm= 9; и рекоменду= 02;тся три методики:<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>Методиl= 2;а 1 – экспертн&= #1086;го технико-эк = 86;номическог&#= 1086; обос&= #1085;ования проектов программныm= 3; средств при подготовке концепции и техническоk= 5;о задания на новый компл = 77;кс программ на основе экспертных данных разработки одной строк = 80; текста прог = 88;амм – прототипо = 74;;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>Методика 2<s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";mso-bidi-font= -weight: bold'> – оценка технико-эко = 85;омических показателеl= 1; проектов программныm= 3; продуктов с учетом совокупносm= 0;и основных фа = 82;торов предваритеl= 3;ьной модели СОСОМО II (см. Boehm B.W. = et al. Software cost estimation with COCO= MO II. Prentice = Hall PTR. New Jersey. 2000); <o:p>= </o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>Методиl= 2;а 3 – уто= чненная оценка технико-эко = 85;омических показателеl= 1; проектов программныm= 3; продуктов с учетом полной сово= купности факторов де = 90;альной модели СОСОМО II.2000 (там же).= <o:p></o:p> В качестве основ= ;ных критериев выбора методик прогнозироk= 4;ания ТЭП разра= ;ботки ПС целесообрk= 2;зно учитывать возможностn= 0; их использо = 74;ания, как на начальных, так и на боле&#= 1077; поздних этапах разр = 72;ботки. Для практическl= 6;го применения модели СОСОМО II опубликоваl= 5; пакет прикладных программ и р= 091;ководство по его применению. Оно иллюстр = 80;ровано формами экранов и несколькимl= 0; обширными практическl= 0;ми примерами применения для технико-эко = 85;омического анализа конкретных проектов сложных комплексов программ. <o:p></o:p></span= > Важl= 5;ейшим фактором пр = 80; технико-эко = 85;омическом обоснованиl= 0;, определяющl= 0;м создание программныm= 3; средств являются люди – спеm= 4;иалисты, с их уровнем профессионk= 2;льной квалификацl= 0;и, а также с мно&#= 1075;ообразием знаний, опыта, стимулов и потребностk= 7;й. Быстрый рос = 90; сложности и повышение ответственl= 5;ости за качество комплексов программ привели к = появлению новых требований = 82; специалистk= 2;м, обеспечиваn= 2;щим все этапы жизненного цикла ПС. При проектировk= 2;нии ПС различны = 93; классов, разделение труда специалистl= 6;в по квалификацl= 0;и при разработке программ и данных, организациn= 3; коллективоk= 4; и экономика таких разра = 73;оток стали важнейшей частью выбора, обуче= ;ния и подготовк = 80; специалистl= 6;в для обеспечениn= 3; всего ЖЦ ПС (см. лекцию 9).<o:p></o:p><= /span> В детальной<sp= an style=3D'mso-spacerun:yes'> модели СОСОМО значительнl= 6;е внимание уделено влиянию организациl= 0; и взаимодейсm= 0;вия коллектива разработчиl= 2;ов на трудоемкосm= 0;ь создания сложных программныm= 3; средств. В со&#= 1089;таве организациl= 6;нных характерисm= 0;ик коллектива рекомендуеm= 0;ся учитывать согласованl= 5;ость целей специалистl= 6;в, участвующиm= 3; в проекте, их психологичk= 7;скую совместимоl= 9;ть и способностn= 0; к дружной коллективнl= 6;й работе, наличие опыта работ = 99; в данном коллективе = 80; другие объективныk= 7; и субъективнm= 9;е свойства уч = 72;стников проекта. При этом большо = 77; значение может иметь личная мотивация и психологичk= 7;ские особенностl= 0; поведения разных специалистl= 6;в при комплексноl= 1; работе над сложным проектом. Эт= 080; характерисm= 0;ики могут быть обобщены в качественнm= 9;й показатель влияния сло = 78;ности взаимодейсm= 0;вия специалистl= 6;в в коллектив = 77;, которому сопос-тавле = 85;ы коэффициенm= 0;ы изменения трудоемкоl= 9;ти разработки ПС. Наилуч-шим считается продолжитеl= 3;ьное корректное взаимодейсm= 0;вие организоваl= 5;-ных специалистl= 6;в с большим опытом работы в данном колл = 77;ктиве при полной согласованl= 5;ости их целей, планов и методов работы. При <s= pan style=3D'font-size:14.0pt'>ра&= #1079;работке прогр= амм больш= ими колле= ктивами значи= тельно повыш= ается роль </span= >квалификаци = 80; руков= одителей р= азработки, что непос= редственно отраж= ается на средней </spa= n>производ= ;ительности труда= всего= коллекти= ;ва. Однак= о форма= лизовать и учесть влиян= ие руков= одителя разработки </sp= an>и в= едущих специ= алистов на<= /span> за- траты и ТЭП комплекса программ пока трудно. <o:p></o:p> Урове= нь квалификаци= и заказ= чика и= опреде- ленно= сть техни= ческого задан= ия на раз= ;работку ПС может весьма сильн= о влият= ь на суммарны= ;е затра= ты и дли= ;- тельн= ость созда= ния прогр= амм. Измен= ения техни= ческого задан= ия и объем переделок = 85;епосред= ;ственно отраж= аются на средней </spa= n>произ- водит= ельности т= руда специалистl= 6;в, рассч= итанной по конечном= ;у размеру созданного комплекса программ. О= собенно сильно на достоверноl= 9;ть техни- ческо= го задан= ия и возраста= ;ние затра= т влияе= т попытка заказчик= ;а форси= ровать сроки= разработ= ;ки. При э= ;том первонач= ;альное техниче= ;- ское= з= адание оказы= вается недос= таточно квали= фицированнm= 9;м и под= ;- верга= ется в дальнейш= ;ем много= кратным измен= ениям. Этому же мож&= #1077;т спосо= бствовать разли= чие между= заказчик= ;ом и разра= ботчиком в квалифик= ;ации, уровн= е поним= ания целей= разра- ботки= и необходимыm= 3; затрат l= 5;а реализацию допол= нительных тре- бован= ий.<o:p></o:p> При проектировk= 2;нии и создании высококачеl= 9;твенных комплексов программ, прежде всег = 86;, необходима организациn= 3; и тесное взаимодейсm= 0;вие представитk= 7;лей заказчика и разработчиl= 2;ов проекта. Взгляды и тр= 077;бования заказчика, в основном, отражаются = 74; функционалn= 0;ных и потребите = 83;ьских характерисm= 0;иках ПС. Устремлениn= 3; разработчиl= 2;ов направлены на возможностn= 0; и способы их реализации = 89; требуемым качеством. Эти различи= 03; исходных точек зрени= 03; на проект приводят к тому, что некоторые н = 77;формализов&#= 1072;нные представлеl= 5;ия тех и других имеют зоны неоднозначl= 5;ости и взаимного непониманиn= 3;, что может пр= 080;водить к конфликта = 84;. = <o:p></o:p> Затраты и труд специалистl= 6;в при реализации крупномасшm= 0;абного проекта ПС можно распределиm= 0;ь по дв= 091;м категориям специалистl= 6;в: разрабатывk= 2;ющим компоненты = 80; ПС в целом и обеспечиваn= 2;щим технологию = 80; качество программноk= 5;о продукта (см. лекцию 9). Организацl= 0;онное разделение = 89;пециалисто&#= 1074;, осуществляn= 2;щих разработку = 55;С (первая кате= 075;ория), и специалистl= 6;в, контролируn= 2;щих и управляющ = 80;х его качеством в процессе разработки = 80; всего ЖЦ (вто&#= 1088;ая категория), должно обеспечиваm= 0;ь эффективноk= 7; достижение заданных характерисm= 0;ик, а также независимыl= 1;, достоверныl= 1; контроль затрат и качества ре = 79;ультатов разработки.<o:p= ></o:p> = Затl= 8;аты на технологию = 80; инструментk= 2;льные программныk= 7; средства автоматизаm= 4;ии разработки ПС обычн= о являются весьма весом= ;ыми при использоваl= 5;ии высокоэффеl= 2;тивных автоматизиl= 8;ованных технологий. При технико-эк= 086;номическом обоснованиl= 0; проекта следует учи = 90;ывать, что размер и сложность с = 86;здаваемого ПС значител= 00;но влияет на выбор инструментk= 2;льных средств и уровня авто = 84;атизации технологии, = 072; также на дол= 102; этих затрат = 074; общих затратах на разработку. Встречаютсn= 3; ситуации, пр= 080; которых зат = 88;аты на технолог = 80;ю достигают 30 <= span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - 50% общих затрат= на разработку. Такие затра = 90;ы могут быть оправданы повышением производитk= 7;льности труда, сокращениеl= 4; сроков= разработкl= 0; и последующl= 0;м снижением затрат на м= 085;ожество базовых версий ПС. Однако чаще всего эта группа затрат= при создании первой= версии сложных ПС находится в = 087;ределах 30% от суммарных затрат. В первом приб = 83;ижении степе= ;нь автоматизk= 2;ции разработкl= 0; программ отраж= ;ает размер программныm= 3; средств, используемm= 9;х в технологичk= 7;ских системах. Этот показатель соотв= ;етствует сложности систе= ;м автоматизаm= 4;ии разработки программ и п= 088;опорционал&= #1077;н затратам на их приобретенl= 0;е (или создание) и эксплуатацl= 0;ю. <o:p></o:p> </= span>Стремление уменьшить технологичk= 7;ские затраты в период разр = 72;ботки без учета последующеk= 5;о испол= ;ьзования ПС, его компо= ;нентов и всего жизн= 077;нного цикла может оказаться мало полезным, а в некоторых случаях привести к значительl= 5;ому увеличению совокупных затрат в ЖЦ. При применении сложных ПС э= 090;и затраты исч = 80;сляются сотнями человеко-ле = 90;, что определ= 03;ет особую актуальноl= 9;ть их снижения. Поэтому необходим системный а = 85;ализ распределеl= 5;ия и использоваl= 5;ия технологиm= 5;еских ресурсов на разработку программ с учетом всег = 86; их жизненного цикла, включая сопровождеl= 5;ие и возможный перенос на д= 088;угие платформы. <o:p></o:p= > Уровень автоматизаm= 4;ии и качество технологии = 80; инструментk= 2;льных средств, = 80;спользуемы&#= 1093; для поддержки всего жизненного цикла ПС, обычно силь = 85;о коррелировk= 2;н с достигаемыl= 4; качеством к = 86;мплексов программ, а также с качеством с = 88;едств автоматизаm= 4;ии для оценивания этого качества. Поэтому определениk= 7; уровня зрелости технологичk= 7;ской поддержки процессов жизненного цикла, организациl= 6;нного и инструмен = 90;ального обесп= ;ечения качества ПС, непосредстk= 4;енно связано с выбором и оцениваниеl= 4; реальных ил = 80; возможных характерисm= 0;ик качества конкретногl= 6; комплекса программ. В </= span>модели СОСОМО для оценивания технико-эко = 85;омических показателеl= 1; при разработке ПС рекомендуеm= 0;ся методологиn= 3; сложных программныm= 3; средств СММ = 211; система и модель оценки зрел = 86;сти комплекса, применяемыm= 3; технологичk= 7;ских процессов жизненного цикла ПС (см. лекцию 3). Эти уровни зрелости характериk= 9;уются степенью формализацl= 0;и, адекватносm= 0;ью измерения и документирl= 6;вания процессов и продуктов Ж = 62; ПС, широтой применения стандартов = 80; инструментk= 2;льных средств автоматизаm= 4;ии работ, наличием и полнотой реализации функций системой обеспечениn= 3; качества технологичk= 7;ских процессов и их результа = 90;ов. &#= 1042; модели СОСОМ = 54; приводятс&= #1103; количествеl= 5;ные реком = 77;ндации к= ;оэффициент = 86;в влияния уровней зрелости СМ = 52; на трудоемк = 86;сть реаl= 3;изации сложных проектов ПС.<sp= an style=3D'mso-spacerun:yes'> Влиян= ;ию технологичk= 7;ской зрелости разработки ПС в детальной модели СОСОМО сопоставлеl= 5;ы уровни СММ, для каждого из которых приводятся коэффициенm= 0;ы изменения трудоемкоl= 9;ти разработки.<o:p= ></o:p> </spa= n>Для приближен = 85;ой оценки влияния на трудоемкосm= 0;ь некот= ;орых характерисm= 0;ик процессов разработки ПС, в детальной модели СОСОМО выде = 83;ена небольшая группа пока = 79;ателей и соответствm= 1;ющие им наборы рейтингов. Инструментk= 2;льные системы, подде= ;рживающие разработку, описаны качественнm= 9;ми характерисm= 0;иками и рейтингам = 80;, изменяющимl= 0; трудоемкосm= 0;ь в пределах приблизитеl= 3;ьно 20% l= 6;т средней – но= 084;инальной. Уровень технологии = 80; комплекса и = 85;струментал&#= 1100;ных средств особенно сильно влия = 77;т на ТЭП крупных проектов ПС. Поэтому зат = 88;аты на их реализ= 072;цию и применени = 77;, целесообраk= 9;но учитывать конкретно с использоваl= 5;ием функций и характерисm= 0;ик проек= ;та. <o:p></o:p> В модели и таблицах отмечено зн = 72;чительное влияние на трудоемкосm= 0;ь ПС директив = 85;ого огра = 85;ичения сроков разработки</spa= n> относительl= 5;о типовых – но= 084;инальных. При ограничениl= 0; сроков, сокра= ;щению трудоемкосm= 0;и может сопутствовk= 2;ть значительнl= 6;е снижение качества ПС = 080; увеличение рисков реализации проекта. Для уменьшения сроков разр = 72;ботки есть ряд путей, с помощью которых рук = 86;водство может добиваться некоторого ускорения разработки за счёт увеличения трудоемкосm= 0;и и стоимости проекта, для чего рекоме = 85;дуется:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>обеспечить детальные структурирl= 6;вание комплекса п = 88;ограмм на модули и спецификацl= 0;и интерфейса для обеспечениn= 3; максимальнl= 6;го параллелиз= ма работы специалистl= 6;в;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>приобрести и освоить технологичk= 7;ские, инструментk= 2;льные средства дл= 03; более быстр = 86;го кодированиn= 3;, контроля и тестированl= 0;я и обучить разработчи= ков их использо = 74;анию;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;еспечить дополнителn= 0;ную подготовку = 87;рограммист&#= 1086;в и группы тестирован= ия к работе в тематическl= 6;й облас= ;ти функций про = 77;кта;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>привлечь дополнителn= 0;ный вспомогатеl= 3;ьный персонал;<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>отложить нk= 2; время не существеннl= 6;е документирl= 6;вание проекта.<o:p></o:p> Тем не менее, есть предел сокр = 72;щению сроков разработки = 89; по- мощью увеличения числа специалистl= 6;в и приобрете = 85;ия оборудованl= 0;я. При максимальнl= 6; возможном с = 86;кращении сроков разработки до 75% от опт= имального, затраты возрастают на 25%. <o:p></o:p> </spa= n>При разработке комплексов программ систем реального времени бол= ;ьшие затраты могут потребоватn= 0;ся для обеспечениn= 3; тестированl= 0;я и испытаний ПС, которые непосредстk= 4;енно не учитываютсn= 3; моделью СОСОМО. Основ= ные усилия сосредотачl= 0;вались на процесса = 93; программирl= 6;вания и автономно = 81; отладки компонентоk= 4;. На этих этапах выявлялась основная масса дефектов и ошибок, хотя при использовk= 2;нии ПС и сопl= 8;овождении обнаруживаl= 3;ось некоторое и = 93; количество. В последнее в = 88;емя центр тяжести раз = 88;аботки сложных ПС сдвинулся к начальным этапа= ;м и внимание акцентировk= 2;но на предотвра = 97;ение ошибок, прежде всег = 86; путем тщательногl= 6; системного проектировk= 2;ния ПС из готовы= 093; программныm= 3; компонентоk= 4;, а также на комплексноl= 1; отладке и испытаниях = 74; реальном времени. <o:p></o:p> Эта&#= 1087;ы комплексноl= 1; отладки, испытаний = 80; модификациl= 0; программ имеют много общего, в основе которого лежит широкое при = 84;енение их тестиров = 72;ния для обнаруж = 77;ния ошибок и удостовереl= 5;ия функционалn= 0;ной корректносm= 0;и ПС. Разработка детерминирl= 6;ванных тестов при о= 090;ладке модулей и некоторых групп программ в большинстk= 4;е случа= ;ев производитl= 9;я вручную. Однако их доl= 3;я может= ; составлятn= 0; замет= ;ную часть общих затра = 90; на отладку компонентоk= 4;. Достаточно = 72;втономными и локализуе = 84;ыми обычно явля= 02;тся затраты на стохастичеl= 9;кие тесты и тест= 099; в реальном времени, используемm= 9;е при комплек = 89;ной отладке и испытанияm= 3; (см. лекцию 14). <o:p></o:p= > При технико-эко = 85;омическом обоснованиl= 0; проектов ко = 84;плексов программ, на оценку трудоемкосm= 0;и их разработки может оказать сущ = 77;ственное влияние ограничен = 85;ость вычислителn= 0;ных ресурсов специализиl= 8;ованных, реализующиm= 3; ЭВМ реального времени. Эт= 086; привело к необходимоl= 9;ти разрабатывk= 2;ть мето = 76;ы эффективноk= 5;о использоваl= 5;ия аппаратных ресурсов ЭВ = 52;. Одним из важнейших и наиболее общих показ = 72;телей, характеризm= 1;ющих возможностn= 0; применения таких ЭВМ, яв&#= 1083;яется их производ = 80;тельность для конкрет = 85;ых задач реального времени. При этом сущест = 74;енным ограничиваn= 2;щим фактором являются длительносm= 0;ь, в течение которой ЭВМ может быть предоставлk= 7;на для решения данной задачи, или то реальное время, в пределах которого це = 83;есообразно получить ре = 79;ультаты для их практическl= 6;го использоваl= 5;ия. При ограничениn= 3;х ресурсов вследствие требований минимизациl= 0; весов и габаритов специализl= 0;рованных, реализующиm= 3; ЭВМ в авиационныm= 3;, ракетных и космическиm= 3; системах, их экономное использоваl= 5;ие остается актуальным и следует учи = 90;ывать при обоснованиl= 0; соответствm= 1;ющих проектов ПС</sp= an>. <o:p></o:p> Быстр= ый рост в мире масштабов - размk= 7;ров компл= ексов прогр= амм и баз= ; данных</spa= n> , решk= 2;ющих е= диную целев= ую задач= у, потре= бовал создания но- вых= , более эффек= тивных метод= ов разработки </sp= an>слож- ных с= ;истем. = 42;озникла проблема разработ= ;ки функц= ионально закон= ченных ПС и БД и и= х компо-ненто = 74;, потенци= ;- ально= <= /span>готовых </spa= n>к м= ногократноl= 4;у приме= нению в разл= ;ичной внешн= ей и операцио= ;нной среде= , а т= акже в различны= ;х сочетаниях их взаимод = 77;йс- твия. Унифи= 082;ация всегда m= 0;ребует </spa= n>некоторы= ;х ресур= сов, которые в дан= ;- ном с= ;лучае, = 74;ыражает= ;ся в дополнит= ;ельной трудо= емкости создания повторно используемm= 9;х - прогр= амм и данных, = 72; т= акже в увеличен= ;ии необходимоl= 1; па- мяти= и= производ= ;ительности ЭВМ д= ;ля их реализации. </s= pan> Сохра= нение и развитие довольно широкого= ; спектра </spa= n>архитект= ;ур ЭВМ, естес= твенно приве= ло к повт= ;орному испол= ьзованию компо= нентов (ПИК) н = 77; тольк= о на однотипных </sp= an>платформ= ;ах, но и к= разработ= ;ке ПС и БД, пере- но-= симых на различные аппаратные </span= >и о= перационныk= 7; платф= ормы. При этом, выделили= ;сь две те&= #1093;нологическ= ;ие проблемы:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l249 level1 lfo85;tab-stops:list 18.0pt 101.85pt left 234.0pt; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>создание= ; программ= ;ных компо= нентов и баз= ; д= анных, которые рент= абель-но</span= > п= овторно приме= нять и/или </spa= n>переноси= ;ть на ра= ;зличные операционнm= 9;е и аппаратны = 77; платформы;= <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l249 level1 lfo85;tab-stops:list 18.0pt 101.85pt left 234.0pt; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>проблема= ; реализац= ;ии повто= рного испол= ьзования и/или </spa= n>переноса </spa= n>ПС и= БД д= ля созда= ния из них новых систем на иных платформаm= 3;.<o:p></o:p> Увеличениk= 7; за&= #1090;рат при ре= ;шении перво= й пробл= емы должн= о компен-сиров= ;аться с= окращением затра= т при с= ;оздании= ; комплекс= ;ов прогр= амм и баз= ; д= анных на базе готовых </spa= n>компонен= ;тов. Освое= ние метод= ов и средств </spa= n>решения </spa= n>этих проблем </spa= n>позволил= ;о ка- честв= енно изменить= ; п= роцессы со= зда-ния с= ложных– комплексов программ и ре= зко повыс= ить произ= водитель-ность труда специали- стов </span= >при их раз&= #1088;аботке. Это а= ;ктивизи= ;ровало в последние = 75;оды ин- терес= к= проблеме= ; мобильно= ;сти прогр= амм и данных во всех отрас- лях п= ;рименен= ;ие вычис= лительной техни= ки. Создание новых Пi= 7; и= БД путем переноса= ; их с других k= 2;ппаратн= ;ых и операционнm= 9;х плат- форм </span= >стало особенно= ; актуальн= ;ым для современныm= 3; администраm= 0;ивных систе= м госуд= арственногl= 6; и регионал= ;ьного управ- ления= , управлениn= 3; отраслям= ;и и предприя= ;тиями, а также бk= 2;нковс- кими </span= >системам= ;и и в социальн= ;ой сфере= . <o:p></o:p> На практике= ;, при создании нового i= 5;С, н= ;е всегда имеет= ся полны= й набор готовых</span= >, и пригодны= ;х для п= ;рименен= ;ия программнm= 9;х компо-н= ;ентов. Тогда при с= ;борке k= 4;ерсии i= 5;С м= ожет потре= боваться дораб= отка отдел= ьных компо= нентов, их сопряжен= ;ие в новых соче- тания= х, = и создание новых программ= ; для решения дополнит= ;ельных задач. Поэтому целе-сообраk= 9;но оцени= вать трудо= емкость сборо= чного прогр= аммированиn= 3; с учетом m= 5;астичны= ;х затра= т на<= /span> <= /span>новые кl= 6;мпо- ненты= . Относителn= 0;ное сниже= ние трудо= емкости разра= ботки в первом прибл= ижении пропо= рционально доле </span= >готовых </spa= n>ПИК. В пред&= #1077;ле при создании базовой </spa= n>версии i= 5;С п= олностью из многокра= ;тно при- меняе= мых готовых ко = 84;понентов, т= рудоемкостn= 0; может сокра= титься в 3 -</span= > 5 р= аз. В промежут= ;очных случа= ях, когда= готовые </spa= n> компо= ненты используютl= 9;я части= чно, оценк= у измен= ения трудоем- кости= можно провести по степени сокра= щения затра= т на пр= ;о- грамм= ирование и автономную </sp= an>отладку </spa= n>всех необходи= ;мых компо- ненто= в. <o:p></o:p> <o:p></o:p> <h1> <a name=3D"_Toc508102464"></= a><a name=3D"_Toc508102237">5.2. Методика 1 – экспертное технико-эк = 86;номическое<s= pan style=3D'mso-spacerun:yes'> = обоснованl= 0;е проектов программныm= 3; средств</a> <o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> <o:p></o:p= > </sp= an>В эm= 0;ой методике реализоваl= 5; метод прогноза Т = 69;П с учетом экспер= тной оценки минимальноk= 5;о числа факто = 88;ов. Данная методика оценки ТЭП может приме = 85;яться, когда определены цели и общие &#= 1092;ункции проекта ПС, сформулироk= 4;анные в концепции = 080; первичных требованияm= 3; с достоверн = 86;стью около 20 – 40% . Основная цk= 7;ль оценки ТЭП = 211; подготовитn= 0; возможностn= 0; принять обоснованнl= 6;е решение о допустимосm= 0;и дальнейшегl= 6; пl= 8;одвижения проекта в область системного анализа, разработки требований = 80; предваритеl= 3;ьного проектировk= 2;ния. Если оказываетсn= 3;, что рассчит = 72;нные технико-эко = 85;омические показатели = 80; требуемые р = 77;сурсы не могут быт= 100; обеспечены для продолж = 77;ния проекта, то возможны кардинальнm= 9;е решения: либ= 086; изменение некоторых ТЭП и выделяемых ресурсов, либо прекращениk= 7; проектировk= 2;ния данного ПС. Учитывая полноту и достоверноl= 9;ть доступных х = 72;рактеристи&#= 1082; и требовани = 81; к проекту ПС должны бm= 9;ть определены цk= 7;ли и возможная достоверноl= 9;ть технико-эко = 85;омического обоснованиn= 3; продолжениn= 3; проектиров&#= 1072;ния ПС. <o:p></o:p> При первичном технико-эко = 85;омическом обоснованиl= 0; сложных проектов ПС, составляетl= 9;я таблица 5.2 – исходными, для которой являются концепm= 4;ия проекта ПС и комплекс предваритеl= 3;ьных требований</spa= n> к иерархичесl= 2;ому набору функций, которые мог = 91;т быть разбит = 99; на предпола = 75;аемые фактическиk= 7; компоненты ПС. В дальней&#= 1096;ем разбиение может детализироk= 4;аться, формируя упрощенный или более точный уровень абс = 90;ракции и взаимодейсm= 0;вия компонентоk= 4;. Наиболее низкий и глубокий уровень детализациl= 0;, как правило, редко формируетсn= 3; ко времени первоначалn= 0;ной экспертной оценки размера ПС. <o:p></o:= p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>Эти факторы могут быть оценены квалифицирl= 6;ванными экспертами на основе им= 077;ющегося у них опыта реализации предшествоk= 4;авших подобных проектов, а также испол= 00;зования опубликоваl= 5;ных данных. При наличии необходимыm= 3; данных важн = 86; оценить их д= 086;стоверност&= #1100; и возможную точность (20 – 40%).<= span style=3D'mso-spacerun:yes'> Наиме= ;нее точный из перечисленl= 5;ых факторов по = 83;ностью определяет достоверноl= 9;ть расчета технико-эко = 85;омических показателеl= 1; проекта ПС, поэтому желательно, чтобы значения точности экспертногl= 6; оценивания перечисленl= 5;ых факторов бы = 83;и сбалансироk= 4;аны. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>При наличии перечисленl= 5;ых исходных да = 85;ных и положителn= 0;ной оценке целе = 89;ообразност&#= 1080; экспертногl= 6; анализа ТЭ = 55; проекта может реали = 79;овываться методиl= 2;а, состоящая и = 79; следующих шагов:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>опр= еделение класса, сложности функций про = 77;кта программноk= 5;о средства;<o:p></o:p>= <![if !supportLis= ts]>-&nb= sp; = <![endif]>экс= пертная оценка размера – масштаба, чи= 089;ла строк предполагаk= 7;мого текста разрабатывk= 2;емых программ, с учетом размера повторно ис = 87;ользуемых компонентоk= 4; и характери = 89;тик возможного языка программирl= 6;вания;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>экс= пертная оценка возможной средней про = 80;зводительн&#= 1086;сти труда специалистl= 6;в при разрабо = 90;ке программ и/и= 083;и стоимости (и длительносm= 0;и) разработки одной сроки текста программ проекта ПС;<o:p></o:p= > <![if !supportLis= ts]>-&nb= sp; = <![endif]>рас= чет возможной полной трудоемкосm= 0;и и длительно = 89;ти разработки проекта ПС, а также среднего числа специ = 72;листов, необходимыm= 3; для его реализации;<o:p= ></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>обо= бщение основных технико-эко = 85;омических показателеl= 1; и полной стоимости разработки проекта ПС, анализ результатоk= 4; и технико-экономи-ческое обоснованиk= 7; рентабелn= 0;ности продолжениn= 3; проектировk= 2;ния комплекса программ.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Достовернl= 6;сть прогнозов ТЭП зависит, прежде всег = 86;, от точносm= 0;и экспертной оценки исходных данных: размера ̵= 1; масштаба ПС = 080; от достовер = 85;ости экспертной оценки производитk= 7;льности труда специ = 72;листов или оценки стоимости разработки одной строк = 80; текста программ (см. таблицу 5.2). Кроме того, экспертны&= #1077; оценки зависят от компетенциl= 0; и объективн = 86;сти экспертов, и= 093; &#= 1086;птимистичн= ости, пессимистиm= 5;ности, знания суще = 89;твенных особенностk= 7;й проекта. <o:p></o:p> Экспертнаn= 3; оценка размера про = 77;кта программноk= 5;о средства наиболее сложная задача в это= 081; методике. Пl= 8;иступая к разработк = 77; комплекса программ, ка= 082; в любой проф= 077;ссионально&= #1081; деятельносm= 0;и, необходимо сначала провести реалистичеl= 9;кую оценку возм = 86;жного м= ;асштаба проекта – поставленнm= 9;х целей, ресурсов проекта и вы= 076;еленного времени. Задач= ;а управления масштабом состоит в задании базовых требований, = 082;оторые включают разбитое на компоненты = 86;граниченно&#= 1077; множество функций и требований, намеченных для рk= 7;ализации в конкретно = 81; версии= проекта. Бk= 2;зовый уровень масштаба должен обеспечиваm= 0;ь:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>при= емлемый для заказчика минимум функций и требований = 82; проекту;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>разумн= 091;ю вероятностn= 0; успеха с точки зрени= 03; возможностk= 7;й и ресурсов коллектива разработчиl= 2;ов.<o:p></o:p> При оценивании масштаба следует определить приоритеты функций для установленl= 0;я состава работ, согласованl= 5;ого между заказ = 95;иком и разработч = 80;ком, которые обn= 3;зательно должны быть выполнены и для определ = 77;ния базового уровня масштаба конкретногl= 6; проекта с допустимым риском неуспешной реализациl= 0;. Сокращение масштаба проекта до размеров, адекватных выделенномm= 1; времени и ре= 089;урсам, может привести к к= 086;нфликтам заказчиков = 80; разработчиl= 2;ов. Для уменьшения вероятностl= 0; таких конфликтов целесообраk= 9;но активно привлекать заказчиков = 82; управлению их требованияl= 4;и и масштабом проекта, что= 073;ы обеспечить как качеств = 86;, так и своевременl= 5;ость разработки ПС.<o:= p></o:p> <sp= an style=3D'font-size:14.0pt'> <s= pan style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>Эl= 2;спертные оценки удельных затрат на строку текста прог = 88;амм относятся к полному циклу разработки крупных комплексов программ, начиная от с= 086;здания концепции и требований до завершен = 80;я испытаний и передачи программноk= 5;о продукта заказчику или пользоватеl= 3;ям, с учетом всего состава коллектива = 89;пециалисто&#= 1074; всех квалификацl= 0;й. По мнению некоторых специалистl= 6;в, несмотря на появление новых меm= 0;одов и инструмен = 90;альных средств разработки сложных ПС, средняя производитk= 7;льность при их создании за = 087;оследние двадцать ле = 90; осталась почти неизменной = 80; составляет около 3000 строк кода на одного разработчиl= 2;а проекта в го= 076; (порядка 250 строк на человеко-ме = 89;яц). Это отражае = 90; то, что уменьшение = 74;ремени, затрачиваеl= 4;ого на цикл разработки, не может быт= 100; достигнуто за счет значительн= ого повышения производитk= 7;льности труда отдельных с = 87;ециалистов. Причем это практическl= 0; не зависит о= 090; усовершенсm= 0;вований языка программирl= 6;вания, организациl= 6;нных усилий со стороны менеджеров, от наличия или отсутствия некоторых о = 90;дельных видов инструментk= 2;рия и автоматизаm= 4;ии работ, хотя значительнm= 1;ю роль играет увеличившаn= 3;ся д= ;оля повторно используемm= 9;х компонентоk= 4; (ПИК). На самом деле при дос= 090;аточно высоком уровне техн = 86;логии (3 – 4 уровень СММ – см. лекцию 3) большое зна = 95;ение имеет возросший размер и сложность с = 86;става функционалn= 0;ных задач компл = 77;ксов программ, а также значительнl= 6;е повышение требуемого качества создаваемыm= 3; ПС. <= o:p></o:p> </spa= n>В качестве ориентиров</spa= n> при экспертной оценке ТЭП, для таблицы 5.2 можно использоваm= 0;ь следующие д = 72;нные сре = 76;ней трудоемкосm= 0;и разработки сложных комплексов программ. Весьма общи = 77; данные опуб = 83;икованы в виде широких диапазонов производитk= 7;льности труда: дл= 03; относительl= 5;о простых ПС – 8 = LOC= на человеко-де = 85;ь, и 4 LOC на человеко-де = 85;ь для достаточно сложных ПС. Так же приво= 076;ятся широкие диапазоны п = 88;оизводител&#= 1100;ности труда при разработке программ на ассемблере R= 11; 60 – 500 LOC на чело = 74;еко-месяц, и 50 – 300 LOC на человеко-ме = 89;яц для языков высокого ур = 86;вня. Подобные оц = 77;нки можно испол= 00;зовать к&= #1072;к ориентиры при первичных определениn= 3;х ТЭП.<o:p></o:p> Более точные оценки производитk= 7;льности при разработке программ различного размера и классов на основе обобщения статистичеl= 9;ких данных множ = 77;ства проектов пр = 77;дставлены в базовой модели СОСОМО:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>для программ администраm= 0;ивных систем (ИПС) размером по = 88;ядка 30 тысяч строк оценка производитk= 7;льности составляет около 220 строк на человеко-= 084;есяц, а для ПС размером 500 тысяч строк = 211; 160 строк на чел= ;овеко-месяц;<o= :p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>для встроенных комплексов программ реального времени раз = 84;ером 30 тысяч строк рекомендуеm= 0;ся для оценок использоваm= 0;ь производитk= 7;льность около 140 строк на человеко-= 084;есяц, а для крупны= 093; ПС размером 500 тысяч строк предлагаетl= 9;я значение производитk= 7;льности около 80 строк на человеко-= 084;есяц.<o:p></o:p> Эт&#= 1080; данные находятся в середине представлеl= 5;ных выше диапаз = 86;нов и их целесоо= 073;разно использоваm= 0;ь при экспертной оценке полной труд = 86;емкости разработки соответствm= 1;ющих новых ПС. При использоваl= 5;ии готовых повторно используемm= 9;х компонентоk= 4; обобщенная производитk= 7;льность труда возрастает = 80; зависит от доли таких компонентоk= 4; в комплексе программ. Их также можно использоваm= 0;ь для оценки пl= 6;лной стоимости проекта конкретногl= 6; ПС. Однако при этом необходимы удельные данные средней стоимости труда одног = 86; человеко-ме = 89;яца специалистl= 6;в в конкретно = 84; предприятиl= 0; с учетом все= 093; накладных расходов, ко= 090;орые могут различатьсn= 3; в несколько раз. Такие сведения обычно являются коммерческl= 6;й тайной, и при использоваl= 5;ии данной методики дл= 03; определеннl= 6;го проекта ПС, их слk= 7;дует запрашиватn= 0; у экономичесl= 2;их служб конкр = 77;тного предприятиn= 3;м. Тем нk= 7; менее, опубликоваl= 5;ы о= ;риентиры стоимост= ;и разработки одной строк = 80; текста программ ре = 72;льного времени около= ; 100$ и бол= ее, а для = 72;дминистрат&#= 1080;вных систем около 20$ – 50$. <o:p></o:p> </spa= n>Эксперm= 0;ная оценка длительносm= 0;и разработки</spa= n> сложных ПС (таблица 5.3), может базироватьl= 9;я на формулах модели СОСОМО (см. п. 5.3).<= /span> Основой дл= 03; расчета длительносm= 0;и целесообраk= 9;но использоваm= 0;ь рассч= ;итанную ранее трудоемкосm= 0;ь разработки проекта ПС, от которой н= 077; линейно зависит длительносm= 0;ь (месяцы) приблизитеl= 3;ьно равная труд = 86;емкости (человеко-ме= 089;яцы) в степени 0,3. Например, крупные проекты ПС р= 077;ального времени размером около 500 тысяч строк требуют для реализации около 3,5 лет, а небольшие (30 тысяч строк) – около одного года. При этом сле= 076;ует учитывать, что необходимаn= 3; численностn= 0; коллектива специалистl= 6;в изменяется = 74; десяток раз.<o:= p></o:p> Экспертна= 03; оценка необходимоk= 5;о числа специ = 72;листов всех кв&= #1072;лификаций рассчитываk= 7;тся путем деления полной трудоемкосm= 0;и разработки ПС на длител= 100;ность её реализац = 80;и. Для примера крупного проекта ПС р= 077;ального времени, размером 500 тысяч строк,<sp= an style=3D'mso-spacerun:yes'> необходим = 86;е число специ = 72;листов достигает 160 ч= еловек, а для относительl= 5;о небольшого проекта (30 тысяч строк) </= span>– в десять раз меньше (16 человек). Аналогич&= #1085;о можно получить оценки необходимоk= 5;о числа специ = 72;листов на выделенных крупных этапах разр = 72;ботки ПС, что полезно для первичного формированl= 0;я коллектива = 80; оценки возм = 86;жности реализации им конкретн = 86;го проекта ПС (см. таблицу 5.1). </= span> <o:p></o:p></sp= an> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </sp= an> <o:p></o:p></span= > <h1><a name=3D"_Toc508102465"></a><a name=3D"_Toc508102238">5.3. Методика 2 – оценка технико-эко = 85;омических показателеl= 1; = проектов программныm= 3; продуктов с учетом сово = 82;упности факторов = предваритk= 7;льной модели СОСОМО </a>II<o:p></o:p></h1> <o:p> </o:p> <s= pan style=3D'font-size:14.0pt;color:windowtext'> </sp= an>В СО= 057;ОМО II для оценки ТЭП представлеl= 5;ы две модели – дл= 103; этапов пред = 74;арительног&#= 1086; и детальног = 86; проектировk= 2;ния (см. Boehm B.W. et al.<s= pan lang=3DEN-US style=3D'font-size:14.0pt;font-family:"Times New Roman","serif= "; color:windowtext;mso-ansi-language:EN-US'>= Software cost estimation with COCOMO II. Prentic= e&= nbsp; Hall PTR. New Jersey. 2000)</spa= n>. Предваритk= 7;льная модель пред = 85;азначена для анализа общих, архитек= ;турных решен= ;ий и выработки стратегий последующеl= 1; разработки при начальных сведениях о содержании предваритеl= 3;ьного проекта. Дет= 072;льная модель рекомендуеm= 0;ся для примене = 85;ия при разработке наиболее сложных и до= 088;огих систем, когда требуется тщате= ;льный учет ряда факторов, влияющих на оценку стои = 84;ости на уровне техническоk= 5;о проекта ПС. В &= #1086;беих моделях исх = 86;дным и, определяющl= 0;м достоверноl= 9;ть прогнозов, является размер комп = 83;екса программ (с учетом повторно ис = 87;ользуемых компонентоk= 4;) и совокупносm= 0;ь набора влияющих факторов. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> На </span= >этапе предваритеl= 3;ьного проектировk= 2;ния комплекса п = 88;ограмм, после утверждениn= 3; требований = 80; концепции проекта, пов= 099;шается достоверноl= 9;ть данных о функциях, спецификацl= 0;ях, компонентаm= 3; и структуре разрабатывk= 2;емого ПС. Это позволяет, п= 088;ежде всего, более точно оцени = 90;ь размер – масштаб ПС и возможностn= 0; использоваl= 5;ия готовых про = 75;раммных компонентоk= 4; из других аналогичныm= 3; проектов. Если достоверноl= 9;ть оценки размера ПС достигает 15 – 20%, то при определ = 77;нии ТЭП, целесообрk= 2;зно сбалансироk= 4;ано выделять и учитывать ф = 72;кторы, влияние которых на трудоемкосm= 0;ь и стоимость достаточно велико, и составляет также около 20%. Таких= факторов может быть около 5 – 10, и их число зависит от конкретных = 93;арактерист&#= 1080;к объекта и среды разработки ПС. При технико-эко = 85;омическом обоснованиl= 0; проекта ПС н= 072; этом этапе, с&#= 1086;став и номенклатуl= 8;а учиты= ;ваемых факторов должны выбираться путем включения в анализ, тех факторов, ко= 090;орые достаточно влияют на ТЭ= 055; конкретногl= 6; проекта. <o:p></o:p> Так как величи= на и достоверноl= 9;ть определениn= 3; размера проекта ПС <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>кl= 3;ючевой фактор последующеk= 5;о технико-эко = 85;омического анализа, то целесообраk= 9;но применять н = 77;сколько доступных методов для его оценива = 85;ия. Конкретизаm= 4;ия функций, структуры П = 57; и состава компонентоk= 4; проекта позволяет более досто = 74;ерно определить размеры групп прогр = 72;мм и, суммируя их, рассчитать размер всег = 86; комплекса программ. Кроме того, на этом этап= 077; повышается возможностn= 0; выбора и использоваl= 5;ия аналогов данного проекта, так как становя = 90;ся более определеннm= 9;ми задачи, функ= 094;ии и компонент = 99; разрабатывk= 2;емого ПС, для, котор= ;ого желательно найти аналоги с известными = 72;пробирован&#= 1085;ыми характерисm= 0;иками. Ос= обенно сильно на ТЭ= 055; влияет использl= 6;вание готовых компонентоk= 4; из предшест = 74;ующих разработок. </s= pan>Пl= 8;и анализе аналогов могут быть выделены ко = 84;поненты, пригодные для повторного применения = 74; новом проекте. Это позволяет о = 94;енить возможную долю использоваl= 5;ия готовых компонентоk= 4; и тем самым определить = 01;квивалентн&#= 1099;й размер комп = 83;екса программ, по= 076;лежащий непосредстk= 4;енной разработке. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n>Для трех классо = 74; комплексов программ в п= 088;едваритель&= #1085;ой модели СОСОМО II), представлеl= 5;ы коэфф= ициенты для расчета </s= pan>зависимо= ;сти трудо= емкости разработки </sp= an>про- грамм С (челове&#= 1082;о-месяцы) от &#= 1080;х объемов – П (тысяч&#= 1080; строк текста) (таблиц&#= 1072; 5.4). <= /span>Для аппроксимац= ии завис= имости трудо= емкости от размера ПС, рекомендуеm= 0;ся испол= ьзовать степ = 77;нную функцию </spa= n>вида: <o:p></o:p>= = &nb= sp; = &nb= sp; С =3D А × = П Е . = = (5.1)<o:p></o:p> = <o:p></o:p> При р= ;азработ= ;ке ПС бол= ;ьшого размера- , должна возрастать </sp= an>сложност= ;ь разра= ботки по сравнени= ;ю с ПС малого объема, так как в боль&= #1096;их прогр= аммах сущес= твенно усложняютсn= 3; взаимосв= ;язи компо= нентов по информации </sp= an>и управl= 3;ению, а= также становят= ;ся более= трудоемк= ;ими проце= ссы планиро= ;ва- ния= и управления проектом в х= оде разра= ботки. Выдви= нутая гипо- теза= , = о возрастаниl= 0; трудоемк= ;ости разра= ботки с ростом размера ПС быстр= ее, чем п= ;о линейному = 79;акону, = 89;праведл= ;ива, если </span= >показате= ;ль степе= ни в уравнении = 88;егресси= ;и Е > 1. - В ряде работ опре= делены коэффициенm= 0;ы А и Е = 74; ура= ;в- нения= х с= тепенной регре= ссии, показ= ывающие характер зависимо= ;сти трудо= емкости от размера ПС. В таблице 5.4. представлеl= 5;ы значения коэффициенm= 0;ов регрессии для моделей СОСОМО для трех основных классов проектов программныm= 3; средств. Выражение (5.1) l= 9; использоваl= 5;ием этих коэффициенm= 0;ов и значений размера ПС – П в тысячах строк ассемблера</spa= n> рекомендуеm= 0;ся для прогнозироk= 4;ания трудо-емкос = 90;и полной разработки = 74; чk= 7;ловеко-меся&#= 1094;ах. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;color:windowtext;mso-no-proof:yes'> Длит&= #1077;льность разработки программныm= 3; средств- является= ; важнейши= ;м ТЭП- , поскольку ч= ;асто она определяет </span= >общие сроки= разработ= ;ки систе= м, а значит, = 73;ыстроту= ; реали= зации идей в различны= ;х облас= тях автомат= ;и- зации= . При определениl= 0; коэффициенm= 0;ов в табл= ;ице 5.5 за начало l= 8;азработ= ;ки ПС при= ;нят момен= т начал= а создания техни= ческого задан= ия, а= за окончание – заве= ;ршение - испыт= аний программноk= 5;о продукта в ц= елом .&= nbsp; Диапазону размеров современ= ;ных ПС в т= ри-четыре поряд= ка (до 10 млн. строк) соответс= ;твуют прибл= изительно такие= же ди= ;а- пазон= ы и= зменения трудоемкоl= 9;ти и= стоимост= ;и их разработ= ;ок. = Од- нако= , очевидна принципиалn= 0;ная нерен= табельностn= 0; разра= ботки да- же очень сложных </spa= n>ПС б= олее 5 лет. = 057; д= ругой сторо= ны, программы да&= #1078;е в нескольк= ;о тысяч строк по пол&= #1085;ому техно= логическомm= 1; циклу= с испытаниямl= 0; как продукции - редко создаются = 79;а время, меньш= ее, чем п= ;олгода-- год. i= 8;аким образом, </sp= an>вариация длительносm= 0;ей разра= боток ПС - меньш= е, чем в= ;ариация= ; их трудl= 6;емкости, и не превы= шает деся- тикра= тный д= иапазон. Длите= льности разра= боток – Т огl= 8;аничены сверх= у и снизу, и о= дним из основных= ; факторов= ;, определя= ;ющих эти грани= цы, являе= тся масштаб комплекса = 87;рограмм= ; <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol;mso-no-= proof: yes'>-</= span> П. <o:p></o:p> Чтобы сократить ош&= #1080;бки, связа= нные с неопреде= ;ленностью из- мерен= ия размерk= 2; программ= ;, исследов= ;ана зависимо= ;сть длительно- сти р= ;азработ= ;ки от ее трудоемкосm= 0;и. Учитывалась т= ;оль- ко трудоемк= ;ость не= посред-стве = 85;ной разработки </sp= an>программ= ; С </span= >без затра= т на средства= ; автомати= ;зации разра= ботки- . Обработка т= ;ех же, что= выше, наборов </spa= n>данных l= 7;озволил= ;а полу- чить коэффициенm= 0;ы уравн= ения регре= ссии представлеl= 5;ные в таблице 5.5. Обобщенныk= 7; данные длительносm= 0;и разработки R= 11; Т по l= 2;лассам комплексов </sp= an>программ= ; аппроксим = 80;ро- ваны уравнениямl= 0; регресси= ;и <= /span>по методу наиме= ньших квадр= атов в зависимостl= 0; от размера ПС и= от трудоемкосm= 0;и их ра= ;з- работ= ки: <o:p></o:p></spa= n> <o:p> </o:p> = Т =3D G</span= > × С= H</span= > . = &nb= sp; = &nb= sp; = (5.2)<o:p></o:p> <o:p></o:p> Установлен = 86; , чт&= #1086; длительн= ;ость разра= ботки ПС меньше подвергаетl= 9;я измен= ениям при а= ;втомати= ;зации разра= ботки или д= ;ругими </spa= n>метода- ми, чем трудоемкост= ь или п= ;роизвод= ;ительность труда= . Н= еобходи- мость= в= ыполнения при р= ;азработ= ;ке ПС определе= ;нной совокупносm= 0;и этапо= в и операций= ; в з= аданной техно= логической последоваm= 0;ельнос- ти остается= ; более или менее постоянной при р= ;азличных воздеl= 1;ст- виях </span= >на процесс разра= ботки. Исклю= чением являе= тся применение повторно используемm= 9;х компонентоk= 4; ( ПИК), = 87;ри котором значител= ;ьно сокращаютl= 9;я этапы= п= рограмми- рован= ия и автономной отлад= ки модул= ей и групп программ= ;, а так- же в т= ой или и= ;ной степени </spa= n>длительн= ;ость други= х этапо= в.. Поэто= му завис= имость T</s= pan> , о<= span style=3D'mso-no-proof:yes'>т доли ПИК о= ;казывае= ;тся нелин= ейной, и заметное= ; сокращен= ;ие длительносm= 0;и разра= ботки прояв= ляется тольк= о при с= ;оздании= ; базовой </spa= n>версии i= 5;С п= рактически полно= стью из готовых компонентоk= 4;. <o:p></o:p> </s= pan>Оценка требуемого среднего числа специ = 72;листов для конкрет = 85;ого проекта ПС предваритеl= 3;ьно может быть рассчитана путем деления оценки величины трудоемкосm= 0;и разработки (5.1) на длительносm= 0;ь разработки (5.2= ). Однако рациональнl= 6;е число специ = 72;листов, участвующиm= 3; в проекте ПС распределяk= 7;тся не равномер = 85;о по этапам работ (см. таб&= #1083;ицу 5.1). Поэтому целесообраk= 9;но определять число и квалификацl= 0;ю необходимыm= 3; специалистl= 6;в с учетом этапов разработки комплексов программ. О= 073;общенные значения пр = 77;дварительн&#= 1086;го расчета ТЭП целесообрk= 2;зно оформлять в виде таблиц = 99; 5.3, где оценки представляn= 2;тся также с учетом пессимистиm= 5;еских и оптимисти = 95;еских результатоk= 4; определеl= 5;ия масштаба проекта комплекса п = 88;ограмм. <o:p></o:p> Для= учета= ; влияниn= 3; на трудоемкосm= 0;ь различных факторов удобно пользоватьl= 9;я коэффициенm= 0;ами (рейтингами) изменения трудоемкоl= 9;ти (КИТ) –&= nbsp; М (i), учитывающl= 0;ми зависимостn= 0; от i-го фактора l= 5;а совокупные затрат труда. В них входя= 090; факторы процесса непосредстk= 4;енной разработки, факторы программноl= 1; и аппаратур = 85;ой оснащенносm= 0;и, а также квалификацl= 0;я специалистl= 6;в (таблица 5.6). Затраты на разра= ;ботку С и объем прогр = 72;мм П могут быть связаны через показ = 72;тель интегральнl= 6;й с= ;редней производитk= 7;льности труда= разработчl= 0;ков Р. Непосредсm= 0;венно затраты на разработку можно представитn= 0; как частное от размера П= 057; и производи = 90;ельности труда Р =3D 1 / &= #1040;, корректируk= 7;мой произведенl= 0;ем коэффициенm= 0;ов изменения трудоемкосm= 0;и (КИТ – М</spa= n> (i) ) :<o:p></o:p> = <o:p></o:p> = П = Е <o:p></o:p> C =3D <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>---</span= > × <span style=3D'font-= size: 14.0pt;font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi= -font-family: "Times New Roman";mso-bidi-font-family:"Times New Roman";color:windowtext; mso-char-type:symbol;mso-symbol-font-family:Symbol'>P &#= 1052; (i) =3D А × П Е × <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>P</span= > &#= 1052; (i) . = &nb= sp; (5.3)<o:p></o:p> = Р </spa= n>i = &nb= sp; i<o:p></o:p> <o:p></o:p> </spa= n> Средн= яя производитk= 7;льность труда коллектива специалистl= 6;в при разработке сложного полностью нового комплекса п = 88;ограмм Р= в выражении (5.3) может служить ориентиром для сравнен = 80;я эффективноl= 9;ти труда при создании различных п = 88;оектов ПС. Эта харак&#= 1090;еристика, конечно, ра= 079;личается для различных классов, размеров и других пара = 84;етров комплексов программ, однако диапазон этих различ = 80;й не столь велик как из= 084;енения размера и требований = 82; качеству. Та= 082; при диапазоне изменения размеров программ реального в = 88;емени на четыре порядка средняя производитk= 7;льность труда изменяется только в два раза, что в ряде случае = 74; существеннl= 6; облегчает упрощенные оценки и про= 075;нозировани&= #1077; ТЭП. <o:p></o:p> В предва= рительной модели СОСОМО= II при достаточноl= 1; достоверноl= 9;ти определениn= 3; масштаба ПС рекомендуеm= 0;ся в выражении (5.= 3) учитывать семь фактор = 86;в М (i), представлеl= 5;ных в таблице 5.6. Для каждого из них в табл&#= 1080;це 5.7 приведены значения рейтингов (коэффицие = 85;тов изменения трудоемкосm= 0;и), которые целесообраk= 9;но использоваm= 0;ь при выборе определеннl= 6;го содержания факторов конкретногl= 6; проекта ПС, а также свободный столбец для выбранных значений. Результаты уточненногl= 6; расчета трудоемкосm= 0;и проекта ПС п= 086; формуле (5.3) следует использоваm= 0;ь для последующеk= 5;о определениn= 3; длительносm= 0;и (выражение 5.2) l= 0; требуемого среднего числа специалистl= 6;в. <o:p></o:p>= <o:p> </o:p> <h1><a name=3D"_Toc508102466"></a><a name=3D"_Toc508102239">5.4. Методика 3 – уточненная оценка технико-эко = 85;омических = &nb= sp; показателk= 7;й проектов пр = 86;граммных продуктов с учетом полной сово= купности факторов детальной м = 86;дели СОСОМО </a>II.2000<sp= an style=3D'mso-fareast-font-family:"MS Mincho"'><o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'><o:p> </o:p> П = 88;и д= ;етальном проектировk= 2;нии возможно значительнl= 6;е повышение точности определениn= 3; размера – ма= 089;штаба проекта комплекса программ. После= ;довательна= 03; детализациn= 3; и конкретизаm= 4;ия проекта ПС позволяет уточнять ег = 86; будущий размер и привлекать для расчета трудоемкосm= 0;и большее число факто = 88;ов, способных повысить точность пр = 86;гноза всех ТЭП. Разработка полного содержания спецификаm= 4;ий функций и структуры программныm= 3; компонентоk= 4;, их вз= ;аимодейств = 80;я и интерфейсоk= 4;, а также архитектурm= 9; всего комплекса программ и базы данных,<sp= an style=3D'mso-spacerun:yes'> обычн= ;о позволяют повысить точность определениn= 3; размера ПС, приблизитеl= 3;ьно на 10%. Поэтому пр = 80; расчете трудоемкосm= 0;и разработки при прогнозироk= 4;ании целесообраk= 9;но выбирать и учитывать влияние ряд = 72; дополнителn= 0;ных факторов из таблицы 5.8, которые не оценивалисn= 0; в методиках 1 и 2, вследствие</s= pan> их отноl= 9;ительно меньшего влияния. <o:p></o:p> Таких дополнителn= 0;ных факторов обычно може = 90; быть выделе = 85;о около 10, котор= ые целесообраk= 9;но рассматривk= 2;ть и учитывать при оценках,<sp= an style=3D'mso-spacerun:yes'> если он способен = 080;зменить трудоемкосm= 0;и разработки конкретногl= 6; проекта на 5 – 10%. Анали= ;з, выбор и оценивани = 77; коэффициенm= 0;ов влияния F ( j ) и <sp= an style=3D'color:windowtext;mso-bidi-font-weight:normal;mso-bidi-font-style:i= talic'>М ( i ),= этих дополнителn= 0;ных факторов до = 74;ольно сложный процесс. Он оправдан, когда совместное влияние совокупносm= 0;и этих дополн = 80;тельных факторов может измен = 80;ть оценки трудоемкосm= 0;и на 10 – 20%. В результа = 90;е расчет трудоемкосm= 0;и несколько усложняетсn= 3;, однако процессы последующеk= 5;о расчета дли = 90;ельности разработки = 80; необходимоk= 5;о числа специ = 72;листов практическl= 0; не изменяются. = 042; целом, процессы методики 3 технико-эко = 85;омического обоснованиn= 3; проекта ПС с учетом ряда дополнителn= 0;ных факторов, практичесl= 2;и не отличает = 89;я от предыдущей предваритеl= 3;ьной методики 2, однако требуется более тщательное определениk= 7; размера комплекса программ, и оценивания влияния на трудоемкосm= 0;ь разработки большего числа факторов.<o:p></o:p>= Для более точного технико-эко = 85;омического обоснованиn= 3; проектов ПС</sp= an> при детальном проектировk= 2;нии обычно целесообраk= 9;но учитывать влияние ряд = 72; дополнителn= 0;ных факторов из четырех гру = 87;п позволяет повысить достоверноl= 9;ть прогнозироk= 4;ания технико-эко = 85;омических показателеl= 1; ПС до уровня около 5 – 10%. В дет= альной модели СОСОМО II влиян= ие на трудоемкосm= 0;ь определяют 22 фактора, из которых пят= 00; – масштабны = 77; факторы, характеризm= 1;ются множителем </sp= an>F ( j ) <sp= an style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho"'>в значении степени раз = 84;ера ПС, а 17 множителеl= 1; <= /span>M = ( i= ) непосредстk= 4;енно изменяют трудоемкосm= 0;ь разработки. Перечень, ма= 082;симальные значения и содержание этих множит = 77;лей представлеl= 5;о в таблице 5.8. Пр= ;и этом номина = 83;ьными (средними) ниже принимаютсn= 3; все M ( i ) </span= >=3D 1,00, при которы = 93; соответствm= 1;ющий фактор практическl= 0; не влияет на трудоемкосm= 0;ь ПС. <o:p></o:p> Для выполнения оm= 4;енок трудоемкосm= 0;и разработки</spa= n> (человеко-ме= 089;яцы) в детальной модели СОСОМО II предложены выражения, уточняющие зависимостl= 0;, представлеl= 5;ные выше в п. 5.3: </span= > </spa= n> = &nb= sp; <o:p></o:p> <s= up> = &nb= sp; = &nb= sp; n<sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext; mso-no-proof:yes'> = &nb= sp; = &nb= sp; <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = C =3D &= #1040; × П E<s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> × <span style=3D'font-size:14= .0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";mso-bidi-font-family:"Times New Roman";color:windowtext; mso-char-type:symbol;mso-symbol-font-family:Symbol'>P M ( i ) , = &nb= sp; = &nb= sp; (5.4)<o:p></o:p> = &nb= sp; </spa= n>i =3D 1 = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> = &nb= sp; = &nb= sp; 5<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> где: &= nbsp; А =3D 2,94; E =3D B + 0,01× <span style=3D'font-size:14.0pt;font-famil= y: Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times= New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>å F ( j ); B =3D 0,91. = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = &nb= sp; = &nb= sp; = j =3D 1 </spa= n><o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> Для прогнозироk= 4;ания длит&#= 1077;льности (месяцы) разработки ПС рекоменд = 91;ются выражения: = = &nb= sp; = &nb= sp; = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = Т =3D </sp= an>G</spa= n> × С</sp= an> H , = &nb= sp; = &nb= sp; = &nb= sp; (5.5)<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> = &nb= sp; = &nb= sp; = &nb= sp; = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> где: G =3D 3,67; <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = &nb= sp; = &nb= sp; 5 <o:p></o= :p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> = H = =3D D + 0,02× 0,01× <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>å= F (j</spa= n>) =3D D + </spa= n>0,02×(E</spa= n> – B) ; D =3D 0,28. <o:p></o:p> = &nb= sp; = j<sp= an style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho"'> =3D 1</span= > <o:p></o:p= > <o:p> </o:p> В модели СОСОМО II подд&= #1077;рживаются вероятностl= 5;ые диапазоны оценок, представляn= 2;щие одно станда = 88;тное отклонение на фоне наиболее достоверныm= 3; оценок. При использоваl= 5;ии представлеl= 5;ных выражений для прогнозироk= 4;ания ТЭП конкретных проектов сл = 77;дует выбирать набор факторов (кk= 2;либровать модель), имеющих наибольшие значения ко= 01;ффициентов изменения трудоемкосm= 0;и (КИТ) F ( j ) и M ( i ) </span= > &#= 1074; соответствl= 0;и с характери = 89;тиками конкретногl= 6; проекта и ср= 077;ды разработки = 80; вставлять вm= 9;бранные значения в таблицу 5.8. Значения этих коэффициенm= 0;ов и уровни оценок их влияния на трудоемкосm= 0;ь по основным = 074;ыделенным группам факторов представлеl= 5;ы в модели СОСОМО II. <o:p></o:p> З= 072;казчик может заказать разработку специальныl= 4; образом калибр= ованной версии коэ = 92;фициентов в формулах (5.4) = 80; (5.5), которая должна боле = 77; точно отраж = 72;ть применяемm= 9;е технологичk= 7;ские процессы, особенностl= 0; и возможностl= 0; проекта ПС, чем в методи= 082;е 2 . При калибровке модели СОСОМО II последоватk= 7;льно выполняютсn= 3; следующие процедуры для конкретногl= 6; проекта: <o:p></o:p> = <![if !supportLists]>-&nb= sp; = &nb= sp; <![endif]>выбир= 072;ется набор факторов M ( i ) <= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif"'>, оказывающиm= 3; наибольшее вли-яние на прогнозируk= 7;мую трудоемкосm= 0;ь проекта ПС;<o:p></o:p= > <![if !supportLists= ]>-&nb= sp; = &nb= sp; <![endif]>устанав= ;ливаются значения масштабных факторов F = ( j );<o:p></o:p> <![if !supportLists= ]>-&nb= sp; = &nb= sp; <![endif]>для каждого из выбранных факторов производитl= 9;я оценка коэффициенm= 0;а изменения т = 88;удоемкости для анализи = 88;уемого проекта ПС.<o:p></o:p= > </spa= n>Выбор с= ;остава и оценку факторов, влияющих н = 72; ТЭП конкрет = 85;ого проекта ПС предваритеl= 3;ьно целесообраk= 9;но проводить п = 86; шагам при калиброванl= 0;и модели СОСОМО II на основе совокупносm= 0;и 22 факторов из таблицы 5.8. Первоначаl= 3;ьно должна производитn= 0;ся оценка коэффициенm= 0;ов влияния пяти групп факторов = - F ( j ). </sp= an>В выраженияm= 3; (5.4), (5.5) значения M ( i ) отражаю= ;т коэффициенm= 0;ы влияния i -ых факторов на трудоемк = 86;сть разработки ПС, которые первоначалn= 0;но (все n ) считаются равными единице. Предваритеl= 3;ьный расчет трудоемкосm= 0;и и длительносm= 0;и разработки ПС при M ( i ) =3D 1 может слу = 78;ить уточненныl= 4; ориентиром, так как он базируется на более точном знач = 77;нии размера проекта комплекса п = 88;ограмм и более адекватных значениях основных коэффициенm= 0;ов, чем в l= 4;етодике 2. </span= ><o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal;mso-bidi-font-styl= e: italic'> Выб= ирать и учитывать следует те факторы, ко= эффициенты</spa= n> влияния которых на трудоемкосm= 0;ь в конкретно = 84; проекте, имеют достаточнуn= 2; величину, сбалансироk= 4;анную с точностью определениn= 3; размера ком = 87;лекса программ ил = 80; превышают е= 05;. Эти факторы можно разделить н = 72; две группы, которые существеннl= 6; различаютсn= 3; по степени влияния на трудоемкосm= 0;ь разработки ПС. В первую группу – F <= /span>( j ) следует включать, кроме размера и доли повтор = 85;о используемm= 9;х компонентоk= 4;, совокупносm= 0;ь факторов, которые способны изменять трудоемкосm= 0;ь в несколько (до 3 – 5) раз:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>нов= изну проекта комплекса программ;<o:p></o:p>= <![if !supportLis= ts]>-&nb= sp; = <![endif]>нео= бходимую степень согласованl= 5;ости проекта с требованияl= 4;и техн= ического задания;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>нал= ичие управления рисками и архитектурl= 6;й проекта;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>уро= вень обобщенной слаженностl= 0; и организов = 72;нности коллективнl= 6;й разработки проекта;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>уро= вень обеспечениn= 3; и оснащения технологии разработки по оценке СММ.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n>Вторую группу – M ( i ) следует выбирать из совокупносm= 0;и перечисленl= 5;ых в таблице 5.8 семнадцати факторов, таких которые в ко= 085;кретном проекте могут повлиять на изменение трудоемкосm= 0;и разработки на 10 – 20%, соизмеримоk= 7; с точностью оценок разм = 77;ра ПС:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тре= бования надежности ПС;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тре= бования степени соответствl= 0;я документацl= 0;и программноl= 4;у продукту;<o:p></o:p>= <![if !supportLis= ts]>-&nb= sp; = <![endif]>тем= атическая квалификацl= 0;я специалистl= 6;в;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тех= нологическk= 2;я квалификацl= 0;я проектировm= 7;иков и программи = 89;тов;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>ста= бильность состава коллектива разработчиl= 2;ов;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>огр= аничения ресурсов объектной ЭВМ реально = 75;о времени;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>ста= бильность требований заказчика к задачам и функциям ПС.<o:= p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Остальная совокупносm= 0;ь около десят = 80; факторов модели СОСОМО II обычно может изменять трудоемкосm= 0;ь проекта менее чем на 10% и их не целесообраk= 9;но учитывать в процессе детальног = 86; проектировk= 2;ния, когда точность оценивания размера проекта ПС м= 086;жет составлять около 10%. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Обобщенны = 77; оценки технико-эко = 85;омических показателеl= 1; проекта ПС целесообраk= 9;но представляm= 0;ь в виде табли= 094; с указанием достоверноl= 9;ти оценок результатоk= 4; расчетов. На основе анализа результатоk= 4; и оценивани= 03; рассчитаннm= 9;х характерисm= 0;ик следует вып = 86;лнять заключителn= 0;ное техникl= 6;-экономичес&#= 1082;ое обоснованиk= 7; проекта ПС и опред&= #1077;лять:<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>целесооб&= #1088;азно ли продолжать работы над к= 086;нкретным проектом ПС = 074; направлениl= 0; детализациl= 0; требований, функций и те= 093;нико-эконом= ических характерисm= 0;ик или следует его прекратить, вследствие = 85;едостаточн&#= 1099;х ресурсов специалистl= 6;в, времени или возможной стоимости и трудоемкосm= 0;и разработки;</sp= an><o:p></o:p> <![if !supportLis= ts]>- = <![endif]>при наличии достаточныm= 3; ресурсов, следует ли провести ма = 88;кетинговые исследованl= 0;я для определениn= 3; рентабельнl= 6;сти полного вып = 86;лнения проекта ПС и создания программноk= 5;о продукта дл= 03; поставки на = 088;ынок;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>дос= таточно ли полно и корректно формализовk= 2;ны концепция и требования = 82; проекту ПС, на осl= 5;ове которых проводилисn= 0; расчеты ТЭП, или их следу= 077;т откорректиl= 8;овать и выполнить повторный анализ с уто= 095;ненными исходными д = 72;нными;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ест= ь ли возможностn= 0; применить готовые пов = 90;орно используемm= 9;е компоненты ПС, в каком относительl= 5;ом размере от всего комплекса программ, и рентабельнl= 6; ли их применять в конкретном проекте ПС или весь проект целесообраk= 9;но разрабатывk= 2;ть как полностью н = 86;вый. <o:p></o:p> <o:p> </o= :p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p>= <o:p> </o:p> <o:p> </o:p= > <o:p> </o:p> <h1><a name=3D"_Toc508102467"></a><a name=3D"_Toc508102240">Лекция 6. Разработка требований = 82; программныl= 4; средствам</a><= /h1> <o:p> </o:p> <h1><a name=3D"_Toc508102468"></a><a name=3D"_Toc508102241">6.1. Организациn= 3; разработки требований = 82; сложным про = 75;раммным средствам</a><= /h1> <o:p> </o:p> Проекты программныm= 3; средств раз = 83;ичаются по уровню сл= 086;жности, масштабу и н= 077;обходимому качеству. Он= 080; имеют различное н = 72;значение, содержание = 80; относятся к разным областям применения. Поэтому сущ = 77;ствует потребностn= 0; в четко организоваl= 5;ном процессе, методах формализацl= 0;и и управлени= 03; требованияl= 4;и к конкретны = 84; программныl= 4; продуктам. Чаще всего проблемамl= 0;, с которыми встретилисn= 0; не достигши = 77; своих целей = 087;роекты программныm= 3; продуктов, я= 074;ляются: недостатоl= 2; информации от пользова = 90;еля или заказчи = 82;а о функциях проекта, неполные, некорректнm= 9;е требования, = 072; также многочислеl= 5;ные изменения требований = 80; спецификацl= 0;й. Это происходит потому, что з&#= 1072;частую разработчиl= 2;и и заказчики считают, что “даже если м= 099; не очень точно знаем, чего хотим д= 086;стичь, лучше быстрее приступить = 82; реализации проекта, так как мы и так выбились из графика и на= 084; некогда размышлять. = 052;ы можем уточнить требования позднее”. Подобный подход приводит к хаотическиl= 4;, неупорядочk= 7;нным действиям при разработке ПС, когда никто не знает, что на самом деле хочет заказчик и пользоватеl= 3;ь, и как в дейст&#= 1074;ительности функционирm= 1;ет созданная на данный момент сист = 77;ма и/или программнm= 9;й продукт.<o:p></o:p> Формали= ;зация и управлени = 77; требованияl= 4;и = - это систематичk= 7;ский метод выявления, организациl= 0; и документи = 88;ования требований = 82; системе и/ил= 080; ПС, а также процесс, в ходе которого вы = 88;абатываетс&#= 1103; и обеспечиваk= 7;тся соглашение между заказчиком = 80; выполняющиl= 4;и проект спец = 80;алистами, в условиях меняющихся требований = 82; системе -</span= > рис. 6.1. Развитие программноl= 1; инженерии, е= 105; обозримое будущее, связаны с непрерывныl= 4; возрастаниk= 7;м сложности, поэтому раз = 88;аботкой ПС должны заниматься хорошо орга = 85;изованные и обученные коллективы </sp= an>-</span= > командm= 9; разработчиl= 2;ов. Каждый член команды в то= 081; или иной сте= 087;ени должен привлекатьl= 9;я к управлени= 02; и формализа = 94;ии требований = 82; проекту. Ком= 072;нде необходимо выработать профессионk= 2;льные приемы для понимания п = 86;требностей пользоватеl= 3;ей, управления масштабом П = 57;, структурой = 80; построениеl= 4; системы, удовлетворn= 3;ющей эти потребн = 86;сти. <o:p></o:p> К= 086;манда должна применить методы и процессы дл= 03; того, чтобы п&#= 1086;нять решаемую проблему заказчика д = 86; начала разработки ПС. Дл= 03; этого следует ис = 87;ользовать метод анализа, выявления и освоения проблемы и интересов заказчика:<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>д = 86;стигнуть соглашения между заказчиком = 80; разработчиl= 2;ом по определениn= 2; проблемы, целей и зада= 095; проекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 99;делить основные причины = - проблемы, являющиеся её источник = 72;ми и стоn= 3;щие за основной проблемой проекта системы и ПС;<o= :p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 99;явить заинтересоk= 4;анных лиц и пользоватеl= 3;ей, чье коллект = 80;вное мнение и оценка в конечном итоге опред = 77;ляет успех или неудачу про = 77;кта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;ределить, где приблизитеl= 3;ьно находятся область и гр= 072;ницы возможных р = 77;шений проблем;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>п = 86;нять ограничениn= 3;, которые будут налож = 77;ны на проект, коман= ду и решения проблем.<o:p></o:p> &#= 1042; результате необходимо предложить заказчику возможные решения рассматривk= 2;емой проблемы. Дл= 103; анализа проблемы можно испол= 00;зовать разнообразl= 5;ые методы. В частности, моделироваl= 5;ие бизнес-проц = 77;ссов, специальныl= 1; метод анализа про = 73;лем, который достаточно = 93;орошо зарекомендl= 6;вал себя для сложных инф = 86;рмационных систем, осущ= 077;ствляющих поддержку ключевых инфраструкm= 0;ур. Выявленные на данном этапе преце = 76;енты, могут позднее применятьсn= 3; для определениn= 3; совокупносm= 0;и требований = 82; ПС. Методы сис = 90;емного анализа, позволяют о = 89;уществить разбиение сложной системы на п= 086;дсистемы. Этот процес = 89; помогает понять, каки= 084; общим целям должн= ;о служить ПС. При этом часто оказы = 74;ается, что в чем-то усложняютсn= 3; требования, создавая новые подсистемы, для которых = 074; свою очеред= 00; нужно заниматься разработкоl= 1; и понимание = 84; требований.<o:p= ></o:p> Понимание потребностk= 7;й пользоватеl= 3;ей необходимm= 9;й организациl= 6;нный этап, так как разработчиl= 2;и редко получают совершенныk= 7; спецификацl= 0;и требований = 82; создаваемоl= 1; системе, они должны сами добывать информацию, необходимуn= 2; им для успеш= 085;ой работы. Термин выявление требований точно отраж = 72;ет данный процесс, в котором разработчиl= 2;и должны играть активную роль. Чтобы помочь команде решить эти п= 088;облемы, лучше понят= 00; потребностl= 0; пользоватеl= 3;ей и других заинтересоk= 4;анных лиц, целесообраk= 9;но использоваm= 0;ь методы:<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>интервьюи = 88;ования и анкетироваl= 5;ия - создание структуриl= 8;ованного интервью; проведение интервью с 5 <= span style=3D'mso-bidi-font-size:14.0pt;font-family:Symbol;mso-ascii-font-family= :"Times New Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - 15 пользоватеl= 3;ями и/или заинте= 088;есованными лицами; подведение итогов совокупносm= 0;и интервью, формулировk= 2;ние 10 - 15 наиболее часто уп = 86;минавшихся</= span> потребностk= 7;й заказчика и пользоватеl= 3;ей; <o:p></o:p><= /p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>с = 86;вещания, посвященныk= 7; анализу и синтезу тре = 73;ований -</span= > формулироk= 4;ание и определениk= 7; целей программноk= 5;о продукта; ознакомленl= 0;е с ними всех участников проекта и установленl= 0;е, что они с ними соглас = 85;ы; если это не так, следует остановитьl= 9;я и уточнения = 84;и добиться со = 75;ласия; обязательl= 5;о убедиться в согласии заказчикоk= 4;;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>м = 86;зговой штурм и отбо= 088; идей, чтобы: выяв= 080;ть и/или уточни= 090;ь функции про = 77;кта; отсечь нецелесообl= 8;азные идеи; провести классификаm= 4;ию функций, чтобы определить приоритеты, = 088;иски, трудоемкосm= 0;и реализации фун-кц = 80;й;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>а = 85;ализ иллюстратиk= 4;ных прецедентоk= 4; в приложени = 80; к концепции требований (или системному проекту), что&#= 1073;ы их функции были наглядны и п= 086;нятны;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>п = 86; возможностl= 0; выявление или создани = 77; временных прототипов на основе первичных требований.<o:p= ></o:p> Хо= тя ни один из методов не является универсальl= 5;ым, каждый из ни= 093; позволяет лучше понят= 00; потребностl= 0; пользоватеl= 3;ей и тем самым превратить “неясные” требования, = 074; требования, которые “лучше известны и п= 086;нятны”. Каждый из этих методо = 74; эффективен = 74; определеннm= 9;х ситуациях, однако целесообраk= 9;но отдавать предпочтенl= 0;е совещанию, п= 086;священному требованияl= 4;, и мозговому штурму. <o:p></o:p> Для сложных систем требуются стратегии управления информациеl= 1; о требованияm= 3;. Для этого применяетсn= 3; информациоl= 5;ная иерархия; он= 072; начинается = 89; потребностk= 7;й пользоватеl= 3;ей, описанных с помощью фун = 82;ций, которые затем превращаютl= 9;я в более подр= 086;бные требования = 82; ПС, выраженные посредствоl= 4; прецедентоk= 4; или традиционнm= 9;х форм описан = 80;я и стандартизl= 0;рованных характерисm= 0;ик. Эта иерархи= 03; отражает уровень абс = 90;ракции при рассмотренl= 0;и взаимосвязl= 0; области проблемы и области реш = 77;ния. Концепцию требований, модифицироk= 4;анную в соответствl= 0;и с конкретны = 84; содержаниеl= 4; комплекса программ, необходимl= 6; иметь в каждом проекте. В требованияm= 3; к ПС следует указывать, какие функц = 80;и должны осуществляm= 0;ься, а не то, как они могут реализоватn= 0;ся. Они используютl= 9;я для задания функционалn= 0;ных и конструкт = 80;вных требований, = 072; также огран = 80;чений ресурсов проектировk= 2;ния. Нужно использоваm= 0;ь набор харак = 90;еристик для установленl= 0;я и оценки кач= 077;ства ПС и содержащихl= 9;я в нем компон= 077;нтов. Если необходимо, документацl= 0;я требований может дополнятьсn= 3; одним или несколькимl= 0; более формальнымl= 0;, либо более структурирl= 6;ванными методами спецификацl= 0;и требуемого качества. <o:p></o:p></span= > Без лидера -</span= > руководитеl= 3;я проекта, который будет утвер = 78;дать требования = 82; ПС, согласов= 099;вать и поддерживk= 2;ть потребностl= 0; заказчика и команды раз = 88;аботчиков, нельзя быть уверенным в том, что буду&#= 1090; приняты необходимыk= 7; четкие, скоординирl= 6;ванные решения. Возможно возникновеl= 5;ие флюктуаций требований, задержек, а также принятие не = 86;птимальных решений, вызванное приближениk= 7;м срока окончания проекта. Рук= 086;водитель должен создать совет по = 82;онтролю за изменениямl= 0;, который при = 79;ван помогать лидеру в принятии действителn= 0;но сложных решений и га= 088;антировать, что изменения и утверждениn= 3; требований будут приниматьсn= 3; только посл = 77; их обсужден = 80;я. <o:p></o:p> Концепция требований = 82; проекту (или системный проект) должна быть “живым” документоl= 4;, чтобы было легче его использоваm= 0;ь и пересматр = 80;вать. Следует сделать кон = 94;епцию официальныl= 4; каналом изменения функций так, чтобы проек = 90; всегда имел = 076;остоверный, соответствm= 1;ющий современноl= 4;у состоянию документ. Ли= 076;ер должен нест = 80; персональнm= 1;ю ответственl= 5;ость за концепци= 02;, регулярно (вместе с командой) оценивать состояние дел и готовить отчеты и зап= 088;осы, способствуn= 2;щие этим действиям. Процесс отслеживанl= 0;я спецификацl= 0;й требований = 82; ПС, должен помогать убедиться, что концепц = 80;я надлежащим образом реализуетсn= 3; в детализир = 86;ванных требованияm= 3; к компонентаl= 4; ПС. Руководс= 090;во процессом контроля за изменен = 80;ями, должно= гарантироk= 4;ать, что перед тем, как разрешить внесение существеннm= 9;х изменений в систему, производитl= 9;я оценка рентабельнl= 6;сти поступившиm= 3; предложениl= 1; (см. лекцию 16).<o:p></o:p>= <s= pan style=3D'mso-spacerun:yes'> Проек= ты, как правило, инициируютl= 9;я с объемом функционалn= 0;ных возможностk= 7;й, значительнl= 6; превышающиl= 4; тот, который разработчиl= 2; может реализоватn= 0;, обеспечив п = 88;иемлемое качество пр = 80; заданных ресурсах. Те= 084; не менее, необходимl= 6; ограничиваm= 0;ься, чтобы иметь возможностn= 0; предоставиm= 0;ь в срок доста= 090;очно целостный и качественнm= 9;й продукт. Сущ= 077;ствуют различные методы задания очередностl= 0; выполнения (приоритето = 74;) требований = 80; понятие базового ур = 86;вня - со = 74;местно согласованl= 5;ого представлеl= 5;ия о том, в чем будут состоять кл= 02;чевые функции системы как продукта проекта = - понятиk= 7; состава требований, задающих ориентир дл= 03; принятия решений и их оценки. <o:p></o:p> Если масштаб проекта и сопутствуюm= 7;ие требования заказчика п = 88;евышают реальные ресурсы, в любом случа = 77; придется ограничиваm= 0;ься в функциях и качестве ПС. Поэтому следует определять, что обязательнl= 6; должно быть сделано в версии прог = 88;аммного продукта пр = 80; имеющихся р = 77;сурсах проекта. Для этого придется в = 77;сти переговоры. Нельзя ожидать, что данный процесс полностью решит пробл = 77;мы масштаба и т= 088;ебований к ПС. Но такие шаги окажут заметное во = 79;действие на размеры проблемы, позволят ра = 79;работчикам ПС сконцент = 88;ировать свои усилия на критически важных подмножестk= 4;ах требований = 80; функций и, в несколько приемов, предоставl= 0;ть высококачеl= 9;твенные системы, удовлетворn= 3;ющие или даже превосходяm= 7;ие основные ожидания пользоватеl= 3;ей. Привлечениk= 7; заказчика к решению проблемы управления масштабом и функциями повышает вз = 72;имные обязательсm= 0;ва сторон, способствуk= 7;т росту взаим = 86;понимания и доверия между заказчиком = 80; разработчиl= 2;ами. Имея достаточноk= 7; определениk= 7; функций продукта (концепцию) и сократив масштаб проекта до р= 072;зумного уровня, можно надеяться н = 72; успех в следующих фазах или версиях про = 77;кта.<o:p></o:p> На основе выполненныm= 3; оценок трудозатраm= 0; рекомендуеm= 0;ся определять базовый уровень для каждой версии концепции требований, используя атрибут “номер верс = 80;и”, достигнуть соглашения = 89; заказчиком относительl= 5;о масштаба, а также принять жесткие реш = 77;ния по масштабу версии. Итеративнk= 2;я разработка = 80; управление изменениямl= 0;, используя б = 72;зовый уровень, позволяет контролироk= 4;ать, что все предложеннm= 9;е функции записаны и н= 080;чего не потеряно. Целесообраk= 9;на система упр = 72;вления запросами н = 72; изменения требований, чтобы фиксироватn= 0; все изменения и гарантировk= 2;ть, что они поступают через эту си= 089;тему в совет по контролю за изменен = 80;ями. На всех этапах развития спецификацl= 0;и требований = 82; ПС, следует задавать полный набо = 88; характерисm= 0;ик функционалn= 0;ного и конструкт = 80;вного поведения программноk= 5;о продукта и п= 086;дробные прецеденты для основны = 93; функций системы. <o:p></o:p> В требованияm= 3; должны быть полно и с = 78;ато зафиксировk= 2;ны потребностl= 0; пользоватеl= 3;ей в таком виде, чтобы разработчиl= 2; мог построи = 90;ь удовлетворn= 3;ющее их ПС и его ко&= #1084;поненты. Кроме того, требования должны быть достаточно конкретнымl= 0;, чтобы можно было опреде = 83;ить, когда они удовлетворk= 7;ны. Зачастую именно разработчиl= 2;и обеспечиваn= 2;т эту конкретизаm= 4;ию. Существуют различные в = 86;зможности организациl= 0; и документи = 88;ования этих требований. Вся разрабо = 90;ка должна вытекать из требований, а все спецификацl= 0;и ПС и компоне= 085;тов должны найт = 80; отражение в процессах и продуктах разработки. = 057;ложный программныl= 1; комплекс следует пересматриk= 4;ать и обновлять на протяжении всего жизне = 85;ного цикла проек = 90;а. <o:p></o:p> Проектироk= 4;ание и реализаци= 03; корректной (правильной) системы, адекватной требованияl= 4; = - весьма трудоемкая задача. Один из полезных методов сос = 90;оит в использоваl= 5;ии прототипов требований = 80; прецедентоk= 4; в качестве основы архитектурm= 9; и реализаци = 80; проекта. Постоянно отслеживатn= 0; эволюцию функций и требований, = 072; также их реализацию позволяет верификациn= 3; (см. лекцию 13). Её поддержка о = 89;уществляет&#= 1089;я путем испол= 00;зования методов трассировкl= 0;, что позволя = 77;т связывать друг с друго= 084; части проек = 90;а, проводить трассировкm= 1; требований = 82; прецедентаl= 4; и функциям и обратно. С помощью трассировкl= 0; можно удост = 86;вериться в том, что:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>в = 89;е элементы требований проекта учтены;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 89;е реализованl= 5;ые элементы проекта слу = 78;ат заданной цели и требо= 074;аниям.<o:p></o:p> Хотя верификациn= 3; является аналитичесl= 2;им методом, рекомендуеm= 0;ся помнить о важности размышлениl= 1; и интуиции. Нельзя ограничиваm= 0;ься механическl= 0;м применениеl= 4; верификациl= 0;. Основное внимание пр = 80; её проведен = 80;и уделяется тестированl= 0;ю и использов = 72;нию трассировкl= 0; для отбора компонентоk= 4; системы, нуж= 076;ающихся в тестированl= 0;и. Методы проверки корректносm= 0;и требований = 87;ризваны гарантировk= 2;ть, что:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 89;е элементы требований могут надлежащим образом и достаточно полно тести = 88;оваться;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>в = 89;е тесты служа = 90; цели проект = 72; и не являютс= 103; избыточнымl= 0;.<o:p></o:p> <s= pan style=3D'mso-spacerun:yes'> Чтобы принять решение о том, какая часть системы нуж = 76;ается в верификациl= 0; и проверке корректносm= 0;и и в каком объ&#= 1077;ме, целесообраk= 9;но применять анализ и оце= 085;ку рисков. Это позволяет определить, для каких элементов неправильнk= 2;я реализация требований недопустимk= 2;, а также разр= 072;ботать план действий по верификациl= 0; и проверке правильносm= 0;и, основываясn= 0; на результатаm= 3; этих оценок. На этом этап= 077; следует привлекать = 82; управлениn= 2; требованияl= 4;и и анализу их корректносm= 0;и, специалистl= 6;в по тестиров = 72;нию, подключая и = 93; к планированl= 0;ю тестов с самого начала прое = 82;та (см. лекцию 13) . Группа тестированl= 0;я должна разр = 72;ботать тестовые процедуры и сценарии, которые трассируютl= 9;я к прецедент = 72;м, а также функционалn= 0;ным и конструкт = 80;вным требованияl= 4;. <o:p></o:p> <s= pan style=3D'mso-spacerun:yes'> Построениk= 7; корректных требований = 82; системе во многом зави = 89;ит от надлежащей обработки изменений. И= 079;менения - неотъемлемk= 2;я часть жизни ПС, это нужно учитывать при создани = 80; планов, а также необх = 86;димо разработатn= 0; процесс, с помощью которого можно управлять изменениямl= 0; требований. Управление изменениямl= 0; дает уверен = 85;ость в том, что создаваемаn= 3; система является корректной = 80;, более того, будет правильной = 80; в дальнейше = 84;. Специалистk= 2;м по независи = 84;ой гарантии качества, должна отво = 76;иться роль в отслеживанl= 0;и и оценке про= 094;есса управления требованияl= 4;и и плана их тестироваl= 5;ия, а также пери= 086;дических испытаний п = 86; окончании значительнm= 9;х этапов, чтоб= 099; проверить правильносm= 0;ь результатоk= 4; работы и обеспечить постоянное участие зак = 72;зчиков.<o:p></o:p> = <o:p></o:p> <h1> <a name=3D"_Toc508102469"></a><a name=3D"_Toc508102242">6.2.&= nbsp; Процессы разработки требований = 82; характерисm= 0;икам сложн= ;ых программныm= 3; средств</a></h1> = <o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> При планированl= 0;и, разработке = 80; реализации требований = 82; характерисm= 0;икам качества ПС необходимо, = 074; первую очередь, учи= 090;ывать следующие основные фа = 82;торы:<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1092;ункциональ= ную пригодностn= 0; (функционал= 00;ность) конкретногl= 6; проекта ПС;<o:p></o:p= > <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1074;озможные конструктиk= 4;ные характерисm= 0;ики качества комплекса программ, не= 086;бходимые для улучшения функционалn= 0;ной пригодностl= 0;;<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1076;оступные ресурсы для создания и обеспечениn= 3; всего жизне = 85;ного цикла ПС с требуемым качеством.<o:p></o:p>= Эти фактор = 99; целесообраk= 9;но применять последоватk= 7;льно, итерационнl= 6; на каждом из основных этапов ЖЦ ПС. При первона = 95;альном определениl= 0; требований = 82; функционалn= 0;ной пригодностl= 0; и к конструктиk= 4;ным характерисm= 0;икам качества, заданные заказчиком ограничениn= 3; ресурсов не всегда могу = 90; учитывать ряд особенностk= 7;й проекта, что обусловит недопустимl= 6;е снижение (ил= 080; завышение) требований = 82; некоторым характерисm= 0;икам качества ПС. Кроме того, возможно, чт= 086; некоторые характерисm= 0;ики проти= ;воречивы или принципиалn= 0;но нереализуеl= 4;ы в данном проекте. В ре&#= 1079;ультате не сбалансироk= 4;анные требования = 82; качеству и доступные р = 77;сурсы проявятся как риски – ущерб в виде потерь в кач= 077;стве или в пер= 077;расходован&= #1080;и ресурсов. Дл= 103; устранения или снижени= 03; рисков до допустимых пределов потребуетсn= 3; изменение требований = 82; функционалn= 0;ной пригодностl= 0; и/или к конструктиk= 4;ным характерисm= 0;икам. Таким образом, целесообраk= 9;но анализ и разработку требований = 82; качеству ПС = 087;роводить в два этапа: предваритеl= 3;ьно максимиk= 9;ируя функционалn= 0;ную пригодностn= 0; и конструкт = 80;вные характерисm= 0;ики качества, а затем ми = 85;имизируя риски снижения требуемого качества ил = 80; используемm= 9;х ресурсов. <o:p></o:p></span= > <= span style=3D'mso-spacerun:yes'> </span= >Разработку и утверждениk= 7; требований = 82; характерисm= 0;икам и атрибутам качества бе = 79; учета риско = 74;, целесообраk= 9;но проводить и = 90;ерационно на этапах си= 089;темного и детальног = 86; проектировk= 2;ния ПС. Полная и од= 085;ократная формализацl= 0;я требований = 82; характерисm= 0;икам качества в начале жизненного цикла сложного ПС обычно невозможна, прежде всег = 86;, из-за разных представлеl= 5;ий заказчика и разработчиl= 2;ов о детk= 2;лях его назначе = 85;ия, функций и возможностk= 7;й реализации при доступных ресурсах. Че= 084; крупнее и сложней проект ПС и соответствk= 7;нно выше его стоимость, тем тщательнее следует разрабатывk= 2;ть требования = 82; его характе = 88;истикам качества и распределяm= 0;ь ресурсы на и= 093; реализацию (см. лекцию 12). Поэто= ;му при средней = 080; относительl= 5;о невысокой с = 83;ожности ПС, во многих случаях, мож= 085;о удовлетворl= 0;ться подготовкоl= 1; требований = 82; качеству с п= 086;дробностью анализа, соответствm= 1;ющей системному проектировk= 2;нию. Для крупном = 72;сштабных и особо сложных про = 77;ктов необходим более детал= 00;ный анализ факторов пр = 80; разработке требований = 80; их оптимиза = 94;ия по критерию = 082;ачество/зат= раты. Поэтому на этапах прое = 82;тирования последоватk= 7;льно должны определятьl= 9;я требо= вания: <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>при проектировk= 2;нии концепции = - предваритеl= 3;ьные требования = 82; назначению, функционалn= 0;ной пригодностl= 0; и к номенклатуl= 8;е необходимыm= 3; конструктиk= 4;ных характерисm= 0;ик качества ПС; </= span><o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;и предваритеl= 3;ьном проектировk= 2;нии - требования = 82; шкалам и мерам приме = 85;яемых атрибутов характерисm= 0;ик качества с учетом общи = 93; ограничениl= 1; ресурсов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>п = 88;и детальном проектировk= 2;нии - подробные требования = 82; атрибутам качества с детальным учетом и распределеl= 5;ием реальных ограниченнm= 9;х ресур= ;сов, а также, возможно, их<sp= an style=3D'mso-spacerun:yes'> оптимизацl= 0;я по критерию качество/за = 90;раты. <o:p></o:p> В зависимостl= 0; от сложност = 80; проекта окончательl= 5;ым результатоl= 4; работ при предваритеl= 3;ьном или детальн = 86;м проектировk= 2;нии должны быть детализироk= 4;анные и утвержденнm= 9;е требования = 82; функциям, св= 086;йствам и значениям атрибутов качества ПС, которые в обоих случаях дос = 90;аточны для его полноценноk= 5;о рабочего проектировk= 2;ния и последующ = 77;й, эффективноl= 1; эксплуатацl= 0;и (без учета рисков). В реальных пр = 86;ектах при подгото = 74;ке требований = 82; качеству ПС могут исклю = 95;аться этапы проек = 90;ирования, однако соде = 88;жание и последоватk= 7;льность работ по ана= 083;изу и детализац = 80;и требований = 82; характерисm= 0;икам и атрибутам качества целесообраk= 9;но сохранять. Эти требова = 85;ия закрепляютl= 9;я в контракте = 080; техническоl= 4; задании, по которым раз = 88;аботчик впоследствl= 0;и должен отчи = 90;ываться перед заказчиком при завершении проекта или его версии. Однако на последующиm= 3; этапах жизненного цикла и при конфигурацl= 0;онном управлении, требования могут измен= 03;ться по согласов = 72;нию между заказчиком = 80; разработчиl= 2;ом, которые чащ = 77; всего приур = 86;чиваются к подготовк = 77; новой версии= программнl= 6;го продукта. Дл= 103; этого необходим м = 86;ниторинг требований = 80; реализаций характерисm= 0;ик качества в течение всего ЖЦ ПС.<o:p></o:= p> Выбор требований = 82; харак= теристикам и атрибутам качества пр = 80; проектировk= 2;нии программныm= 3; средств начинается = 89; определениn= 3; исходных да = 85;ных. Для корректногl= 6; выбора и установленl= 0;я требований = 82; характерисm= 0;икам качества, прежде всег = 86;, необходимо = 86;пределить особенносm= 0;и проекта:<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1082;ласс, назначение = 80; основные функции l= 9;оздаваемог= 086; ПС;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1082;омплект стандартов = 80; их содержание, которые целесообраk= 9;но использоваm= 0;ь при выборе характерисm= 0;ик качества ПС;<o:= p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1089;остав потребителk= 7;й характерисm= 0;ик качества ПС, для которых важны соотв = 77;тствующие атрибуты качества;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1088;еальные ограничениn= 3; всех видов ресурсов проекта. <o:p></o:p> = Этап разработки концепции проекта целесообраk= 9;но начинать с формализацl= 0;и и обоснованиn= 3; набора исхо = 76;ных данных, отражающих общие особе = 85;ности класса, потр= 077;бителей и этапов жизненного цикла проек = 90;а ПС, каждый из которых влияет на выбор опред = 77;ленных характерисm= 0;ик качества комплекса п = 88;ограмм. Из конструктиk= 4;ных характерисm= 0;ик и атрибутов качества, прежде всег = 86;, следует выд = 77;лять, те на которые в наибольшей степени воздействуk= 7;т класс, назна= 095;ение и функции ПС. Для этого первоначалn= 0;но целесообраk= 9;но использоваm= 0;ь классификаm= 4;ию программныm= 3; средств по стандарту ISO<= span style=3D'font-size:14.0pt'> 12182 и всю базовую ном = 77;нклатуру характерисm= 0;ик и субхар = 72;ктеристик качества, стандартизl= 0;рованных в ISO 9126 (см. лекцию 11). Их описания желат= ;ельно предваритеl= 3;ьно упорядочитn= 0; по приорите = 90;ам с учетом особенностk= 7;й назначения = 80; сферы применения конкретногl= 6; ПС. Обычно наиболее сильное влияние функции ПС о= 082;азывают на требования = 82; атрибутам характерисm= 0;ик: Защищенносm= 0;ь, Надежность = 80; Эффективноl= 9;ть. В то же время, характерисm= 0;ики Сопровоk= 8;даемость и Мобильнос = 90;ь относительl= 5;о слабо связаны с на= 079;начением и конкретно = 81; функционалn= 0;ной пригодностn= 0;ю ПС для оперативныm= 3; пользоватеl= 3;ей. Их меры и шкалы определяютl= 9;я не столько конкретнымl= 0; функциями комплекса п = 88;ограмм, сколько его архитектурl= 6;й и приспособлk= 7;нностью интерфейсоk= 4; к модификациl= 0; и переносу н= 072; иные операц = 80;онные и аппаратны = 77; платформы. <o:p></o:p= > Требованиn= 3; стандартов = 82; функционалn= 0;ной пригодностl= 0; должны выполнятьсn= 3; для любых классов и назначения ПС. Однако номенклатуl= 8;а учитываемыm= 3; требований = 82; конструктиk= 4;ным характерисm= 0;икам качества существеннl= 6; зависят от назначения = 80; функций ком = 87;лексов программ. Так, наприме= 088;, при проектировk= 2;нии:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 80;стем управлениn= 3; объектами в реальном времени наибольшее значение имеет защищ = 77;нность, корректносm= 0;ь и надежност= 00; функционирl= 6;вания стабильногl= 6; комплекса программ и менее важно может быть качест = 74;о обеспечениn= 3; сопровождеl= 5;ия и конфигура = 94;ионного управления, спосо= ;бность к взаимодей = 89;твию и практично = 89;ть;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>администр= 072;тивных систем кром = 77; корректносm= 0;и, важно обесп = 77;чивать практичносm= 0;ь применения, комфортное взаимодейсm= 0;вие с пользоват = 77;лями и внешней средой и мож= 077;т не иметь особого значение эффективноl= 9;ть использоваl= 5;ия вычислителn= 0;ных ресурсов и обеспечениk= 7; мобильностl= 0; комплекса программ;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 87;ерационных систем наиболее жесткие требования предъявляюm= 0;ся к корректно = 89;ти, эффективноl= 9;ти использоваl= 5;ия вычислителn= 0;ных ресурсов и защищенносm= 0;и, и не всегда могут учитыватьсn= 3; мобильностn= 0; и унификаци= 03; способностl= 0; к взаимодейсm= 0;вию её компонен = 90;ов;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 72;кетов прикладных программ дл= 03; вычислений или моделир = 86;вания процессов, во= зможно не учитыват= 00; их мобильностn= 0;, защищенносm= 0;ь и временную эффективноl= 9;ть, но особенно важна корре = 82;тность.<o:p></o:p> = Далее необходимо выделить и ранжироватn= 0; по приоритетаl= 4; потребителk= 7;й, которым необходимы = 86;пределенны&#= 1077; показатели качества ПС = 089; учетом их специализаm= 4;ии и профессионk= 2;льных интересов. Ши= рокая номенклатуl= 8;а характерисm= 0;ик, представлеl= 5;ная в стандарте <sp= an lang=3DEN-US style=3D'mso-ansi-language:EN-US'>ISO 9126 определяет</spa= n> разнообразl= 5;ые требования, из которых следует = 89;електирова&#= 1090;ь и выбирать те, которые необходимы = 89; позиции потребителk= 7;й этих данных: <o= :p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>з = 72;казчиков, для которых важно регламентиl= 8;овать и оценивать = 055;C по значениям требований = 82; характерисm= 0;икам, заданным и утвержденнm= 9;м в контракте, техническоl= 4; задании и спецификацl= 0;ях требований = 80; определяющl= 0;х, прежде всег = 86;, назначение, функции и сферу приме = 85;ения программноk= 5;о продукта;<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>п = 86;льзователе&#= 1081;, для которых необходима функционалn= 0;ная пригодностn= 0;, корректносm= 0;ь, надежность и другие пока = 79;атели качества пр = 80; оперативноl= 4; использоваl= 5;ии комплекса программ по основному назначению;<o:p= ></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>р = 72;зработчико&#= 1074;, для которых особенно важны: ясность и ко= 085;кретность описаний требований = 82; функциям и характерисm= 0;икам ПС, его возможная архитектурk= 2; и интерфейс = 99; между компонентаl= 4;и и с внешней средой;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>с = 87;ециалистов сопровождаn= 2;щих и модифицир = 91;ющих ПС, которые отдают прио = 88;итет характерисm= 0;икам, поддерживаn= 2;щим сопровождеl= 5;ие и конфигура = 94;ионное управление версиями комплекса программ и его компоне = 85;тов;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>л = 80;цам, ответственl= 5;ым за инсталляциn= 2; и реализаци= 02; программноk= 5;о продукта в различных аппаратных = 80; операционнm= 9;х средах, для которых наиболее важны характерисm= 0;ики мобил= ;ьности.<o:p></o:p> = В таблице 6.1 представлеl= 5; пример ранжированl= 0;я по степени важности на = 090;ри уровня= (высокая, средняя, низкая) осно= 074;ных стандартизl= 0;рованных характерисm= 0;ик качества ПС для разных к= 072;тегорий специалистl= 6;в. Первые две группы потребителk= 7;й характерисm= 0;ик качества, заинтересоk= 4;аны, преимущестk= 4;енно, в реализаци = 80; функций, проявляющиm= 3;ся в процессе использоваl= 5;ия конечного, готового пр = 86;граммного продукта. Дл= 103; этих потреб = 80;телей при выборе важно выдел= 03;ть и по возможностl= 0; формализовk= 2;ть внешние, эксплуатаm= 4;ионные характерисm= 0;ики на завершающиm= 3; этапах ЖЦ версий ПС. К ним относятся, прежде всег = 86;, высокие приоритеты для надежности, эффективноl= 9;ти и практично = 89;ти. Для заказчи = 82;ов приоритетнm= 9;ми могут быть также со = 87;ровождаемо&#= 1089;ть и мобильнос = 90;ь, которые для оперативныm= 3; пользоватеl= 3;ей ПС обычно являются второстепеl= 5;ными.<o:p></o:p> Последние три группы потребителk= 7;й интересуют преимущестk= 4;енно характерисm= 0;ики ПС на промежуточl= 5;ых этапах ЖЦ, на которых про= 03;вляются, в основном, в&#= 1085;утренние структурныk= 7;, технологичk= 7;ские свойства комплекса программ, влияющие также на = 089;опровождае&= #1084;ость и мобильнос = 90;ь. Их можно не представляm= 0;ь в составе эксплуатацl= 0;онной документацl= 0;и для оперативныm= 3; пользоватеl= 3;ей и отражать только в технологичk= 7;ской документацl= 0;и разработчиl= 2;ов, специалистl= 6;в по сопровождеl= 5;ию и переносу программ и данных, а также поставлять заказчикам = 87;о специальноl= 4;у запросу. Они должны формализовk= 2;ться для обеспеч = 77;ния возможностl= 0; контроля системой качества предприятиn= 3; или проекта, а также для т&#= 1077;хнологичес= кой поддержки реализации этих характ = 77;ристик качества в течение всего ЖЦ ПС. Для этих потребителk= 7;й надежность = 80; практичносm= 0;ь отходят на второй план, однако, ресурсная эффективноl= 9;ть может остав = 72;ться высоко прио = 88;итетной.<o:p></o:p> Приоритетm= 9; потребителk= 7;й при выборе требований = 82; качеству от = 88;ажаются не только на выделении важнейших для них критериев и ранжированl= 0;и приоритетоk= 4; других характерисm= 0;ик, но также на возможностl= 0; исключении из анализа некоторых характерисm= 0;ик качества, которые для данного потребителn= 3; не имеют значения. Представлеl= 5;ное в таблице 6.1 ра= ;нжирование может детализироk= 4;аться и изменятьс= 03; в зависимостl= 0; от функций П= 057; и реальных ресурсов, доступных для обеспеч = 77;ния их жизненного цикла. Эти приоритеты должны обобщаться = 80; учитыватьсn= 3; заказчиком = 87;роекта при подготовке контракта и техническоk= 5;о задания. После опред = 77;ления назначения = 80; функций ПС подготовка = 80;сходных данных и концепции проекта должны завершатьсn= 3; выделением номенклатуl= 8;ы приоритетнm= 9;х конструктиk= 4;ных атрибутов характерисm= 0;ик качества, имеющих доста= ;точное влияние на функционалn= 0;ную пригодностn= 0; ПС для определеннm= 9;х потребителk= 7;й.<o:p></o:p> = На этапе предваритеl= 3;ьного проектировk= 2;ния, после фиксированl= 0;я исходных данных и приоритетоk= 4; характерисm= 0;ик для конкретногl= 6; проекта и ег= 086; потребителk= 7;й, может начинаться выбор требо = 74;аний к свойствам и значениям, а также установленl= 0;е и утвержден = 80;е конкретных мер и шкал характерисm= 0;ик и атрибутов качества. Такой анали = 79; должны пров = 86;дить заказчик и некоторые потенциальl= 5;ые пользоватеl= 3;и совместно с = 86; специалистk= 2;ми, обеспечиваn= 2;щими ЖЦ комплекс = 72; программ и реализацию установленl= 5;ых требований = 82; показателяl= 4; качества. Этими специалистk= 2;ми, для каждого из выбранны = 93; атрибутов, должна быть установленk= 2; и согl= 3;асована мера и шкала оценок характерисm= 0;ик и их атрибут= 086;в для конкрет = 85;ого проекта и потребителn= 3; результатоk= 4; анализа. Там где кроме оц= 077;нивания наличия номинальныm= 3; свойств, возможны количествеl= 5;ные измерения, при оценке р= 077;ализации требований = 82; качеству может быть п= 086;лезен выбор и уста= 085;овление допусков на = 086;тклонения от величин требуемых спецификацl= 0;ями. Для показателеl= 1;, представляk= 7;мых качественнm= 9;ми свойствами = 80; признаками их наличия, желательно определить = 80; зафиксировk= 2;ть в специфика = 94;иях описания допустимых условий, при которых следует считать, что данная хара = 82;теристика может или до= 083;жна быть реализ = 86;вана в проекте ПС. <= o:p></o:p> = Принципиаl= 3;ьные и техническ = 80;е возможностl= 0;, точность реализации свойств и измерения значений характериl= 9;тик качества, а также общие ресурсы конкретноk= 5;о проекта, все= 075;да ограничены = 74; соответствl= 0;и с их содержаниеl= 4; и возможностn= 3;ми заказчика и разработчиl= 2;ов. Это определяет рациональнm= 9;е диапазоны значений каждого атрибута, которые мог = 91;т быть выбран = 99; для проекта ПС на основе требований заказчика, здравого смысла, а также путем анализа пилотных проектов и прецедентоk= 4; в специфика = 94;иях требований реализованl= 5;ых проектов. В пределах этих диапаз = 86;нов целесообраk= 9;но определениk= 7; реальной достовернl= 6;сти оценивания = 80; масштаба ме = 88; для описани= 03; соответствm= 1;ющего атрибута тр = 77;бований. <o:p></o:p> Требованиn= 3; к значениям характерисm= 0;ик качества должны быть предваритеl= 3;ьно проверены разработчиl= 2;ами на их реализуемоl= 9;ть с учетом доступных ресурсов конкретногl= 6; проекта и пр= 080; необходимоl= 9;ти откорректиl= 8;ованы по составу и значениям с учетом риск = 86;в. При ограниченнl= 6;сти ресурсов проекта ПС р= 072;спределени&= #1077; приоритетоk= 4; должно становитьсn= 3; более строгим и могут снижаться приоритеты = 93;арактерист&#= 1080;к, для реализации которых рес = 91;рсов недостаточl= 5;о. В результат = 77; формируетсn= 3; полный набо = 88; требуемых характерисm= 0;ик, свойств и атрибутов, и= 093; мер и значений ка = 95;ества для определеннm= 9;х потребителk= 7;й в ЖЦ ПС. <o:p></o:p> Входные проектные данные и требования = 82; ПС, включая установленl= 5;ые законодатеl= 3;ьные и регламентиl= 8;ующие нормативныk= 7; требования, должны быть, оформлены документалn= 0;но, а их выбор проанализиl= 8;ован поставщикоl= 4; на адекватносm= 0;ь. Неполные, дв= 091;смысленные или противоречl= 0;вые требования должны быть предметом урегулировk= 2;ния с лицами, ответственl= 5;ыми за их предъявленl= 0;е. Спецификацl= 0;ю требований должен пред = 89;тавить потребителn= 0;-заказчик. Однако по взаимному согласию её может подготовитn= 0; поставщик-р = 72;зработчик, в тесном сотрудничеl= 9;тве с потребите = 83;ем для предупреждk= 7;ний разногласиl= 1; путем, например, уточнения определениl= 1; терминов, объяснения предпосылоl= 2; и обоснован = 80;я требований. Исходные требования могут быть п= 088;едставлены и согласованm= 9; в виде специ= 092;икации всей систем = 99;. Если программныl= 1; продукт нуждается в = 86; взаимодейсm= 0;вии с другими программныl= 4;и или аппарат = 85;ыми продуктами, то в специфи= 082;ации требований должны быть оговорены непосредстk= 4;енно или при помощи ссылок интерфейсы = 84;ежду разрабатывk= 2;емыми и другими применяемыl= 4;и продуктами. = 042; этом случае должны быть = 088;азработаны процедуры, обеспечиваn= 2;щие четкое распределеl= 5;ие системных требований между аппаратнымl= 0; и программныl= 4;и компонентаl= 4;и, а также соответствm= 1;ющие спецификацl= 0;и интерфейсоk= 4; с внешней средой. При заключении контракта спецификацl= 0;я требований может быть определена не полность= 02;, она может быть доработана = 74; ходе реализ = 72;ции проекта. <o:p></o:p> Выходны= ;е проектные данные должны быть документалn= 0;но оформлены и выражены в требованияm= 3; так, чтобы их &= #1084;ожно было проверять в ЖЦ ПС и подтв&#= 1077;рдить соответствl= 0;е входным проектным т = 88;ебованиям. Выходные проектные данные долж = 85;ы содержать к = 88;итерии приемки про = 77;кта заказчиком или ссылки н= 072; них, а также идентифициl= 8;овать те характер = 80;стики проекта, которые являются критическиl= 4;и для безопасногl= 6; и надежного функционирl= 6;вания ПС. К составу выходных проектных данных могу = 90; относиться:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 87;ецификация структурноk= 5;о проектировk= 2;ния;<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1086;писание результатоk= 4; и спецификацl= 0;и рабочего проектировk= 2;ния компонентоk= 4;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 89;ходные тексты программ и программы в объектном коде;<o:p></o:p> <![if !supportLists]><= span style=3D'mso-bidi-font-size:14.0pt'>- = <![endif]>&#= 1082;омплект эксплуатацl= 0;онной документацl= 0;и и руковоk= 6;ств для пользо = 74;ателей;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;мплект технологичk= 7;ской документацl= 0;и для обеспечениn= 3; возможностl= 0; модификациl= 0; и сопровождеl= 5;ия ПС. <o:p></o:p> Результатm= 9; системного анализа и выбора номенклатуl= 8;ы и мер характерисm= 0;ик проектов ПС средней или относительl= 5;о невысокой сложности должны быть документирl= 6;ваны в спецификацl= 0;ях требований, согласованm= 9; с их потребителn= 3;ми и утвержден = 99; заказчиком проекта для последующеl= 1; реализации. Для разрабо = 90;чиков особенно важно форма = 83;изовать требования = 82; качеству и согласоватn= 0; их с заказчиком при утвержд = 77;нии контракта и техническоk= 5;о задания на проект ПС. Требования = 82; характерисm= 0;икам, утвержденнm= 9;е после предваритеl= 3;ьного проектировk= 2;ния, могут быть закреплены = 74; техническоl= 4; задании как обязательнm= 9;е для детального = 80; рабочего проектировk= 2;ния. Эти данные могут испол= 00;зоваться при последу= 02;щем оценивании = 82;ачества и его сопоставлеl= 5;ии с требованияl= 4;и в процессе квалификацl= 0;онных испытаний или сертифи = 82;ации ПС. Однако для крупных = 080; дорогих проектов может потребоватn= 0;ся уточнение т = 88;ебований к качеству при дk= 7;тальном проектировk= 2;нии с позиции улучшения соотношениn= 3; значений качества и затрат ресурсов, ко= 090;орые необходимы или допустимы для их реали= 079;ации в ЖЦ ПС.&nbs= p; <o:p></o:p> При детальном проектировk= 2;нии может быть целесообраk= 9;но дополнителn= 0;ное уточнение совокупносm= 0;и требований выбранных характериl= 9;тик и атрибутов качества сложных ПС с учетом соотношениn= 3; качес= ;тва и затрат ресурсов, которые могут быть весьма велики. Для заказчика и пользоватеl= 3;ей может иметь значение не только опре = 76;еление функц= ;иональной пригодностl= 0;, но и потенциальl= 5;ого спроса на рынке конкретногl= 6; программноk= 5;о продукта, а также его конкурентоl= 9;пособности с другими аналогичныl= 4;и по функциям ПС с учетом его качеств = 72; и стоимости. Это обстоят = 77;льство может определять необходимоl= 9;ть уточнения требований = 82; отдельным характерисm= 0;икам качества не только для и= 093; реализации разработчиl= 2;ами в ЖЦ ПС, но также для оценивания интегральнl= 6;го качества го = 90;ового программноk= 5;о продукта поставляемl= 6;го на рынок. <o:p></o:p> Каждая характерисm= 0;ика качества и затраты ресурсов первоначалn= 0;но анализируюm= 0;ся независимо, что может использоваm= 0;ься в качестве исходных данных для и= 093; сопоставлеl= 5;ия с отдельным = 80; характерисm= 0;иками аналогичныm= 3; ПС, или для представлеl= 5;ия, как составл= 03;ющей вектора в многомерноl= 4; пространстk= 4;е стандартизl= 0;рованных атрибутов характерисm= 0;ик качества. Обычно заказчики и разработчиl= 2;и первоначалn= 0;но устанавливk= 2;ют требования = 82; каждой характерисm= 0;ике без учета от= 085;осительных затрат на их достижение, = 072; также без детального анализа их совместногl= 6; влияния на полную функ = 94;иональную пригодностn= 0; у потребителk= 7;й. Это может приводить к значительнm= 9;м перекосам и несбалансиl= 8;ованным значениям требований = 82; отдельным, взаимосвязk= 2;нным характерисm= 0;икам качества, на которые не р= 072;ционально используютl= 9;я ограниченнm= 9;е ресурсы ЖЦ ПС, или к не ад= екватно низким их значениям. В проектах крупных ПС это может угрожать зн = 72;чительным повышением стоимости и/или снижением конкурентоl= 9;пособности создаваемоk= 5;о программноk= 5;о продукта из-за недост= 072;точного уровня отдельных п = 86;казателей качества.<o:p></o:p>= Атрибуты к = 72;чества ПС имеют различные меры и шкалы, вследствие чего они в большинствk= 7; своем непос = 88;едственно не сопоставимm= 9; между собой. Они предвар = 80;тельно выбираются = 80; согласовывk= 2;ются с заказчико = 84; при последоватk= 7;льном, почти незав = 80;симом анализе каждого атрибута качества в соответствl= 0;и с их мерами и шкалами, для последующеk= 5;о использоваl= 5;ия в контракте = 080; техническоl= 4; задании. Для обобщенногl= 6; оцени= ;вания качества ПС необходим учет относи = 90;ельного влияния каждого атр = 80;бута на функционалn= 0;ную пригодностn= 0;. При этом не всегда учит = 99;ваются ресурсы для их реализации в конкретноl= 4; ПС. Это часто приводит к в= 099;движению ряда не рациональнm= 9;х требований, которые значительнl= 6; отличаются: либо по степени влияния на функционалn= 0;ную пригодностn= 0;, либо по величине ре = 89;урсов, необходимыm= 3; для их реали= 079;ации. Для целенаправl= 3;енного эффективноk= 5;о управления качеством сложного ПС при проекти = 88;овании целесообраk= 9;но иметь механизм объединениn= 3; разнородныm= 3; характерисm= 0;ик в некоторый интегральнm= 9;й показатель, отражающий их совокупн = 86;е влияние на его функцио = 85;альную пригодностn= 0;. Таким образом, при разработке требований = 82; характерисm= 0;икам качества выявилась п = 88;облема анализа систе= ;мной эффективнl= 6;сти прогр= ;аммного средства и обобщения его характе = 88;истик, а также оцениваниn= 3; совместногl= 6; влияния различных характерисm= 0;ик и атрибутов качества на функционалn= 0;ную пригодностn= 0; ПС с учетом затрат на их реализацию (см. лекцию 12). <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102470"></a><a name=3D"_Toc508102243">6.3. Структур= ;а основных документов, отражающих требования = 82; программны&= #1084; средствам</a><= span style=3D'mso-spacerun:yes'> </h1> <o:p= ></o:p> При разработке требований = 82; проектам программныm= 3; средств, кроме основных целей, назначения = 80; функций важно учест= 00; и сформулир = 86;вать содержание достаточно полного множества характерисm= 0;ик, каждая из которых может влият= 00; на успех проекта про = 75;раммного продукта. Дл= 103; уменьшения вероятностl= 0; случайного пропуска ва = 78;ного требования заказчикам = 80; пользоватеl= 3;ям целесообраk= 9;но иметь типовые проекты перечней (шаблоны) наборов требованиl= 1;, которые мож = 85;о целеустремl= 3;енно сокращать и адаптироваm= 0;ь, обеспечиваn= 3; целостностn= 0; требований для конкрет = 85;ых проектов ПС. Ниже представлеl= 5;ы примеры состава требований на двух этап= 072;х жизненного цикла сложных ПС: на этапе фор= 084;ирования концепции П = 57; и на этапе детального проектировk= 2;ния комплекса программ. <o:p></o:p></span= > <o:p></o:p> Соста= в концепции основных требо= ;ваний к программноl= 4;у средству:<o:p></o:p>= <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1086;писание обобщенных результатоk= 4; обследованl= 0;я и изучения существующk= 7;й системы и внешней среды;<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1086;писание целей, назначения программноk= 5;о продукта и потребностk= 7;й заказчика и потенциальl= 5;ых пользоватеl= 3;ей к нему в зада&#= 1085;ной среде приме = 85;ения;<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1087;еречень базовых стандартов предполагаk= 7;мого проекта про = 75;раммного продукта;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;щие требования = 82; характерисm= 0;икам комплекса задач ПС:<o:p></o:p> * цели создания программноk= 5;о продукта и н= 072;значение комплекса функционалn= 0;ных задач;<o:p></o:p> * перечень объектов среды применения ПС (технолог= 080;ческих объектов управления, подразделеl= 5;ий предприятиn= 3; и т. п.), при управлении которыми до = 83;жен решаться комплекс задач;<o:p></o:p> * периодичнl= 6;сть и продолжитеl= 3;ьность решения комплекса з = 72;дач;<o:p></o:p> * связи и взаимодейсm= 0;вие комплекса задач с внеш= 085;ей средой и дру= 075;ими компонентаl= 4;и системы;<o:p></o:p> * распределеl= 5;ие функций между персоналом, программныl= 4;и и техl= 5;ическими средствами при различных ситуациях решения тре = 73;уемого комплекса функционалn= 0;ных задач= ;;<o:p></o:p> - требованиn= 3; к входной информации:<o:p= ></o:p> * источники информации = 80; их идентифи = 82;аторы;<o:p></o:p> * перечень и описание входных соо = 73;щений (идентифика = 90;оры, формы представлеl= 5;ия, регламент, сроки и част= 086;та поступлениn= 3;); <o:p></o:p> * перечень и описание структурныm= 3; единиц информации входных сообщений или ссылка н= 072; документы, содержащие эти данные;<o:p></o:p= > - требованиn= 3; к выходной информации:<o:p= ></o:p> * потребитеl= 3;и и назначени = 77; выходной информации;<o:p= ></o:p> * перечень и описание выходных сообщений;<o:p></o:p>= * регламент = 80; периодичноl= 9;ть их выдачи;<o:p></o:p></span= > * допустимоk= 7; время задержки решения определеннm= 9;х задач;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;писание и оценка преимущестk= 4; и недостатк = 86;в разработанl= 5;ых альтернатиk= 4;ных вариантов функций в концепции создания проекта ПС;<o:p></o:p= > <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1089;опоставите= льный анализ требований заказчика и пользоватеl= 3;ей к программн = 86;му продукту и набора функций в концепции П = 57; для удовлет = 74;орения требований заказчика и пользоватеl= 3;ей;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;боснование выбора оптимальноk= 5;о варианта требований = 82; содержанию = 80; приоритетаl= 4; комплекса функций ПС в концепции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;щие требования = 82; структуре, составу ком = 87;онентов и интерфейс = 72;м с внешней средой; <o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;жидаемые результаты = 80; возможная эффективноl= 9;ть реализации выбранного варианта требований = 74; концепции П = 57;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 88;иентировоч&#= 1085;ый план реализации выбранного варианта тр = 77;бований концепции ПС;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;бщие требования = 82; составу и содержанию = 76;окументаци&#= 1080; проекта ПС;<o:p></o:p= > <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;ценка необходимыm= 3; затрат ресурсов на разработку, ввод в действие и обеспечениk= 7; функционирl= 6;вания ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ый состав требований, гарантируюm= 7;их качество применения ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ые требования = 82; условиям ис = 87;ытаний и приемки си= 089;темы и ПС.<o:p></o:p> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-align:justify;text-inden= t: 35.45pt;line-height:normal;tab-stops:35.4pt'><a name=3D"_Toc4297197"> <o:p></o:p= ></a></h2> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:35.45pt;line-heig= ht: normal;tab-stops:35.4pt'> Спецификаm= 4;ия требований = 82; системе и к комплексу программ на = 101;тапе детального проектировk= 2;ния:<o:p></o:p></h2> <![if !supportLists]>- = <![endif]>тре&= #1073;ования проекта системы к комплексу программ, ка= 082; к целому в общей архит = 77;ктуре системы; <o:p></o:p></span= > <![if !supportLists]>- = <![endif]>тре&= #1073;ования к унификации интерфейсl= 6;в и базы данны= 093; комплекса п = 88;ограмм;<o:p></o:p> <![if !supp= ortLists]>-&nb= sp; = <![endif]>т = 88;ебования и обоснованиk= 7; выбора проектных решений уровня системы, состава компонентоk= 4; системы, опи= 089;ание функций системы и ПС с точки зрен= 080;я пользоватеl= 3;я; <o:p></o:p> <![if !supp= ortLists]>-&nb= sp; = <![endif]>с = 87;ецификация требований верхнего уровня комплекса п = 88;ограмм, производныk= 7; требования = 82; компонентаl= 4; ПС и требования = 82; интерфейсаl= 4; между систе = 84;ными компонентаl= 4;и, элементами конфигурацl= 0;и ПС и аппарат= 091;ры;<o:p></o:p> <![if !supportLists]>- &nbs= p; <![endif]>о = 87;исание распределеl= 5;ия системных требований по компонен = 90;ам ПС с учетом требований, которые обеспечиваn= 2;т заданные характерисm= 0;ики качества;<o:p></o:p>= <![if !supportLists]>- = <![endif]>тре&= #1073;ования к архитектурk= 7; системы, содержащей идентификаm= 4;ию и функции компонентоk= 4; системы, их назначение, статус разр = 72;ботки, аппаратные = 80; программныk= 7; ресурсы;<o:p></o:p>= <![if !supportLists]>- = <![endif]>тре&= #1073;ования совместногl= 6; целостного функционирl= 6;вания компонентоk= 4; ПС, описание и характерисm= 0;ики их динамическl= 0;х связей;<o:p></o:p> <![if !supportLists]>- = <![endif]>тре&= #1073;ования анализа тр= ;ассируемос = 90;и функций компонентоk= 4; программноk= 5;о средства к требованияl= 4; проекта сис = 90;емы;<o:p></o:p> <![if !supportLi= sts]>- = <![endif]>тре&= #1073;ования для системы или/и подсистем и = 084;етоды, которые должны быть = 080;спользован&= #1099; для гаранти = 80; того, что каждое треб = 86;вание к комплексу программ будет выпол = 85;ено и прослеживаk= 7;мо к конкретны = 84; требованияl= 4; системы:<o:p></o:p> * к режимам работы;<o:p></o:p> * к производитk= 7;льности системы;<o:p></o:p> * к внешнему и пользоватеl= 3;ьскому интерфейсу системы;<o:p></o:p> * к внутреннемm= 1; интерфейсу компонентоk= 4; и к внутренн= 080;м данным системы;<o:p></o:p> * по возможностl= 0; адаптации П = 57; к внешней ср= 077;де;<o:p></o:p> * по обеспечениn= 2; безопасносm= 0;и системы, ПС и &= #1074;нешней среды;<o:p></o:p> * по обеспечениn= 2; защиты, безопасносm= 0;и и секретностl= 0; данных;<o:p></o:p> * по ограничениn= 3;м доступных ресурсов проекта ПС;<o:p></o:p= > * по обучению и уровню квалификацl= 0;и персонала;<o:p= ></o:p> * по возможностn= 3;м средств аттестации результатоk= 4; и компонентоk= 4;, включающие = 74; себя демонс = 90;рацию, тестированl= 0;е, анализ, инспекцию и требуемые специальныk= 7; методы для контроля функций и качества ко = 85;кретной системы или компонента ПС.<o:p></o:p> Представлk= 7;нный состав спец = 80;фикации требований на этапе дет= 072;льного проектировk= 2;ния может использоваm= 0;ься как компоне = 85;т для уточнен = 80;я техническоk= 5;о задания и ко= 085;тракта с заказчико = 84; на проект ЖЦ ПС и служить базой для формированl= 0;я комплекса о = 90;четных требований, утверждаемm= 9;х и проверяемыm= 3; заказчиком при приемке = 075;отового программноk= 5;о продукта. Состав стандартизl= 0;рованных характерисm= 0;ик качества программныm= 3; средств и процессы выбора треб = 86;ваний к ним в конкретных проектах представлеl= 5;ы в лекциях 11 и 12. Эти требования должны быть отдельным, обязательнm= 9;м разделом в общей спецификацl= 0;и требований, итерационнl= 6; формируемыl= 4;и на этапах концепции и проектировk= 2;ния ПС, и контролируk= 7;мыми при испытаниях программноk= 5;о продукта.<o:p></o:p>= <o:p> </o:p> <h1><a name=3D"_Toc508102471"></a><a name=3D"_Toc508102244">Лекция 7. Планированl= 0;е жизненного цикла = &nb= sp; программнm= 9;х средств</a></h1> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:35.45pt;line-heig= ht: normal'><o:p> </o:p></h2> <h1><a name=3D"_Toc508102472"></a><a name=3D"_Toc508102245">7.1. Организациn= 3; планированl= 0;я жизненного цикла = сложных пр = 86;граммных средств</a></h1> <o:p> </o:p> Цель планированl= 0;я жизненного цикла программноk= 5;о средства состоит в выборе и определениl= 0; способов создания и совершенстk= 4;ования ПС, ко = 90;орые способны удовлетворl= 0;ть требованияl= 4; техническоk= 5;о задания, спе= 094;ификаций и контракта, а также обеспечить уровень качества, со= 086;тветствующ&= #1080;й заданным тр = 77;бованиям. В современн = 99;х стандартах подчеркиваk= 7;тся, что эффективноk= 7; планированl= 0;е - определяющl= 0;й фактор высокого ка = 95;ества всего ЖЦ программноk= 5;о средства, удовлетворn= 3;ющего требованияl= 4; заказчика. В стандартах ISO 12207 и ISO 16326 рекомен&#= 1076;уется определить = 72;дминистрат&#= 1086;ра, который должен подг = 86;товить планы для выполнения процессов ЖЦ ПС. = 055;ланы, связанные с = 074;ыполнением процесса, должны содержать описания соответствm= 1;ющих работ и задач, обозн= 072;чения создаваемыm= 3; компонентоk= 4; программноk= 5;о средства и охватывать следующие задачи:<o:p></o:p> установ= ;ление графиков своевременl= 5;ого решения частных зад = 72;ч и всего ПС;<o:p></o:p></spa= n> оценки необходимыm= 3; трудозатраm= 0; на задачи и проект в целом;<o:p></o:p> определ= ;ение ресурсов, необходимыm= 3; для выполне = 85;ия задач и прое= 082;та;<o:p></o:p> распред= ;еление задач по исп= 086;лнителям;<o:p></o:p></s= pan> определ= ;ение обязанностk= 7;й исполнителk= 7;й;<o:p></o:p> определ= ;ение критическиm= 3; ситуаций, связанных с задачами ил = 80; процессами ЖЦ ПС;<o:p></o:p> установ= ;ление используемm= 9;х в процессах = 046;Ц ПС критерие = 74; управления качеством; - определенl= 0;е затрат, связанных с = 088;еализацией каждого процесса;<o:p></o:p>= обеспеч= ;ение условий и определениk= 7; инфраструкm= 0;уры выполнения процессов Ж = 62; ПС.<o:p></o:p> Должны быт= 00; определены обязанностl= 0; специалистl= 6;в по подготовке = 80; утверждениn= 2; (согласован = 80;ю) планов. Следует уст = 72;новить модель жизн = 77;нного цикла программноk= 5;о средства, задачи, расп= 088;еделение задач, их бло&#= 1082;ировку и соответствm= 1;ющие ресурсы. В пр&#= 1086;граммном проекте должен быть определен о = 76;ин основной график рабо = 90;, а все вспомо= 075;ательные графики должны быть связаны и согласованm= 9; с основным графиком. С помощью структуры классификаm= 4;ии работ можно эффективно проверять ход процессов и обеспечиваm= 0;ь контроль этих процессов и продуктов. План должен быт= 00; применен так, чтобы обеспечить управление программныl= 4; проектом на всех уровня = 93; его детализациl= 0; с использоваl= 5;ием соответствm= 1;ющих технологий = 74; зависимостl= 0; от объема, сложности, критичностl= 0; и риска прое= 082;та. Оценки проекта, используемm= 9;е при планиро = 74;ании, должны охва = 90;ывать: <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>с = 90;оимость реализации соответствm= 1;ющих процессов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>и = 85;фраструкту&#= 1088;у обеспечениn= 3; реализации = 87;роцессов;<o:p></o:p></sp= an> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>п = 86;требности в ресурсах, включая соответствm= 1;ющее управление = 80; контроль;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>о = 94;енку и контроль качества реализации процессов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>у = 87;равление риском результатоk= 4; процессов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>о = 73;еспечение среды программноl= 1; инженерии проекта ПС;<o:p></o:p= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>з = 72;дания, выполняемыk= 7; в каждом процессе и (и&#= 1083;и) работе.<o:p></o:p> &n= bsp; Администрk= 2;торы каждого программноk= 5;о проекта должны стре = 84;иться по возможно = 89;ти использоваm= 0;ь существующm= 1;ю организациl= 6;нную инфраструкm= 0;уру предприятиn= 3;. Если существующk= 2;я инфраструкm= 0;ура не удовлетв = 86;ряет потребностn= 3;м конкретногl= 6; проекта, тогда она должна быть = 089;оответству&= #1102;щим образом ада = 87;тирована или дополне = 85;а. Для устранения несовершенl= 9;тва (неполноты) существующk= 7;й инфраструкm= 0;уры может потре = 73;оваться использоваl= 5;ие субподряднm= 9;х работ. <o:p></o:p> Планироваl= 5;ие является постоянной, повторяющеl= 1;ся работой, при выполнении которой оценивают, уточняют и, при необходимоl= 9;ти, корректируn= 2;т ход проекта. Администраm= 0;оры программноk= 5;о проекта дол = 78;ны использоваm= 0;ь соответствm= 1;ющие процессы, сп= 086;собствующи&= #1077; проведению перепланирl= 6;вания и уточненны = 93; оценок в жизненном цикле прогр = 72;ммного проекта. В каждом программноl= 4; проекте имеется мно = 78;ество взаимосвязk= 7;й, поэтому для уточнения исходного плана управления проектом обычно требуется несколько и = 90;ераций. При необходимоl= 9;ти внесения в план управл = 77;ния информации, содержащейl= 9;я в других пла= 085;ах, в данном пла= 085;е может быть приведена ссылка на эт= 080; планы.<o:p></o:p> В стандарте ISO 15504 расширены, детализироk= 4;аны задачи и вид= 099; деятельносm= 0;и, которые следует отраж= ;ать в плане управления проектом ПС: <o= :p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>в = 99;брать модель жизненного цикла программныm= 3; средств, соо= 090;ветствующу&= #1102; назначению, функциям, величине и сложности п = 88;оекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>о = 87;ределить работы, которые необходимо выполнить п = 86; проекту и возможностn= 0; достижения целей проекта в рамках суще = 89;твующих ресурсов и ограничениl= 1;;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>о = 94;енить варианты достижения целей проек = 90;а и определит= 00;, на основе анализа рисков, кака= 103; стратегия целесообраk= 9;на; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>к = 86;личественн&#= 1086; оценить сложность работ и ресу= 088;сы, необходимыk= 7; для их выпол= 085;ения, рассматривk= 2;я варианты достижения = 94;елей проекта и принимая во внимание су = 97;ествующие риски и возм= 086;жности, чтобы весь жизненный ц = 80;кл ПС удовлетворn= 3;л требованияl= 4; заказчика; <o:p></o:p= > <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>в = 99;явить и выбрать элементы человеческl= 0;х и материальнm= 9;х ресурсов, необходимыk= 7; для обеспечениn= 3; и реализаци = 80; стратегии проекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>у = 89;тановить график (исполнител = 80;, сроки, ресур= 089;ы) выполнения проекта, осн= 086;вываясь на распреде = 83;ении работ, оценках и элементах и = 85;фраструкту&#= 1088;ы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 99;явить конкретных лиц и группы, дающие треб = 91;емый вклад в проект, опре= 076;елить им конкретные зоны ответственl= 5;ости, и обеспечит= 00; то, чтобы обя&#= 1079;анности были поняты = 080; приняты, профинансиl= 8;ованы и достижимы;<o:= p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 76;ентифициро&#= 1074;ать интерфейсы между элементами проекта, а также с другими проектами и = 086;рганизацио&= #1085;ными единицами с = 80;стемы; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 87;ределить инструментk= 2;рий для обеспеч = 77;ния того, чтобы планы проекта был = 80; формально разработанm= 9;, реализованm= 9;, поддержаны = 80; доступны лицам, вовле= 095;енным в проект, обеспечить публикацию планов для специалистl= 6;в, к которым он= 080; относятся;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>и = 89;пользовать упорядоченl= 5;ые методы для т= 086;го, чтобы регул= 03;рно оценивать степень выполнение проекта, при= 085;имать меры, для корректироk= 4;ки отклонений от плана и предотвращk= 7;ния повторения проблем, выя= 074;ленных в проекте.<o:p></o:p></span= > Поставщ= ;ик-разработ= 095;ик ПС должен подготовитn= 0; планы по каж= 076;ому виду деятельносm= 0;и. Следует установить = 80; поддерживаm= 0;ь в рабочем состоянии документирl= 6;ванные процедуры, гарантируюm= 7;ие разработку программноk= 5;о продукта в соответствl= 0;и с заданными требованияl= 4;и и согласно плану развития ЖЦ. Такие планы должны описывать в = 80;ды деятельносm= 0;и или содержать ссылки на разделы стандартов = 80; определять ответственl= 5;ость за их осущес= 090;вление. <o:p></o:p> Планиро= ;вание жизненного цикла ПС должно опре = 76;елить действия по анализу тре = 73;ований, проектировk= 2;нию, программирl= 6;ванию, интегрировk= 2;нию, тестированl= 0;ю, установке и поддержке программныm= 3; средств с це= 083;ью их принятия = 080; применения заказчиком. = 046;изненный цикл следуе = 90; оформить документамl= 0;, которые необходимо = 87;роанализир&#= 1086;вать на реализуе = 84;ость и утвердить. Они должны актуализирl= 6;ваться по мере развития пр = 86;екта. В планах необходимо определить, каким образом сле = 76;ует управлять проектом, контролироk= 4;ать и анализировk= 2;ть выполнение работ, а такж&#= 1077; установить вид и частот= 091; отчетов для руководствk= 2;, заказчика и других заин = 90;ересованны&#= 1093; сторон, принимая во внимание вс = 77; конкретные требования заказчика. В планах должны определятьl= 9;я организациl= 6;нные подразделеl= 5;ия и специалистm= 9;, которые будут испол = 85;ять различные виды работ. Для этого планы должн = 99; содержать с = 83;едующую информацию:<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>р = 86;ли и обязанностn= 3;х соответствm= 1;ющих субъектов проекта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>п = 86;длежащие выполнению работы и задачи;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>п = 77;речень всех проектных результатоk= 4; (продуктов), подлежащих поставке и определеннm= 9;х в структуре классификаm= 4;ии работ;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>к = 88;итерии завершения соответствm= 1;ющей деятельносm= 0;и, работ, задач;<o= :p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>с = 86;став окончательl= 5;ых отчетных документов;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>о = 90;четные документы п = 86; стоимости и графикам проведения = 88;абот;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>с = 86;держание средств организациl= 0; работ по упр= 072;влению, выпуску продукта и/или синхронизаm= 4;ии работ;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>п = 77;риодичност&#= 1100; и средства выдачи отчетных документов;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>о = 90;четные материалы п = 86; проблемам-д = 77;фектам или выполнению деятельносm= 0;и;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>т = 88;ебования к ресурсам и их наличие.<o:p></o:p= > Стандар= ;тами ISO 16326 и ISO 90003 &nb= sp; рекомендуk= 7;тся в процессе п= 083;анирования ЖЦ ПС подгот= 086;вить и утвердить содержание следующих п = 83;анов (рис. 7.1): <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;зработки компонентоk= 4; и всего ЖЦ ПС, который должен определять используемm= 1;ю модель жизненного цикла комплекса п = 88;ограмм и его компон= 077;нтов, а также внеш= 085;юю технологичk= 7;скую среду проектировk= 2;ния;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 77;рификации и тестированl= 0;я, который оп = 88;еделяет методы и средства, способные удовлетворl= 0;ть последоватk= 7;льные цели процесса устранения дефектов и контроля ка = 95;ества ПС и его комп&#= 1086;нентов;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 77;ализации процессов интеграции компонентоk= 4; в версии ком= 087;лекса программ;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;провождени&#= 1103; и управлени= 03; конфигурацl= 0;ей ПС, который должен устанавливk= 2;ть методы и средства, пр= 080; помощи которых буд = 91;т удовлетворn= 3;ться цели процесса со = 74;ершенствов&#= 1072;ния, управления = 80;зменениями и корректироk= 4;ками программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>т = 80;ражировани&#= 1103;, адаптации и внедрения версий ПС дл= 103; конкретных пользоватеl= 3;ей, включая их подготовку = 80; обучение; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1076;окументиро= вания процессов и результатоk= 4; жизненного цикла ПС, создания и выпуска тех = 85;ологическо&#= 1081; и эксплуатацl= 0;онной документацl= 0;и; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1091;правления и обеспечениn= 3; качества ПС, определяющl= 0;х методы и средства, пр= 080; помощи которых будет гаран = 90;ировано требуемое качество ко = 84;плекса программ.<o:p></o:p>= Соответстk= 4;ующие планы должн = 99; быть разработанm= 9; администраm= 0;орами вспомогатеl= 3;ьных процессов, так как эти процессы об = 99;чно являются частью проекта. Данные план = 99; должны быть привязаны к базовому плану управ = 83;ения жизненным циклом программноk= 5;о проекта и обеспечиваm= 0;ь его реализацию; они могут быть оформл = 77;ны в виде отдел= 100;ных планов или включены в общий план. Планы должны быть согласованm= 9; (утверждены) менеджером проекта про = 75;раммного средства и подлежат контролю пр = 80; внесении изменений в проект. Менеджером </sp= an>= - администраm= 0;ором планированl= 0;я программноk= 5;о средства должна быть определена отчетность по вспомога = 90;ельным процессам (либо непосредстk= 4;енная, либо через управление организациk= 7;й). Должны быть представлеl= 5;ы отчеты о про= 073;лемах-дефек= тах и исключителn= 0;ных ситуациях д = 83;я анализа их влияния на стоимость проекта, график рабо = 90; по нему, область управления проектом и его качеств = 86;. Должен быть определен механизм дл= 03; разрешения или преодол = 77;ния конфликтныm= 3; ситуаций между админ = 80;стратором планированl= 0;я ЖЦ программноk= 5;о средства и администраm= 0;орами вспомогатеl= 3;ьных процессов н = 72; соответствm= 1;ющем уровне их полномочий по организациl= 6;нному управлению.<o:p= ></o:p> Когда определеннm= 9;е контрольныk= 7; точки проекта и результаты, установленl= 5;ые требованияl= 4;и для этих точек, зависят от выходных р = 77;зультатов вспомогатеl= 3;ьного процесса, важно, чтобы отчетные материалы п = 86; ним были представлеl= 5;ы точно и своевременl= 5;о в соответствl= 0;и с установле = 85;ными планами. Это положение является общим для всех контро = 83;ьных точек, связанных с выполнениеl= 4; договорных обязательсm= 0;в по вспомога = 90;ельным процессам, поэтому необходимы = 89;инхронизац&#= 1080;я соответствm= 1;ющих планов и своевременl= 5;ое уведомлениk= 7; администра&#= 1090;ора программноk= 5;о средства о всех затруднениn= 3;х, возникающиm= 3; при выполне = 85;ии соответствm= 1;ющих задач вспомогатеl= 3;ьных процессов. Синхронизаm= 4;ия всех планов может быть з= 072;труднена при наличии субподряднm= 9;х соглашений = 80; заданий, но упрощена пр = 80; наличии еди = 85;ого базового плана.<o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102473"></a><a name=3D"_Toc508102246">7.2. Задачи планов для обеспечениn= 3; жизненного цикла сложн = 99;х прогр= ;аммных средств</a></h1> <o:p> </o:p> План управления жизненным циклом ПС включает регламентиl= 8;ованные стандартамl= 0;, процедуры анализа, проверки и оценки сост = 86;яния проекта для реализации организациl= 6;нных и управляющиm= 3; воздействиl= 1; на компонен = 90;ы и ПС в целом. При этом должны испо = 83;ьзоваться техническоk= 7; задание и спецификацl= 0;и требований, = 074; которых определяющm= 1;ю роль играют согласованl= 5;ые с заказчико = 84; входные и выходные данные проекта ПС. П&#= 1086;требитель-з= ;аказчик может иметь определеннm= 9;е обязанностl= 0; согласно ко = 85;тракту при формиро = 74;ании ЖЦ ПС. Особого внимания потребителn= 3; требует сотрудничеl= 9;тво с разработч = 80;ком-поставщ&= #1080;ком, своевременl= 5;ое предоставлk= 7;ние ему нужной информации = 80; решение опе = 88;ативных вопросов дл= 03; обеспечениn= 3; качества ПС. Если предст = 72;витель заказчика обладает соответствm= 1;ющей компетентнl= 6;стью, то он может представляm= 0;ь конечного пользоватеl= 3;я продукта, а также админ = 80;стративное руководствl= 6; проектом и иметь полно = 84;очия заниматься контрактныl= 4;и вопросами. К ним относят = 89;я определениk= 7; и уточнение требований спецификацl= 0;й потребителn= 3; к поставщик = 91; и к показателяl= 4; качества ПС, одобрение и утверждениk= 7; предложениl= 1; разработчиl= 2;а, а также заключение дополнителn= 0;ных соглашений = 89; поставщикоl= 4;. Целесо&#= 1086;бразно планироватn= 0; либо регуля = 88;но проводить разработчиl= 2;ом и заказчико = 84; совместные анализы состояния п = 88;оекта, либо такие анализы в случае значительнm= 9;х проектных событий, чтобы охват = 80;ть:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;стояние и развитие выполняемыm= 3; поставщикоl= 4; работ по раз= 088;аботке и модификац = 80;и программноk= 5;о средства;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;ответствие результатоk= 4; разработки, согласованl= 5;ой спецификацl= 0;и требований заказчика;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;стояние работ, касающихся подготовки = 80; обучения конечных пользоватеl= 3;ей разрабатывk= 2;емой системы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 77;зультаты проверок текущего состояния п = 88;оекта и приемочны = 93; испытаний.<o:p></o:p>= План разработки компонентоk= 4; и ПС в целом (см. рис. 7.1) должен включать назначение, стандарты и описание фрагментов жизненного цикла, которые следует использоваm= 0;ь в процессе разработки:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ое описание процессов стандартизl= 0;рованного ЖЦ ПС и его компон= 077;нтов, которые должны использоваm= 0;ься для формиро = 74;ания конкретногl= 6; жизненного цикла данного проекта, включая кри = 90;ерии перехода между этапами разработки;<o:p= ></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>и = 76;ентификаци&#= 1102; фрагментов стандартов: на требован = 80;я к ПС; описание проекта; кодированиk= 7; программ дл= 03; данного проекта; а также, ссылк= 080; на стандарт = 99; для ранее ра= 079;работанных компонентоk= 4;, включая исп = 86;льзуемые готовые апробироваl= 5;ные компоненты ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 73;основание выбора инструментk= 2;льной среды разработки ПС в аппаратной = 80; программноl= 1; части, которые будут использоваm= 0;ься, включая выбор языков программирl= 6;вания, средств кодированиn= 3;, компиляторl= 6;в, редакторов связей и загрузчикоk= 4;.<o:p></o:p> План верификациl= 0; и тестированl= 0;я ПС является предваритеl= 3;ьным описанием организациl= 0; процедур тестированl= 0;я, удовлетворn= 3;ющих цели достижения = 79;аданной корректносm= 0;и программ. Данный план должен вклю = 95;ать:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;исание методов, которые будут использоваm= 0;ься на каждом этапе, а также для обеспечениn= 3; независимоl= 9;ти верификациl= 0; и тестирова = 85;ия;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;спределени&#= 1077; организациl= 6;нной ответственl= 5;ости внутри проц = 77;ссов тестированl= 0;я и интерфейс = 99; с другими процессами жизненного цикла ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;исания оборудованl= 0;я для анализа = 080; тестироваl= 5;ия, инструментk= 2;льных средств, а также руководств по применен = 80;ю этих средст = 74; и аппаратно = 75;о тестового оборудованl= 0;я;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;исание методов идентификаm= 4;ии компонентоk= 4;, на которые оказывает воздействиk= 7; модификациn= 3; ПС, и измененные части исполняемоk= 5;о объектного кода. <o:p></o:p> План сопровождеl= 5;ия и управлени= 03; конфигурацl= 0;ей ПС устанавливk= 2;ет методы, испо= 083;ьзуемые для сопровождеl= 5;ия программныm= 3; средств и их компонентоk= 4; в течение всего жизненного цикла. Этот план должен включать:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>о = 87;исание процессов управления конфигурацl= 0;ей в жизненном цикле ПС, кот&#= 1086;рые обеспечат выполнение задач сопро = 74;ождения;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1086;писание среды управления конфигурацl= 0;ей, которую следует использоваm= 0;ь, включая процедуры, инструментk= 2;льные средства, методы, стандарты, о= 088;ганизацион&= #1085;ые соглашения = 80; интерфейсы;<o:p= ></o:p> <= ![if !supportLists]>- &nb= sp; <![endif]>и = 76;ентификаци&#= 1102; отчетов о дефектах и ошибках программноk= 5;о продукта и п= 088;оцессов жизненного цикла; метод закрытия от = 95;етов об ошибках и взаимодейсm= 0;вия с контролем изменений;<o:p></o:p>= <= ![if !supportLists]>- &nb= sp; <![endif]>а = 88;хивацию версий; применение методов и ср= 077;дств формированl= 0;я версий и обеспечениn= 3; их сохранностl= 0;.<o:p></o:p> Цель планированl= 0;я технологичk= 7;ской среды жизненного цикла ПС состоит в том, чтобы оп&#= 1088;еделить методы, инструментk= 2;льные средства, процедуры, языки программирl= 6;вания и аппаратны = 77; средства, которые буд = 91;т использо= ;ваться и совершенстk= 4;оваться для разработки, верификациl= 0;, управления = 80; подготовки документацl= 0;и программноk= 5;о средства. План должен включать стандарты, методы предотвращk= 7;ния ошибок и обеспечениn= 3; отказоустоl= 1;чивости, которые ограничиваn= 2;т возможностn= 0; внесения ош = 80;бок, и такие методы тест = 80;рования, которые гарантируюm= 0; их обнаруже = 85;ие. Цель методо = 74; обеспечениn= 3; отказоустоl= 1;чивости состоит в том, чтобы включить в проект таки = 77; средства обеспечениn= 3; качества и безопасносm= 0;и применения ПС, которые могут гарантировk= 2;ть, что програм = 84;ное средство бу = 76;ет адекватно реагироватn= 0; на ошибки входных данных, предотвращk= 2;ть выдачу ошиб = 86;чных данных и контролироk= 4;ать возможностn= 0; проявления ошибок. <o:p></o:p> Кроме того, в составе перечисленl= 5;ых планов или автономно может быть полезной разработка ряда вспомо = 75;ательных планов (см. рис. 7.1):<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1087;лана подготовки = 80; обучения пользоватеl= 3;ей для квалифицирl= 6;ванной эксплуатацl= 0;и версий ПС;<o:p></o:p></span= > <![if !supportLis= ts]>- &nb= sp; <![endif]>п = 83;ана обслуживанl= 0;я пользоватеl= 3;ей в процессе эксплуатацl= 0;и ПС;<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1087;лана организациl= 0; переноса и установки в = 77;рсий ПС на различ= 085;ые аппаратные = 80; операционнm= 9;е платформы пользоватеl= 3;ей.<o:p></o:p> Все перечисленl= 5;ые планы должн = 99; иметь в свое= 084; составе предваритеl= 3;ьные графики, идентифициl= 8;ующие: этапы работ; входные, выходные данные и опи= 089;ания решаемых задач; необходимыk= 7; ресурсы, дли= 090;ельность и сроки выполнения; взаимосвязl= 0; этапов и работ. Должн= 086; быть устано = 74;лено организациl= 6;нно-техниче&#= 1089;кое взаимодейсm= 0;вие между различными группами специалистl= 6;в, которые вносят свой вклад в процессы и обеспечениk= 7; качества ЖЦ = 055;С, а необходим = 72;я информация должна документирl= 6;ваться и регулярно анализировk= 2;ться. В планах работ поставщикоk= 4; и субподряд = 95;иков при проектировk= 2;нии следует четко опред = 77;лить границы ответственl= 5;ости за каждую часть программноk= 5;о средства и з= 072; способ обмена техническоl= 1; информациеl= 1; между всеми сторонами п = 88;оекта. При установ = 83;ении этого взаимодейсm= 0;вия следует обратить внимание на вспомогатеl= 3;ьных специалистl= 6;в, помимо потребителn= 3; и поставщик = 72;, которым необходимы входные данные для проектировk= 2;ния, установки, обслуживанl= 0;я и подготовк = 80; программ и д= 072;нных. <o:p></o:p> Анализ состояния и результатоk= 4; проекта следует официально планироватn= 0; и регулярно проводить н = 72; соответствm= 1;ющих этапах ЖЦ ПС. В состав уча= 089;тников каждого ана = 83;иза должны включаться представитk= 7;ли всех служб, заинтересоk= 4;анных в результатаm= 3; анализируе&#= 1084;ого этапа проек = 90;ирования. Степень формальносm= 0;и и жесткости действий по осуществлеl= 5;ию анализа должна соответствl= 6;вать сложности П = 57; и степени риска, связа= 085;ного с областью применения = 80; использоваl= 5;ием программноk= 5;о средства. В процедуры а = 85;ализа проекта могут входить действия, ко= 090;орые необходимо предпринятn= 0; до и во время его проведения, включая используемm= 9;е методики и руководящиk= 7; указания дл= 03; всех участн = 80;ков проверок. Если оговор = 77;но в контракте, поставщик должен проводить совещания п = 86; анализу результатоk= 4; и состояния проекта вместе с зак= 072;зчиком. Обе стороны должны согл = 72;совать результаты подобных анализов. Пр= 086;верку проекта на соответствm= 1;ющих этапах ЖЦ ПС надо проводить, чтобы удост = 86;вериться, что выходны = 77; данные на этих этапах соответствm= 1;ют входным требованияl= 4;. <o:p></o:p> В проверку проекта могут входи = 90;ь: анализ выходных проектных данных; демон= ;страции прототипов = 80; моделей, а также резул= 00;татов их тестиров = 72;ния. Эти проверк = 80; следует проводить согласно документирl= 6;ванным процедурам = 80; планам. Пере= 076; тем, как пред&#= 1083;ожить продукт потребителn= 2; на испытани= 03; и приемку, по&#= 1089;тавщик должен оценить его качество со = 75;ласно назначению = 80; спецификацl= 0;ям требований, например, на этапе окончательl= 5;ого внутреннегl= 6; контроля и испытаний р = 72;зработчико&#= 1084;. При разработке программноk= 5;о средства важно, чтобы результаты оценки и люб= 099;е последующиk= 7; действия, необходимыk= 7; для выполне = 85;ия заданных тр = 77;бований, были зафиксировk= 2;ны и проверены = 087;о завершении этих работ. <o:p></o:= p> <o:p></o:p> <h1><a name=3D"_Toc508102474"></a><a name=3D"_Toc508102247">7.3. Планированl= 0;е процессов управления качеством сложных пр = 86;граммных средств</a></h1> <o:p> </o:p> При проектировk= 2;нии ПС, планированl= 0;е процессов управления качес= ;твом ПС целесооб = 88;азно отделять от непосредстk= 4;енного планированl= 0;я и управлени= 03; процессами создания и совершенстk= 4;ования крупных комплексов программ. Эт= 086; позволяет сосредоточl= 0;ть внимание выделенных специалистl= 6;в на совокупн = 86;сти мероприятиl= 1;, гарантируюm= 7;их качество конечного продукта. Чтобы такие гарантии достигалисn= 0; при минимальныm= 3; затратах, необходимы целенаправl= 3;енное, координируk= 7;мое планированl= 0;е и управлени = 77; для предотвращk= 7;ния ошибок проектировk= 2;ния, а также для в&#= 1099;явления и устранени= 03; дефектов проекта на самых ранни = 93; этапах разработки. Поэтому мероприятиn= 3; планированl= 0;я, обеспечиваn= 2;щие качество пр = 86;грамм, должны охва = 90;ывать не только завершающиk= 7; испытания, н= 086; и весь жизне= 085;ный цикл ПС. <o:p></o:p> Соответ= ;ственно должны выделяться = 80; применятьсn= 3; методы и сре= 076;ства автоматизаm= 4;ии процессов планированl= 0;я и управлени= 03; качеством п = 86; этапам разр = 72;ботки компонентоk= 4; и ПС в условиях реальных ограниченнm= 9;х ресурсов. Следует учи = 90;ывать глубокую взаимосвязn= 0; плана управ = 83;ения и применени= 03; процедур обеспечениn= 3; качества ПС = 089; планом управления непосредстk= 4;енной разработкоl= 1; программ, с процессами тестированl= 0;я, испытаний и сертификацl= 0;и ПС. Эта связь выражается = 74; аналогичноl= 4; поэтапном представлеl= 5;ии планов и в наличии в ни= 093; значительнl= 6;й части близких по содержанию = 87;роцессов и документо = 74;. При планированl= 0;и процессов обеспечениn= 3; качества ПС, целесообраk= 9;но учитывать и использоваm= 0;ь совокупносm= 0;ь рекомендацl= 0;й ряда станда = 88;тов, в которые входят – ISO 10005, ISO 10006, ISO 10013, поддерживk= 2;ющие базовые стандарты м = 77;неджмента качества серии ISO 9000 (см. ле= ;кцию 3). <o:p></o:p> В соответствl= 0;и со стандартамl= 0; процедуры у = 87;равления качеством должны прим = 77;няться к различным документам = 80; данным, вклю= 095;ая: контрактныk= 7; документы; процедурныk= 7; документы, описывающиk= 7; процессы системы качества; состояние работ поставщика- = 88;азработчик&#= 1072;; взаимодейсm= 0;вие поставщика = 80; заказчика; д= 086;кументы и данные, которые опи = 89;ывают конкретный программныl= 1; продукт. В составе документов должны соде = 88;жаться методики, инструкции = 80; описания по = 080;спользован&= #1080;ю конкретных инструментk= 2;льных средств и выполнению частных работ и опер= 072;ций в ЖЦ ПС. Для этого в обще= 084; случае долж = 85;ы быть выделены ру = 82;оводители и коллектив специалистl= 6;в, которые должны план = 80;ровать, создавать, утверждать = 80; сопровождаm= 0;ь комплекты документов. Они должны с= 090;имулирова= 090;ь разработчиl= 2;ов ПС осуществляm= 0;ь непрерывно= е, регламентиl= 8;ованное документирl= 6;вание процессов и результатоk= 4; своей деяте = 83;ьности, а также конт= 088;олировать полноту и качество результируn= 2;щих и отчетных д= 086;кументов. Стандарты и базовые нормативныk= 7; документы Ж = 62; ПС должны служить вер = 93;ним уровнем иерархичесl= 2;ой системы технологичk= 7;ских документов, регламентиl= 8;ующих и конкретизиl= 8;ующих все этапы, работы и до= 082;ументы проекта.<o:p></o:p>= Организ= ;ационной основой управления качеством П = 57; на базе стан= 076;артов ЖЦ является план обеспечениn= 3; заданных характерисm= 0;ик качества на всех этапах жизненного цикла компл = 77;кса программ (см. лекцию 11). Для этого до начала разработки = 74; процессе формированl= 0;я требований техническоk= 5;о задания следует сформулироk= 4;ать основные положения методики обеспечениn= 3; качества, по= 101;тапных испытаний компонентоk= 4; и определен = 80;я достигнутыm= 3; значений характерисm= 0;ик, допустимых для продолж = 77;ния работ на следующих этапах. Тако= 081; план целесообраk= 9;но создавать для сложных проектов ПС на этапах системного анализа, раз= 088;аботки требований техническоk= 5;о задания и проектировk= 2;ния. На этих этап= 072;х оформляютсn= 3; первичные требования = 82; характерисm= 0;икам и качеству П= 057; и, соответстk= 4;енно, должна планироваm= 0;ься совокупносm= 0;ь мероприятиl= 1;, обеспечиваn= 2;щих их достижение = 74; процессе последующеk= 5;о проектировk= 2;ния. В плане упра= 074;ления качеством П = 57; должны быть отражены:<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>ц = 77;ли управления качеством, номенклатуl= 8;а и требовани= 03; к значениям = 093;арактерист&= #1080;к качества, область действия требований = 80; условия их применения;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1084;етоды управления = 80; достижения заданных зн = 72;чений качества; процедуры, к= 086;торые должны выполнятьсn= 3; для каждого процесса и н= 072; протяжении всего жизненного цикла ПС; действия, связанные с = 086;тчетностью об ошибках, с трассировкl= 6;й и системой к= 086;рректирующ&= #1080;х действий;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>о = 88;ганизация разработчиl= 2;ов и технологи= 03; создания ПС; утвержде= 085;ные обязанностl= 0; специалистl= 6;в по обеспечениn= 2; качества, их ответственl= 5;ость и полномочи= 03; на утвержде = 85;ие программныm= 3; компонентоk= 4; и документо = 74;;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>р = 77;сурсы, базовые документы и стандарты, и= 089;пользуемые для обеспеч = 77;ния качества на всех этапах разработки;<o:p= ></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>с = 88;едства автоматизаm= 4;ии разработки, обеспечиваn= 2;щие достижение = 80; измерение заданных свойств и значений характерисm= 0;ик качества;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>структура = 80; содержание отчетных документов, удостоверяn= 2;щих достижение определеннl= 6;го качества ко = 84;понентов и ПС в целом на последов = 72;тельных этапах разр = 72;ботки, а также их соответствl= 0;е стандартам = 80; требованияl= 4; заказчика.<o:p></o:p>= Реальные ограничениn= 3; ресурсов, используемm= 9;х в процессе разработки, квалификац= ия специалистl= 6;в, изменения внешней сре = 76;ы и требовани = 81; заказчика объективно приводят к отклоненияl= 4; процессов и реализации плана от</spa= n> предполагаk= 4;шегося. Величина таких откло = 85;ений в значитель = 85;ой степени зависит от принятой технологии разработки, от уровня и характерис= тик средств автоматизаm= 4;ии создания программ. Дл= 103; своевременl= 5;ого обнаружениn= 3; отклонений от плана нео= 073;ходимо регулярно регистрироk= 4;ать результаты выполненныm= 3; работ и их качество. Дл= 103; реализации = 90;аких изменений целесообраk= 9;но предусмотрk= 7;ть и согласова = 90;ь с заказчико = 84; специальны= й документ, ре= 075;ламентирую&= #1097;ий правила корректироk= 4;ки плана обеспечениn= 3; качества ПС, а также состав и содержание поддержива= ющей его документацl= 0;и. Подобные изменения должны оформлятьсn= 3; протоколамl= 0; и доводитьс= 03; до сведения всех специалистl= 6;в, к которым они относят = 89;я.<o:p></o:p> Одна из трудностей достижения высокого ка = 95;ества ПС состоит обычно в отсутствии полной совокупносm= 0;и достоверныm= 3; требований = 82; значениям характерисm= 0;ик качества на начальных этапах проектировk= 2;ния и разработк = 80;, а также итерационнm= 9;й процесс их конкретизаm= 4;ии в течение всего жизненного цикла ПС. В ре&= #1079;ультате первично сформулироk= 4;анные требования = 82; характерисm= 0;икам качества сложных ПС, последоватk= 7;льно уточняются = 80; корректируn= 2;тся в процессе взаимодейсm= 0;вия заказчика и разработчиl= 2;а с учетом объективно изменяющихl= 9;я особенностk= 7;й развивающеk= 5;ося проекта ПС. Для этого необходимо контролироk= 4;ать требуемые характерисm= 0;ики в процессе разработки, анализировk= 2;ть их адекватносm= 0;ь целям проекта и уп= 088;авлять их изменениямl= 0; в нужном направлениl= 0;. Активное вз = 72;имодействи&#= 1077; разработчиl= 2;ов с заказчико = 84; или потенци = 72;льными пользоватеl= 3;ями на всех этапах разработки = 87;озволяет уточнять, корректироk= 4;ать и детализир = 86;вать совокупносm= 0;ь спецификацl= 0;й требований = 80; атрибуты ка = 95;ества в соответствl= 0;и с развитием концепции и возрастаниk= 7;м понимания з = 72;дач проекта, как заказчиком, так и разраб= 086;тчиком.<o:p></o:p> Управлениk= 7; качеством комплексов программ предполагаk= 7;т формализацl= 0;ю технологии обеспечениn= 3; их жизненного цикла, а также выдел = 77;ние в специальн = 99;й процесс поэ = 90;апное измерение и анализ теку = 97;его качества программныm= 3; компонентоk= 4; и проекта в ц&#= 1077;лом. В общем случае в процессе планированl= 0;я и управлениn= 3; качеством П = 57; следует учи = 90;ывать:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 85;ализ контракта и спецификацl= 0;й требований заказчика к ПС, выделени= 077; и ранжирова = 85;ие приоритетоk= 4; характерисm= 0;ик и атрибутов качества ко = 85;ечного продукта;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>д = 77;композицию требований = 82; характерисm= 0;икам качества по контролируk= 7;мым этапам и компонентаl= 4; разработки = 80; создание разделов по детальным требованияl= 4; к атрибутам качества в спецификацl= 0;ях на программ = 85;ые компоненты = 80; ПС в целом;<o:p></o:p></spa= n> <![if !supportLists]>- &nb= sp; <![endif]>в = 99;бор или создани = 77; методов, технологии = 80; инструментk= 2;льных средств автоматизаm= 4;ии разработки, = 086;беспечиваю&= #1097;их создание ПС = 080; его компоне = 85;тов с требуемым = 80; характерисm= 0;иками качества;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>р = 72;зработку методик контроля соблюдения = 89;тандартов, правил= технологиl= 0; проектировk= 2;ния и системы обеспечениn= 3; качества жизненного цикла прогр = 72;ммных средств;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здание методов, методик и средств объективноk= 5;о измерения свойств и/ил= 080; значений атрибутов характерисm= 0;ик качества пр = 86;граммных компонентоk= 4; на этапах их создания и всего ЖЦ ПС для испытаний заказчиком = 80; эксплуатацl= 0;и пользоватеl= 3;ями;<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1086;рганизацию, обучение и стимулировk= 2;ние коллектива специалистl= 6;в на создание компонентоk= 4; и ПС в целом, в максимальнl= 6;й степени удо = 74;летворяющи&#= 1093; требования заказчиков = 80; пользоватеl= 3;ей к характери = 89;тикам качества.<o:p></o:p>= Чтобы решать эти задачи, коллективы специалистl= 6;в в процессе п= 083;анирования проекта, должны игр = 72;ть активную роль и осуществляm= 0;ь их выполнен = 80;е для обеспечениn= 3; качества на последующиm= 3; этапах жизненного цикла. Они должны действоватn= 0; в соответствl= 0;и с полномочияl= 4;и, ответственl= 5;остью и независимоl= 9;тью, чтобы гаран = 90;ировать удовлетворk= 7;ние целей и требований = 82; качеству ПС. Качество объектов формируетсn= 3; и документи = 88;уется при выполнении частных работ каждого эта = 87;а ЖЦ и окончат= 077;льно удостоверяk= 7;тся при их завер= 096;ении. Измерения объектов разработки = 89;водятся к регулярно = 81;, поэтапной регистрациl= 0; и документи= ;рованию характерныm= 3; для данного объекта показателеl= 1; качества, а также к сопо= 089;тавлению их с заданными требованияl= 4;и. <o:p></o:p> В стандарте ISO<= span style=3D'font-size:14.0pt'> 15504 (раздеl= 3; MAN<= span style=3D'font-size:14.0pt'>.3) процес&#= 1089; планированl= 0;я и управлени= 03; качеством П = 57; концентрирm= 1;ется на мониторингk= 7; качества продуктов и процессов, как проекта, так и предприятиn= 3; в целом. В рез&= #1091;льтате успешной реализации процессов в = 087;роекте должно быть обеспечено: <o:= p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>на основе явны = 93; и неявных требований потребителn= 3; необходимо определить цели по качеству продукта и п= 088;оцессов, которые следует оценивать, п= 088;едпочтител&= #1100;но количествеl= 5;ным образом, для различных к = 86;нтрольных точек в жизненном цикле ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>о = 87;ределить общую стратегию н = 72; уровне прое = 82;та ПС и предпри= 103;тия, помогающие аттестоватn= 0; достижение соответствm= 1;ющих целей по качеству, оп= 088;еделяя количествеl= 5;ную меру резуль = 90;атов деятельносm= 0;и по проекту и критерии их приемки; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>д = 83;я каждой цели по качеству ПС идентифициl= 8;овать виды деятел= 00;ности по контролю = 080; обеспечениn= 2; качества, помогающие = 76;остижению этой цели и её мониторингm= 1;, как на уровн= 077; проекта, так и на уровне предприятиn= 3;, и интегрировk= 2;ть эти виды деятельносm= 0;и в жизненный цикл ПС; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>п = 88;оводить идентифициl= 8;ованные виды деятел= 00;ности по контролю = 080; обеспечениn= 2; качества и подтверждаm= 0;ь их выполнен = 80;е;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>п = 86; ходу реализации проекта в контрольныm= 3; точках жизн = 77;нного цикла ПС применять заданные метрики качества дл= 03; аттестации достижения соответствm= 1;ющих целей по кач= 077;ству;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>в случаях, когда заданные цели по качеству не достигаютсn= 3;, применять корректируn= 2;щие или предотвращk= 2;ющие мероприятиn= 3;, которые могут включ = 72;ть либо исправ = 83;ение продукта, ли= 073;о изменение запланировk= 2;нного набора видо = 74; деятельносm= 0;и для лучшего достижения целей по кач= 077;ству, либо изменение с = 87;ецификации требований продукта ил = 80; определениn= 3; процесса дл= 03; предотвращk= 7;ния повторения дефектов.<o:p></o:p>= Утве= ;рждение и выпуск документацl= 0;и о качестве должны планироватn= 0;ся и контролир = 86;ваться уполномочеl= 5;ным персоналом на предмет и= 093; адекватносm= 0;и. Следует планироватn= 0; и поддерживаm= 0;ь в актуально = 84; состоянии процедуры управления документамl= 0;, которые иде = 85;тифицируют текущий статус корректироk= 4;ки и пересмотр = 72; документов, с тем, чтобы предотвратl= 0;ть использоваl= 5;ие недействуюm= 7;их и/или устаре= 074;ших документов:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 72;личие актуальных изданий соответствm= 1;ющих документов на всех участках, гд= 077; проводятся работы, от которых зависит эффективноk= 7; функционирl= 6;вание системы кач = 77;ства;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77;медленное изъятие недействуюm= 7;их и/или устаре= 074;ших документов из всех пунктов их рассылки ил = 80; применения, либо принятие др = 91;гих мер по предотвращk= 7;нию их непреднамеl= 8;енного использоваl= 5;ия;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 76;ентификаци&#= 1102; любых устаревших документов, составленнm= 9;х для юридиче = 89;ких целей и/или для сохранения полезной ин = 92;ормации.<o:p></o:p> Изменен= ;ия документов должны планироватn= 0;ся и утверждатьl= 9;я теми же службами и/или органи= 079;ациями, которые проводили первоначалn= 0;ный анализ и утверждали эту докумен = 90;ацию. Архивные данные по проекту явл= 03;ются основным источником для анализа = 080; осмысления возможностk= 7;й и эффективноl= 9;ти процесса планированl= 0;я в организациl= 0;, рабочих характерисm= 0;ик данного проекта и обобщения полученногl= 6; опыта. Эти архивные да = 85;ные, образующие общую базу данных предприятиn= 3;, следует постоянно и = 89;пользовать для усовершенсm= 0;вования процессов ж = 80;зненного цикла ПС. Та же самая баз= 072; данных долж = 85;а обеспечиваm= 0;ь реализацию процесса управления по отдельны = 84; программныl= 4; проектам. <o:p></o:p></span= > <o:p> </o:p> <h1><a name=3D"_Toc508102475"></a><a name=3D"_Toc508102248">Лекция 8. Объектно-ор = 80;ентированн&#= 1086;е проектировk= 2;ние программныm= 3; средств</a></h1> <o:p> </o:p> <h1><a name=3D"_Toc508102476"></a><a name=3D"_Toc508102249">8.1. Задачи и особенностl= 0; объектно-ор = 80;ентированн&#= 1086;го = &nb= sp; проектироk= 4;ания программнm= 9;х средств</a></h1> <o:p> </o:p> Междунароk= 6;ные стандарты программноl= 1; инженерии (Прилl= 6;жение 1), регламенти&= #1088;уют жизненный цикл программныm= 3; средств широкого класса в раз= 083;ичных областях их применения. Они ориентировk= 2;ны в основном н= 072; структурноk= 7; проектировk= 2;ние и разработк = 91; процессов, функций и данных в различных к = 86;мплексах программ, в которых дом = 80;нируют сложные алгоритмы обработки, относительl= 5;о небольшой совокупносm= 0;и данных. Объектно-о = 88;иентирован&#= 1085;ое проектировk= 2;ние (ООП) предназначk= 7;но организовm= 9;вать программныk= 7; системы с большими базами данных на основе опис = 72;ний объектов реального мира, важных для пользоватеl= 3;ей. Этот подход существеннl= 6; отличается от структурноk= 5;о проектировk= 2;ния, которое акцентировk= 2;но на сложные функции и процессы обработки д = 72;нных. Объекты реального мира, существующl= 0;е внутри области дей = 89;твия ООП програм = 84;ных проектов, определяютl= 9;я в терминах целей, характерисm= 0;ик и ответстве = 85;ностей поведения соответствm= 1;ющих данных (атри= 073;утов) и отношений = 089; другими многочислеl= 5;ными объектами. Все функции при этом скрыты внутри дета = 83;ей описаний об = 98;екта. <o:p></o:p> Объектно-о = 88;иентирован&#= 1085;ое проектировk= 2;ние представляk= 7;т собой страт = 77;гию, в рамках которой программнаn= 3; система состоит из взаимодейсm= 0;вующих объектов, имеющих собственноk= 7; локальное состояние и спосо= ;бных выполнять определеннm= 9;й набор опера = 94;ий, определяемm= 9;й состоянием объекта. Объекты скрывают информацию = 86; представлеl= 5;ии состояний и, следователn= 0;но, ограничиваn= 2;т к ним доступ. Под процессом ООП подразу = 84;евается проектировk= 2;ние классов объектов и в= 079;аимоотноше&= #1085;ий между этими классами. Об= 098;ектно-ориен= тированные системы можно рассм = 72;тривать как совокупносm= 0;ь автономных = 80; в определен = 85;ой степени независимыm= 3; объектов. Из= 084;енение реализации какого-нибу = 76;ь объекта или добавление новых функций не влияет на другие объекты сис = 90;емы. <o:p></o:p> Общий процесс объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния состоит из нескольких крупных эта = 87;ов:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- </spa= n><![endif]>определ= ;ение рабочего окружения системы и разработка моделей её и= 089;пользовани&= #1103;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>проекти= ;рование архитектурm= 9; программноl= 1; системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>определ= ;ение и идентификаm= 4;ия основных об = 98;ектов системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>разрабо= ;тка модели архитектурm= 9; комплекса программ;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>определ= ;ение и документирl= 6;вание интерфейсоk= 4; объектов.<o:p></o:p>= Проце= сс ООП нельзя представитn= 0; в виде прост= 086;й схемы (как при структу = 88;ном проектировk= 2;нии), в которой предполагаk= 7;тся четкая последоватk= 7;льность этапов. Фактически все перечисленl= 5;ые этапы в знач= 080;тельной мере можно выполнять параллельнl= 6;, с учетом вза= 080;много влияния дру = 75; на друга. Как только разработанk= 2; архитектурk= 2; системы, опр= 077;деляются объекты и интерфейсы. После создания моделей объ = 77;ктов отдельные объекты можно переопредеl= 3;ить, а это может привести к изменениям = 74; архитектурk= 7; системы. <o:p></o:p> Главное преимущестk= 4;о ООП програм = 84;ных средств состоит в том, что оно упрощает задачу внес = 77;ния изменений в системную архитектурm= 1;, поскольку представлеl= 5;ие состояния объекта не оказывает н = 72; нее влияния.<sp= an style=3D'mso-spacerun:yes'> Изменение внутренних данных объе = 82;та не должно влиять на другие объе = 82;ты системы. Более того, так как объекты сла = 73;о связаны между собой, обычно новы = 77; объекты просто вставляютсn= 3; без значите = 83;ьных воздействиl= 1; на остальны = 77; компоненты = 89;истемы. <o:p></o:p> Основ= ные понятия ООП включают: <o:p></o:p></span= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 88;и объектно-ор = 80;ентированн&#= 1086;м проектировk= 2;нии основные компоненты программноl= 1; системы представляn= 2;тся как объекты со своими состояниямl= 0; и операциям = 80;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 73;ъекты предоставлn= 3;ют сервисы (методы) друг&#= 1080;м объектам и создаются в = 088;еальном времени на основе определениn= 3; класса объектов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 73;ъекты могут быть реализованm= 9; последоватk= 7;льно и параллель = 85;о, параллельнm= 9;й объект може = 90; быть пассивным, у которого состояние изменяется только чере = 79; его интерфе = 81;с, или активны = 84;, который может измен= 03;ть свое состояние без вмешательсm= 0;ва извне;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в процессе объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния возможно создание ряда различных моделей, кот= 086;рые можно разделить н = 72; статическиk= 7; (модели классов, мод= 077;ли обобщения, модели агре = 75;ирования) и динамическl= 0;е (модели последоватk= 7;льностей, модели конечного автомата); - важным преимущестk= 4;ом объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния является то, что он упрощает процесс мод = 80;фикации системы.<o:p></o:p> &n= bsp; Одна часть общей системы занимается сбором данных, другая обобщает данные, полу= 095;енные из различны = 93; источников, третья выполняет архивироваl= 5;ие данных и = 85;аконец четвертая создает результаты. Система представляk= 7;т собой многоуровнk= 7;вую архитектурm= 1;, в которой отражены вс = 77; этапы обработки данных в сис= 090;еме, сбор и обобщение данных, архи= 074;ирование данных и создание результатоk= 4;. Такая многоуровнk= 7;вая архитектурk= 2; вполне годится для проектировk= 2;ния, так как каждый этап основываетl= 9;я только на обработке д = 72;нных, выполненноl= 1; на предыдущем этапе.<o:p></o:p> Использовk= 2;ние методов ООП строго регламентиl= 8;овано, поэтому:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зрастает производитk= 7;льность труда разра = 73;отчиков благодаря переходу к в= 099;сокоэффект&= #1080;вному методу -</span= > на базе предваритеl= 3;ьного анализа про = 77;кта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>з = 72;просы и объекты реального мира проще моделируютl= 9;я путем конце = 85;трации внимания на классах, а не на алгоритм = 72;х их функционирl= 6;вания;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>к = 86;мпоненты системы легко изменяются = 80; применяютсn= 3; повторно;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>т = 88;ебования проще отслеживаюm= 0;ся;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддерживает&#= 1089;я эффектив= ;ное прототиl= 7;ирование;<o:p></o:= p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>р = 72;зработка проекта отличается непрерывноl= 9;тью в представл = 77;нии объектов = - одни и т= 077; же типы диаграмм применяютсn= 3; как при анализе, так и на этапе разработки;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>р = 72;бота по проектировk= 2;нию может осуществляm= 0;ься с помощью универсальl= 5;ых технологичk= 7;ских инструментl= 6;в.<o:p></o:p> ООП = = - только часть объектно-ор= иентированl= 5;ого процесса ра = 79;работки системы, гд= 077; на протяжении всего процесса создания ПС используетl= 9;я объектно-ор = 80;ентированн&#= 1099;й метод. Этот подход подразумевk= 2;ет выполнение трех этапов:<o:= p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l80 level1 lfo138;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>объектно-о= 088;иентирован&= #1085;ый анализ <span style=3D'font-size:= 14.0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";mso-char-type:symbol;mso-symbol-font-family:Symbol; mso-bidi-font-style:italic'>- созда= ние модели пред = 84;етной области приложения ПС, где объекты отр = 72;жают реальные объекты-сущ = 85;ости, а также определяютl= 9;я операции, выполняемыk= 7; объектами;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l80 level1 lfo138;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>объектно-о= 088;иентирован&= #1085;ое проектироk= 4;ание <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > разработка модел= ;и системы ПС и системной архитектурm= 9; с учетом системных т = 88;ебований, в которой определениk= 7; всех объектов по = 76;чинено решению конкретной задачи;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l80 level1 lfo138;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>объектно-о= 088;иентирован&= #1085;ое программирl= 6;вание <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > реализац= ;ия архитектурm= 9; (модели) системы с помощью объектно-ор = 80;ентированн&#= 1086;го языка прогр = 72;ммирования<s= pan style=3D'mso-spacerun:yes'> (напрl= 0;мер, Java), непосредсm= 0;венно выполняющеk= 5;о отражение определеннm= 9;х объектов и п= 088;едоставляю&= #1097;его средства дл= 03; определениn= 3; классов объ = 77;ктов.<o:p></o:p> Этапы могу = 90; "перетекать= ;" друг в друга, т.е. могут не иметь четки = 93; рамок, приче= 084; на каждом этапе обычн = 86; применяетсn= 3; одна и та же с&= #1080;стема нотации. Переход на следующий этап приводит к усовершенсm= 0;вованию и конкретизаm= 4;ии результатоk= 4; предыдущегl= 6; этапа путем более детал= 00;ного описания определеннm= 9;х ранее класс = 86;в объектов и определениn= 3; новых классов. Так как данные скрыты внутри объектов, детальные решения о содержании данных можн = 86; отложить до этапа реализации системы. В не&#= 1082;оторых случаях можно также не спешить с принятием решений о расположенl= 0;и объектов и о том, будут ли эти объекты последоватk= 7;льными или параллельнm= 9;ми. Если необхо = 76;имы функционалn= 0;ные изменения, они произво = 76;ятся внутри объе = 82;та, что приводи = 90; к незначителn= 0;ным изменениям = 74; оставшейся внешней части его процессов. Для обновления или добавления функций, оставшиеся объекты, под= 076;ерживаются с помощью интерфейсоk= 4;. Объектно-ор = 80;ентированн&#= 1086;е проектировk= 2;ние отображает предметную = 86;бласть задачи и ответственl= 5;ости системы, но задерживаеm= 0; определениk= 7; подробностk= 7;й реализации объектов, переносит и = 93; на более поздний эта = 87; разработки = 80; минимизируk= 7;т влияние изменений в функционалn= 0;ных требованияm= 3;.<o:p></o:p> Пр&#= 1080; ООП основно = 77; внимание уделяется тому, &#= 1095;то следует де = 83;ать, каки = 84; образом до = 73;иться цели, а процесс её достижения целиком зависит от этапа разра = 73;отки. Объектная декомпозицl= 0;я дает возмож = 85;ость создавать программныk= 7; комплексы в = 80;зуально меньшего размера путем испол= 00;зования общих механизмов, обеспечиваn= 2;щих необходимуn= 2; экономию выразительl= 5;ых средств. Использоваl= 5;ие объектного подхода повышает уровень уни = 92;икации разработки = 80; пригодностn= 0; для повторн = 86;го использоваl= 5;ия не только программныm= 3; компонентоk= 4;, но и больших комплексов программ, чт= 086; ведет к созданию унифицировk= 2;нной среды разра = 73;отки и переходу к сборочному созданию пр = 86;граммных продуктов. Системы зачастую по = 83;учаются более компактнымl= 0;, чем их структурныk= 7; эквивалентm= 9;, что означае = 90; не только уменьшение объема программноk= 5;о кода, но и удешевлениk= 7; проекта за счет исполь = 79;ования компонентоk= 4; из предыдущих разработок. Однако, структурнm= 9;й подход сохраняет свою высоку= 02; значимость = 80; широко используетl= 9;я на практике. Взаимосвязn= 0;ю между с&= #1090;руктурным и объектно-о= 088;иентирован&= #1085;ым подходами является общность ря = 76;а категорий и понятий жизненногl= 6; цикла ПС.<o:p></o:p> Объектная декомпозицl= 0;я существеннl= 6; отличается от функцl= 0;ональной, поэтому переход на новую технологию связан как с преодолениk= 7;м психологичk= 7;ских трудностей, так и с дополнителn= 0;ными финансовымl= 0; затратами. Кроме того, диаграммы, о= 090;ражающие специфику о = 73;ъектного подхода, гораздо менее нагля = 76;ны и хуже понимаемы непрофессиl= 6;налами, объектно-ор = 80;ентированн&#= 1099;й подход обыч = 85;о не дает немедленноl= 1; отдачи. Эффект от ег= 086; применения начинает сказыватьсn= 3; после разработки = 85;ескольких проектов и накопления повторно ис = 87;ользуемых компонентоk= 4;, отражающих типовые проектные решения в данной области. <o:p></o:p> В программныm= 3; средствах при ООП реко= 084;ендуется выделять тр = 80; уро-вн= 03;:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l225 level1 lfo130;tab-stops:14.2pt list 48.75= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>уровень интерфейсоk= 4;, который занимается = 74;семи взаимодейсm= 0;виями с другими ча= 089;тями системы и предоставлk= 7;нием внешних инт = 77;рфейсов системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l225 level1 lfo130;tab-stops:14.2pt list 48.75= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>уровень сбора данны = 93;, управляющиl= 1; сбором инфо = 88;мации из внешней среды и обобщающий = 76;анные перед отправкой и = 93; в систему по= 089;троения обобщенных результатоk= 4;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l225 level1 lfo130;tab-stops:14.2pt list 48.75= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>уровень объектов, в котором представлеl= 5;ы и описаны вс= 077; объекты, используемm= 9;е в процессе сбора исход = 85;ых данных.<o:p></o:p> В общем случа = 77; рекомендуеm= 0;ся структурирl= 6;вать систему на части так, чтобы архит = 77;ктура была как можно проще. Согласно хо = 88;ошему практическl= 6;му правилу, модель архи = 90;ектуры должна состоять не более чем из семи-восьми основных объектов. Перед выпол = 85;ением проектировk= 2;ния должны быть сформироваl= 5;ы представлеl= 5;ия относительl= 5;о основных об = 98;ектов проектируеl= 4;ой системы. Вместе с тем &#= 1090;ребуется определить = 80; документирl= 6;вать все другие внешние объекты системы. Опред= ;еления объе = 82;тов на данном этапе проек = 90;ирования отражает класс= 099; объектов</spa= n> и структура системы описываетсn= 3; в терминах этих классо = 74;. Классы объектов, определеннm= 9;е ранее, получают более детальное о = 87;исание, поэтому иногда прих = 86;дится возвращатьl= 9;я на данный этап проект = 80;рования для переопредеl= 3;ения классов. Первый этап = 074; любом процессе пр = 86;ектировани&#= 1103; состоит в выявлении взаимоотноm= 6;ений между проектируеl= 4;ым ПС и его окру&#= 1078;ением. Выявление этих взаимоотноm= 6;ений помогает решать, как обеспечить необходимуn= 2; функционалn= 0;ность системы и ка= 082; структурирl= 6;вать систему, чтобы она могла эффек = 90;ивно взаимодейсm= 0;вовать со своим окр= 091;жением.<o:p></o:p> Язык UML представляk= 7;т набор разработанl= 5;ых инженерных = 79;адач практическl= 6;го профиля, которые успешно исп = 99;таны при моделироваl= 5;ии крупных и сложных систем. Подде= ;рживается метамодель для диаграм = 84; классов и набор семантичесl= 2;их и синтаксич = 77;ских правил, опре= 076;еляющих суть элементов и их отношени = 81;. Модель поддерживаk= 7;тся большим количествоl= 4; автоматизиl= 8;ованных инструментl= 6;в. Основные цели исполь = 79;ования языка UML на этапе разработки проекта ПС:<o:p></o:p= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка на уровне пользоватеl= 3;ей готового к применению, выразительl= 5;ого визуальногl= 6; языка моделироваl= 5;ия, применяемоk= 5;о для разрабо = 90;ки и обмена моделями;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка спецификацl= 0;й, независимыm= 3; от определеннm= 9;х языков прог = 88;аммировани&#= 1103; и процессов разработки;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка формальногl= 6; базиса для представлеl= 5;ия языка модел = 80;рования;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка высокоуровl= 5;евых понятий, так= 080;х как компоненты, элементы со = 90;рудничеств&#= 1072;, каркасы и шаблоны;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>и = 85;теграция наилучшего опыта.<o:p></o:p> &n= bsp; Разработчl= 0;ки UML установили, что даже при использоваl= 5;ии современныm= 3; передовых технологий, при сборе требований, анализе и разработке продолжаетl= 9;я борьба с не адекватнымl= 0; и постоянно = 080;зменяющими&= #1089;я требованияl= 4;и заказчиков (см. лекцию 6). В = 72;рианты использоваl= 5;ия предназначk= 7;ны для уточнения д = 80;намически требований = 80; выработки более четко = 75;о представлеl= 5;ия возможных изменений в = 087;оведении системы. Они позволяют реализоватn= 0; функционалn= 0;ные усовершенсm= 0;вования, которые отражаются = 80; адресуются = 74; организоваl= 5;ной форме. Класс= 099; и объекты языка UML демонстрирm= 1;ют гибкость и управляемоl= 9;ть при использ = 86;вании статично и динамично несовершенl= 5;ых описаний. Дл= 103; оживления общения в команде специалистl= 6;в ООП позволя = 77;т реализоватn= 0; в группе программисm= 0;ов интегрировk= 2;нный подход с помощью общего словаря и языка; инкап= 089;уляция данных и алг= 086;ритмов позволяет членам команды работать на = 76; компонентаl= 4;и в параллельнl= 6;м режиме. Такж= 077; в этом случа= 077; можно ограничить влияние изменчивосm= 0;и требований; наследствеl= 5;ные свойства функций и ат= 088;ибутов являются эффективныl= 4; дополнениеl= 4; к функциона = 83;ьным возможностn= 3;м.<o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102477"></a><a name=3D"_Toc508102250">8.2. Основные понятия и модели объектно-ор = 80;ентированн&#= 1086;го = &nb= sp; проектироk= 4;ания программныm= 3; средств</a></h1> <o:p> </o:p> Класс представляk= 7;т собой абстр = 72;кцию в предметно = 81; области приложения, = 074; общем случа = 77; выраженную существитеl= 3;ьным. Абстракция может быть к= 086;нцептуальн&= #1086;й или физической: она отражае = 90; возможност&= #1080; системы по хранению информации = 86; ней, по взаим&#= 1086;действию с ней или же оба эти фактора. Кла<sp= an class=3DGramE>сс включ = 72;ет: атрибуты (данные, описывающиk= 7; объект, а также тот объем информации об объекте, который хранится в системе); отн&#= 1086;шения с другими классами и о= 087;ерациями (поведение данного объекта, которое и описывает соответствm= 1;ющие ответственl= 5;ости). Диаграмма класса отражает содержимое классов (набор декла= 088;ативных, статичных э = 83;ементов модели), и их взаимоотноm= 6;ения. Класс определяет интерфейсы = 89;оответству&#= 1102;щих экземпляроk= 4; объектов (таблица 8.1). <o:p></o:p>= Классы должны отличаться идентичносm= 0;ью структуры, иметь четко определеннm= 9;е ответственl= 5;ости и поддержив = 72;ть системные функции, взаимодейсm= 0;вуя с другими об= 098;ектами посредствоl= 4; сообщений. Кл= ассы описываютсn= 3; с помощью: атрибутов (д= 072;нные, свойства), операций (сл= 091;жбы, функции, поведение, проце= ;сс, методы), жизненногl= 6; цикла разработки ПС (состояние, идентичносm= 0;ь, независимоl= 9;ть существоваl= 5;ия) и ассоциаци = 81; (отношения, связи, соеди= 085;ения). Классы имеют свойства, структуру, п= 086;ведение и отличаютс= 03; независимоl= 9;тью существоваl= 5;ия. Класс может применятьсn= 3; для определениn= 3; подклассов, которые мог = 91;т быть проилл= 02;стрированы примерами. Однако клас = 89; нельзя проиллюстрl= 0;ровать непосредстk= 4;енно, опираясь только на него самого. Классы обладают по = 74;едением, которое также называется операцией, службой, фун= 082;цией или методом. Эти термины = 080;спользуютс&= #1103; в спецификацl= 0;и UML, где операция оп = 80;сывает класс и объект, а метод -</span= > реализk= 2;цию операции. <o:p></o:p></span= > Существуеm= 0; ряд подходо = 74; к определен = 80;ю классов объектов:<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l266 level1 lfo135;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 89;пользовани&#= 1077; грамматичеl= 9;кого анализа ест = 77;ственного языкового описания си = 89;темы, объекты и атрибуты = - это существитеl= 3;ьные, операции и сервисы = - глаголm= 9;, такой подхо = 76; реализован = 74; иерархичесl= 2;ом методе объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния, который широко испо = 83;ьзуется;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l266 level1 lfo135;tab-stops:list 14.2pt left = 27.35pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 89;пользовани&#= 1077; в качестве объектов ПС событий, объектов и ситуаций реального мира из области приложения (<sp= an class=3DGramE>например</spa= n> самолетов, ролевых сит = 91;аций менеджера) для реализации таких объек = 90;ов, могут потре = 73;оваться специальныk= 7; структуры хранения данных (абстрактны = 77; структуры д = 72;нных);<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l266 level1 lfo135;tab-stops:list 14.2pt left = 27.35pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 88;именение подхода, основанногl= 6; на сценария = 93;, в котором по очереди определяютl= 9;я и анализируюm= 0;ся различные сценарии использоваl= 5;ия системы; группа, отвечающая за анализ, должна иден = 90;ифицироват&#= 1100; необходимыk= 7; объекты, атрибуты и операции; метод анализа, при котором аналитики и разработчиl= 2;и присваиваюm= 0; роли объектам, отражают эффективноl= 9;ть подхода, основанногl= 6; на сценария = 93;.<o:p></o:p> Дл&#= 1103; описания классов можно испол= 00;зовать информацию, полученную из разных источников. Объекты и оп= 077;рации, первоначалn= 0;но определеннm= 9;е на основе неформальнl= 6;го описания системы, могут служить отп = 88;авной точкой при ООП. Затем для усоверш = 77;нствования и расширени= 03; описания первоначалn= 0;ных объектов можно использоваm= 0;ь дополнителn= 0;ную информацию, полученную из области применения ПС или анализа сце = 85;ариев. Дополнителn= 0;ную информацию также можно получить в ходе обсужд = 77;ния с пользоватеl= 3;ями разрабатывk= 2;емой системы или анализа имеющихся с = 80;стем.<o:p></o:p> Объект является отдельным (о= 089;обенным) экземпляроl= 4; класса. Объекты = - это исполняемыk= 7; сущности с атрибутами = 80; сервисами класса объектов. Об= 098;екты представляn= 2;т собой реализацию класса, на основе одно = 75;о класса можн = 86; создать много различных объектов. Обычно при разработке объектных моделей основное внимание сосредоточk= 7;но на классах объектов и и= 093; отношениях. Во всех случаях применяетсn= 3; общее правило, согласно которому объект инка = 87;сулирует данные о своем внутреннем строении. <o:p></o:p></span= > Объект = - это сущность, способная пребывать в различных с = 86;стояниях и имеющее определеннl= 6;е множество операций. Со= 089;тояние определяетl= 9;я как набор атрибутов о = 73;ъекта. Операции, связанные с объектом, предоставлn= 3;ют сервисы (функционал= 00;ные возможностl= 0;) другим объектам (клиентам) для выполнения определеннm= 9;х вычислений. Объекты создаются в соответствl= 0;и с определениk= 7;м класса объе = 82;тов, которое служит шабл = 86;ном для создани= 03; объектов. В него включе = 85;ы объявления всех атрибутов и операций, св= 103;занных с объектом данного класса. Нота= 094;ия, которая используетl= 9;я для обозначениn= 3; классов объ = 77;ктов, определена = 74; UML<= span style=3D'font-size:14.0pt'>. <o:p></o:p> Все объект = 99; из класса, имеют значе = 85;ия атрибутов, соответствm= 1;ющие атрибутам и = 79; полного дескрипторk= 2; классов. Эти объекты будут также поддерживаm= 0;ь операции, оп= 080;сываемые дескрипторl= 6;м классов. Объек= ;ты являются экземпляраl= 4;и класса и сов= 084;естно используют свойства (ат= 088;ибуты и операции) данного класса. Каждый объе = 82;т отличается собственноl= 1; идентичносm= 0;ью и имеет характерныl= 1; набор значений дл= 03; атрибута. Он является су = 97;ностью, инкапсулирl= 6;ванной в двух воплощенияm= 3; = - состояния и поведения. Состояние представлеl= 5;о с помощью атрибутов и связей; опер= 072;ции и механизмы состояния представляn= 2;т поведение. Состояние сохраняет эффекты от производимm= 9;х некоей сущн = 86;стью операций. Диаграммы объектов отображают объекты, их ассоциации = 80; отношения (связи) в их развитии во времени. Объектом (если он подо&#= 1073;ен сущности) может быть:<o:p></o:p= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>м = 72;териальный предмет (или индивидуум);<o:= p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>в = 99;полняемая роль;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>с = 86;бытие;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>в = 79;аимодейств&#= 1080;е (контракт);<o:p></o:p></spa= n> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 87;ерационная процедура (о= 073;зор);<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 88;ганизацион&#= 1085;ая единица;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>м = 77;сто (банк);<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>с = 90;руктура.<o:p></o:p> Объект являетс= ;я экземпляроl= 4;, который структурирl= 6;ван и функциони = 88;ует в соответст = 74;ии со своим классом. Все объекты, пор= 086;жденные одним и тем же классом, структурирl= 6;ваны одним спосо = 73;ом, хотя каждый из них имеет свой собственныl= 1; набор связей атрибутов. = 050;аждая связь атриб = 91;та имеет ссылк = 91; на экземпля = 88;, обычно на значение данных. Объект може = 90; порождатьсn= 3; несколькимl= 0; классами. В этом случае объект обладает всеми свойствами, которые объ= 03;влены во всех этих классах, как структурныl= 4;и, так и поведенчесl= 2;ими. К объекту можно добав = 83;ять новые класс = 99;, а старые классы отделять. Эт= 086; значит, что свойства но = 74;ых классов динамическl= 0; добавляютсn= 3; к данному объекту, а свойства, об= 098;явленные ранее в классе, удаляемые и = 79; объекта, динамическl= 0; также удаляются и = 79; объекта.<o:p></o:p> Интерфейс = 86;м называетсn= 3; набор операций, характеризm= 1;ющих поведение элемента. Интерфейсы можно использоваm= 0;ь для установ = 82;и атрибута, возвращениn= 3; значения ат = 88;ибута и для запрос= 072; объекта с целью выпол = 85;ения операции. Важной частью любого проц = 77;сса ООП являетс= 03; специфицирl= 6;вание интерфейсоk= 4; между различными = 82;омпонентам&#= 1080; системы. Инт= 077;рфейсы необходимо определять так, чтобы объекты и другие компоненты можно было проектировk= 2;ть параллельнl= 6;. Определив интерфейс, разработчиl= 2;и других объектов могут считать, что &#= 1080;нтерфейс уже реализо = 74;ан. Один и тот же объект може = 90; иметь неско = 83;ько интерфейсоk= 4;, причем кажд = 99;й из них предполагаk= 7;т свой способ поддержки методов. Проектировk= 2;ние интерфейсоk= 4; объектов связано со спецификацl= 0;ей интерфейса = 74; объекте или группе объе = 82;тов. Интерфейсm= 9; можно определить подобно диаграмме классов. По м&#= 1077;ре усложнения интерфейсоk= 4; такой подхо = 76; оказываетсn= 3; более эффективныl= 4;, так как для о&#= 1073;наружения ошибок и противоречl= 0;й в описании интерфейса можно воспользовk= 2;ться средствами проверки синтаксиса языка прогр = 72;ммирования. <o:p></o:p> </spa= n>Сообщен= ;ия - содержат объект назначения (включающий = 086;перацию, предназначk= 7;нную для выполнения), название выполняемоk= 5;о оператора и параметры, которые нео = 73;ходимы для выполнения операции. Эт= 080; интерфейсы определяют средства взаимодейсm= 0;вия между объектами. Каждому объекту пересылаютl= 9;я сообщения других объектов. Интерфейсы относятся к общедоступl= 5;ым методам, поскольку о = 85;и имеют отношение к другим объектам. Полезно определять = 80;нтерфейсы заранее, т.е. в= начале жизненного цикла ПС. В этом случае команда про = 75;раммистов может быть р= 072;зделена с учетом границ межд = 91; объектами, что может быть предпочтитk= 7;льнее разделения по функционалn= 0;ным границам. После того, как интерфе = 81;сы и набор ответственl= 5;остей четко опред = 77;лены, они могут функционирl= 6;вать независимо, объединяясn= 0; лишь поздне = 77;, в цикле по тестированl= 0;ю модели.<o:p></o:p> Сообщение </sp= an>являетс= ;я спецификацl= 0;ей по транспортиl= 8;овке информации из одного экземпляра объекта в др= 091;гой, причем ожидается, что эта деятельносm= 0;ь имеет резул= 00;тат (сообщение может указывать н = 72; формированl= 0;е сигнала или на вызов операции). Стиму= 083; определяе= т передачу ин = 92;ормации из одного экземпляра объекта в др= 091;гой, например, фо= 088;мирование сигнала или вызов операции; получение с = 86;общения означает обработку стимула, который передается из экземпля = 88;а отправителn= 3;. Получ= 072;тель (объект) является объектом дл= 03; обработки стимула, который передается из экземпля = 88;а отправителn= 3;. Отнош= 077;ние представлn= 3;ет семантичесl= 2;ую связь между элементами модели (примеры отношений включают ассоциации = 80; обобщения). Ответ= 089;твенность является контрактом или обязательсm= 0;вом создателя классов; для пересылки сообщения стимул передается из экземпля = 88;а объекта отправителn= 3; к экземпляр = 91; получателя. <sp= an style=3D'mso-bidi-font-style:italic'>Отпра= 074;итель (объект) представляk= 7;т собой объек = 90;, передающий стимул в объект полу = 95;ателя.<o:p></o:p> </sp= an> Атриб= ут представляk= 7;т собой описа = 85;ие набора значений, ко= 090;орые могут вызыв = 72;ться экземпляраl= 4;и объектов данного кла = 89;са. Эта информа = 94;ия является дл= 03; объекта внутренней = 80; имеет следующие особенностl= 0;:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>п = 88;едставлени&#= 1077; с помощью существитеl= 3;ьного;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 87;исание объекта в терминах реального в = 88;емени;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>в = 86;зможность, служить индикатороl= 4; состояния;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 73;ладание типом данны = 93;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 76;ентичность для объекто = 74; одного класса -</span= > может отличаться по значению, но не по сути;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зможность получения значения, определеннl= 6;го с помощью домена пересчета (набор опред= 077;ленных значений).<o:p></o:p></span= > Операция представляk= 7;т собой услуг = 91;, которая может запра = 96;иваться из объекта для оказани= 03; влияния на е= 075;о поведение. Операции можно описывать с = 86;гласно следующим параметрам:<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>инкапсули&#= 1088;ование внутри объекта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 90;клик на стимул (сообщение);<o:p></o:= p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зможность действия, выполняемоk= 5;о объектом с помощью другого объекта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зможность преобразовk= 2;ния, которому по = 76;вергается объект.<o:p></o:p> Метод является специфичесl= 2;ой реализациеl= 1; операции. Оп= 077;рация (метод) являе&#= 1090;ся средством, с помощью которого объект може = 90; реализоватn= 0; свою ответс = 90;венность. Операция дл= 03; объекта вызывается = 89; помощью соо = 73;щения, пересылаемl= 6;го из другого объекта. Все объекты имеют метод = 99;, применяемыk= 7; для их инициализаm= 4;ии и выявления = 074; рамках моде = 83;и, а также возможностl= 0; для приобретенl= 0;я атрибутов и избавления от них. Метод&#= 1099; представляn= 2;т собой способы вза = 80;модействия объектов между собой, сообщений для вызова (стимулиров = 72;ния) определеннl= 6;й деятельносm= 0;и (поведения) в пределах объекта пол = 91;чателя. В ходе прове= 076;ения анализа для этого к каждому объекту, имеющему ссылку на другие объекты, доб= 072;вляется внешний клю = 95;. Мето = 76; представl= 3;яет реализацию для операци = 80; - указывает алгоритм ил = 80; процедуру, которая ассоциируеm= 0;ся с операцией. <o= :p></o:p> Ассоциациn= 3; отражает важное= соединениk= 7; (связь) между понятиями или классам = 80; (объектами). Рассматривk= 2;емое понятие включает, по крайней мер = 77;, два ассоциа = 90;ивных конца. Свойство множественl= 5;ости для концов ассоциации показывает, = 082;акое число экземпляроk= 4; объектов можно ассоц = 80;ировать с отдельным = 101;кземпляром класса.<o:p></o:p> Процесс инкапсуляцl= 0;и состоит из отделения внешних аспектов объекта от п= 086;следствий внутренней реализации этого объек = 90;а. Другим термином инкапсуляцl= 0;и является сокрыти= 077; информации. </s= pan>Внешние аспекты объекта доступны другим объектами с помощью методов самого объе = 82;та, в то время как внутренние реализации этих методо = 74; скрыты от внешнего объекта, пересылающk= 7;го сообщения. Инкапсуляцl= 0;я важна для получения потенциала или для поддержки объектно-ор = 80;ентированн&#= 1099;х моделей. Поскольку подробностl= 0; реализации скрыты от других объектов, он= 080; содержатся = 74; пределах объекта. Влияние изм = 77;нений, вносимых в р= 077;ализацию метода минимально для всей мод= 077;ли. <o:p></o:p> Потен= циально все объекты являются повторно используемm= 9;ми компонентаl= 4;и, так как они независимо инкапсулирm= 1;ют данные о состоянии и операции. Ар= 093;итектуру ПС можно разрабатывk= 2;ть на базе объе= 082;тов, уже созданн = 99;х в предыдущи = 93; проектах. Такой подхо = 76; снижает стоимость проектировk= 2;ния, программирl= 6;вания и тестированl= 0;я ПС. Кроме того, появля= 077;тся возможностn= 0; использоваm= 0;ь стандартныk= 7; объекты, что уменьшает риск, связан= 085;ый с разработкоl= 1; программноk= 5;о средства. Однако иногда повторное использоваl= 5;ие эффективнеk= 7; всего реализоватn= 0; с помощью коллекций о = 73;ъектов (компоненто = 74; или объектн = 99;х структур), а не через отдельные объекты. <o:p></o:p> </= span> Н = 72;следование определяет совместное использоваl= 5;ие атрибутов и поведение объектов в пределах иерархичесl= 2;ой структуры (с= 091;перклассов и/или подкла= 089;сов). Каждый подкласс наследует все свойств = 72; <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic'>- (атрибуты и операции) суперклассk= 2; (предка) и добавляет свои собств = 77;нные уникальные свойства. К= 083;асс содержит описание всех атрибутов, ассоциаций = 80; операций, входящих в объект, что является обобщением объекта. Каждый клас = 89; имеет набор наследуемыm= 3; свойств = - атрибутов, операций и ассоциаций. Эти структу = 88;ы данных и алг= 086;ритмы немедленно становятся доступными = 76;ля подклассов наследникоk= 4;. Класс может иметь потомков (подклассы), где потомок является специализаm= 4;ией предшествеl= 5;ника. Потомок наследует (включает в с&#= 1077;бя эту структуру и поведение общих предш = 77;ственников), при этом он способен добавлять свои собственныk= 7; атрибуты и операции. Та= 082;ое отношение также известно ка = 82; обобщение (генерализа = 94;ия). Наследованl= 0;е/специализ&#= 1072;ция/обобщен= ;ие является пр = 77;имуществом метода ООП, поскольку поддерживаk= 7;т повторное использоваl= 5;ие классов. Бла= 075;одаря применению этих поняти = 81; свойства суперклассl= 6;в повторяютсn= 3; в каждом объекте подкласса, и таким образом под = 76;ерживается высокий фактор обно = 74;ления. Изменения для атрибут = 86;в или операци = 81; немедленно наследуютсn= 3; всеми подклассамl= 0;. <o:p></o:p> &n= bsp; Модели систем, разрабатывk= 2;емые при формированl= 0;и требований, должны отоб = 88;ажать реальные сущности, принадлежаm= 7;ие классам объ = 77;ктов. Все объекты связаны с ра= 079;личными уровнями в архитектурk= 7; системы. Конкретные решения по а= 088;хитектуре системы можно принимать в процессе её реализации. Когда связи между разработчиl= 2;ами требований, проектировm= 7;иками и программисm= 0;ами не очень тес= 085;ые (например, если систем = 72; проектируеm= 0;ся в одном подразделеl= 5;ии предприятиn= 3;, а реализуетсn= 3; в другом), требуется более детализироk= 4;анная модель. Следователn= 0;но, в процессе п= 088;оектирован&= #1080;я важно решит= 00;, какие требуются модели, и какой должн = 72; быть степен= 00; их детализациl= 0;. Это решение зависит также от тип= 072; разрабатывk= 2;емой системы. <o:p></o:p> &n= bsp; Классы не должны содержать информацию об отдельны = 93; системных объектах. Можно разработатn= 0; различные т = 80;пы объектных моделей, показывающl= 0;е, как классы с= 074;язаны друг с другом, как объекты = 72;грегируютс&#= 1103; из других объектов, ка= 082; объекты взаимодейсm= 0;вуют с другими объектами. Эти модели расширяют понимание разрабатывk= 2;емой системы. Иде= 085;тификация объектов и классов объ = 77;ктов считается наиболее сложной зад = 72;чей в процессе объектно-ор = 80;ентированн&#= 1086;й разработки систем. Определениk= 7; объектов = - это осн = 86;ва для анализа = 080; проектировk= 2;ния системы. <o:p></o:p> Модель окружения системы и модель использоваl= 5;ия системы представляn= 2;т собой две до= 087;олняющие друг друга модели взаимоотноm= 6;ений между данно = 81; системой и е= 105; окружением. = 052;одель окружения системы = - это статическаn= 3; модель, которая описывает другие системы из окружения разрабатывk= 2;емого ПС. Модель использоваl= 5;ия системы = - динамиm= 5;еская модель, кото= 088;ая показывает взаимодейсm= 0;вие данной сист = 77;мы со своим окр= 091;жением. Модель окружения системы можно предс = 90;авить с помощью схемы связе = 81;, которая дае = 90; простую блок-схему общей архитектурm= 9; системы. С помощью пакетов я= 079;ыка UML её можн = 86; представитn= 0; в развернут = 86;м виде как совокупносm= 0;ь подсистем. Такое представлеl= 5;ие показывает, что рабочее окружение системы находится внутри подсистемы, занимающейl= 9;я сбором данных. При моделироваl= 5;ии взаимодейсm= 0;вия проектируеl= 4;ой системы с её окружением при ООП применяетсn= 3; абстрактныl= 1; подход, который не требует больших объемов дан = 85;ых для описани= 03; этих взаимо = 76;ействий. Подход, применяемыl= 1; в UML, состои = 90; в том, чтобы разработатn= 0; модель вари = 72;нтов использоваl= 5;ия, в которой каждый вариант пре = 76;ставляет собой определеннl= 6;е взаимодейсm= 0;вие с системой. <o:p></o:= p> Объек= тные модели, разработанl= 5;ые для формиро = 74;ания требований, могут использоваm= 0;ься как для представлеl= 5;ия данных, так и &= #1076;ля процессов и = 93; обработки. В этом отноше = 85;ии они объединяют модели потоков дан = 85;ых и семантичесl= 2;ие модели данных. Они также полезны для классификаm= 4;ии системных сущностей и = 084;огут представляm= 0;ь сущности, состоящие и = 79; других сущностей. Для некоторых классов сис = 90;ем объектные модели <span style=3D'font-size:= 14.0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";mso-char-type:symbol;mso-symbol-font-family:Symbol; mso-bidi-font-style:italic'>- ес = 90;ественный способ отображениn= 3; реально сущ = 77;ствующих объектов, которые находятся под управле = 85;ием системы. Например, дл= 103; систем, обрабатываn= 2;щих информацию относительl= 5;о конкретных объектов (таких, как автомобили, самолеты, книги), котор&#= 1099;е имеют четко определеннm= 9;е атрибуты. Более абстрактныk= 7; высокоуровl= 5;евые сущности (например, библиотеки, медицинскиk= 7; регистрируn= 2;щие системы или текстовые редакторы) труднее мод = 77;лировать в виде классов объектов, поскольку о = 85;и имеют достаточно сложный инт = 77;рфейс, состоящий и = 79; независимыm= 3; атрибутов и = 084;етодов.<o:p></o:p> Объектные модели, разработанl= 5;ые во время анализа требований, упрощают пе = 88;еход к объектно-о= 088;иентирован&= #1085;ому проектировk= 2;нию и программи = 88;ованию. Однако коне = 95;ные пользоватеl= 3;и часто считают объектные модели неестествеl= 5;ными и трудными д= 083;я понимания. Часто они предпочитаn= 2;т функционалn= 0;ные представлеl= 5;ия процессов обработки данных. Поэт= 086;му полезно дополнить и = 93; моделями потоков данных, чтоб= 099; показать сквозную обработку данных в системе.<o:p></o:p> Модели данных -</span= > больших программныm= 3; систем используют = 80;нформацион&#= 1085;ые базы данных. В одних случаях эта база данных = 089;уществует независимо от программноl= 1; системы, в других <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic'>- специально создается для разрабатывk= 2;емой системы. Важной частью моделироваl= 5;ия систем является определениk= 7; логической формы данны = 93;, обрабатываk= 7;мых системой. Наиболее широко используемl= 6;й методологиk= 7;й моделироваl= 5;ия данных явля = 77;тся моделироваl= 5;ие типа "сущность = - = 89;вязь - атрибут", которое показывает структуру д = 72;нных, их атрибуты = 080; отношения между ними. <o= :p></o:p> Д&= #1083;я описания структуры обрабатываk= 7;мой информации модели данн = 99;х часто испол= 00;зуются совместно с моделями потоков дан = 85;ых. Проекты структуры П = 57; представляn= 2;тся ориентировk= 2;нными графами. Они состоят из набора узло = 74; различных типов, соеди= 085;енных дугами, отображающl= 0;ми связи между структурныl= 4;и узлами. В системе проектировk= 2;ния присутствуn= 2;т средства вывода на дисплей этого графа (т.е. структурноl= 1; диаграммы) и его преобразовk= 2;ния к виду, удобному дл= 03; хранения в базе данных проектов. Система редактировk= 2;ния выполняет преобразовk= 2;ния струк= ;турной диаграммы и = 79; формата баз = 99; данных в фор= 084;ат, позволяющиl= 1; отобразить её на экране монитора в виде блок-сх= 077;мы. Информация, предоставлn= 3;емая редактором другим средствам анализа проекта, дол= 078;на включить ло = 75;ическое представлеl= 5;ие графа проекта. Эти средства работают с объектами, и= 093; логическимl= 0; атрибутами = 80; связями меж = 76;у ними.<o:p></o:p> С&= #1091;щность <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > реальный ил = 80; абстрактныl= 1; объект, имеющий опр = 77;деляющее значение дл= 03; рассматривk= 2;емой системы (это может быть объект, как самой систе = 84;ы, так и её окру&#= 1078;ения). Каждая сущность должна имет= 00; уникальное имя и обладать одним или несколькимl= 0; атрибутами, которые либ = 86; принадлежаm= 0; сущности, либо наследуютсn= 3; через связь. Сущность соответствm= 1;ет классу (или типу) объектов, а не конкретн = 86;му экземпляру класса. Поим= 077;нованная связь (ассоциация) между двумя сущностями осуществляk= 7;тся с помощью гл= 072;голов (например, имеет, определяет, принадлежиm= 0;). Атри = 73;ут = - любая характерисm= 0;ика сущности (предназнач = 72;ется для идентиф = 80;кации, классификаm= 4;ии, численной параметризk= 2;ции или описани= 03; состояния сущности). Значения атрибутов однозначно идентифициl= 8;уют экземпляр сущности. <o:p></o:p> Я&= #1079;ык моделироваl= 5;ия UML не имеет определеннm= 9;х обозначениl= 1; для типа моделей данных, что желательно для объектно-ор = 80;ентированн&#= 1086;го процесса ра = 79;работки ПС, где для описания систем используютl= 9;я объекты и их отношения. Если сущностям поставить в = 089;оответстви&= #1077; простейшие классы объектов (бе= 079; ассоциировk= 2;нных методов), тогда в качестве мо = 76;елей данных можн = 86; использоваm= 0;ь модели клас = 89;ов UML совместно с именованн = 99;ми ассоциацияl= 4;и между класс = 72;ми. <o:p></o:p> Модели наследованl= 0;я. Важны= м этапом объектно-ор = 80;ентированн&#= 1086;го моделироваl= 5;ия является определениk= 7; классов объ = 77;ктов, которые затем систематизl= 0;руются. Это подразу = 84;евает создание схемы классификаm= 4;ии, которая показывает, как классы объектов св= 03;заны друг с друго= 084; посредствоl= 4; общих атрибутов и сервисов. Схема класс = 80;фикации организоваl= 5;а в виде иерархии наследованl= 0;я, на вершине которой пре = 76;ставлены наиболее об = 97;ие классы объектов. Более специ = 72;лизированн&#= 1099;е объекты наследуют и = 93; атрибуты и сервисы. Эти объекты могут иметь собственныk= 7; атрибуты и сервисы. В нотации UML наследl= 6;вания показываютl= 9;я сверху-вниз, как принято = 074; других объектно-ор = 80;ентированн&#= 1099;х нотациях. Стрелка выходит из класса, который наследует атрибуты и операции, и направлена = 82; родительскl= 6;му классу. В UML вместо термина "наследован= ;ие" чаще используетl= 9;я термин "обобщение". В моделях мн= 086;жественног&= #1086; наследованl= 0;я классы могу = 90; иметь нескольких родителей. Тогда насле = 76;уются атрибуты и сервисы от каждого родительскl= 6;го класса. <o:p></o:p> Упрощения моделей при ООП может вызывать некоторые затруднениn= 3; специалистl= 6;в в понимании следующего:<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l34 level1 lfo136;tab-stops:14.2pt list 25.1pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 76;ни и те же динамическl= 0;е и статическиk= 7; модели опис = 99;вают в разработк = 77; только "споl= 9;обы" взаимодейсm= 0;вия с объектами;<o:= p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l34 level1 lfo136;tab-stops:14.2pt list 25.1pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 85;капсуляция скрывает внутреннее содержание объекта, поз= 074;оляя разработчиl= 2;у уделять больше вним = 72;ния методам использоваl= 5;ия объектов = - их суще = 89;твенных, неотъемлемm= 9;х характерисm= 0;ик; позволяет разделять статус, функцию, пов= 077;дение; ограничиваk= 7;т доступ к переменным, которые функционирm= 1;ют внутри алго = 88;итма;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l34 level1 lfo136;tab-stops:14.2pt list 25.1pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>а = 75;регация позволяет создавать крупный объ = 77;кт из небольши = 93;, упрощать вид объекто = 74;, позволяя выполнять обработку сложных состояний. <o:p></o:p= > <o:p> </o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102478"></a><a name=3D"_Toc508102251">8.3. Варианты представлеl= 5;ия моделей и ср= 077;дства объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния программныm= 3; средств</a> </h1> <o:p> </o:p> Сущес= твует два типа объектно-ор = 80;ентированн&#= 1099;х моделей сис = 90;емной архитектурm= 9;:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l45 level1 lfo131;tab-stops:14.2pt list 49.0pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>статиче= ;ские модели, которые описывают с = 90;руктуру системы в терминах классов объектов и взаимоотноm= 6;ений между ними, которые док = 91;ментируютс&#= 1103; на данном этапе, являю= 090;ся отношениямl= 0; обобщения, о= 090;ношениями "использ= уют - используютl= 9;я" и структурн = 99;ми отношениямl= 0;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l45 level1 lfo131;tab-stops:14.2pt list 49.0pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>динамич= ;еские модели, которые описывают с = 90;руктуру системы и показывают динамическl= 0;е взаимодейсm= 0;вия между объектами системы (но не классами объектов), = - докумеl= 5;тируемые взаимодейl= 9;твия соде= ржат последоваm= 0;ельность соста= ;вленных объектами з = 72;просов к сервисам и описывают реакцию системы на взаимодейсm= 0;вия между объек = 90;ами.<o:p></o:p> В языке моделироваl= 5;ия UML поддерживаk= 7;тся ряд возможн = 99;х статическиm= 3; и динамичес = 82;их моделей: <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l10 level1 lfo132;tab-stops:14.2pt list 51.4pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>м = 86;дели подсистем, которые показывают логически сгруппировk= 2;нные объекты, они представлеl= 5;ы с помощью диаграммы классов, в ко&#= 1090;орой каждая подс = 80;стема обозначаетl= 9;я как пакет, и является статическиl= 4;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l10 level1 lfo132;tab-stops:14.2pt list 51.4pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>м = 86;дели последоватk= 7;льностей, которые показывают = 74;заимодейст&#= 1074;ия между объек = 90;ами, они представляn= 2;тся в UML с помощью диаграмм последоватk= 7;льности или коопера = 90;ивных диаграмм = - динамиm= 5;еские модели;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l10 level1 lfo132;tab-stops:14.2pt list 51.4pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>м = 86;дели конечного автомата, которые показывают изменение с = 86;стояния отдельных о = 73;ъектов в ответ на определеннm= 9;е события, в UML<= span style=3D'font-size:14.0pt'> они представлеl= 5;ы в виде диаграмм со = 89;тояния - динамическl= 0;е модели.<o:p></o:p> Модель подсистемы является од = 85;ой из наиболее важных и пол= 077;зных статическиm= 3; моделей, поскольку показывает, как можно организоваm= 0;ь систему в виде логически связанных групп объек = 90;ов. В UML пакеты являются структурамl= 0; инкапсуляцl= 0;и и не отображ= 072;ются непосредстk= 4;енно в объектах разрабатывk= 2;емой системы. Существует несколько способов со = 79;дания, применения = 80; введения новых опред = 77;лений для моделей ООП с исполь= 079;ованием диаграмм вариантов использоваl= 5;ия сценариев, д= 080;аграмм действий, ди= 072;грамм класс / объект, а также диаграмм сотрудничеl= 9;тва, взаимодейсm= 0;вия, перехода состояния, контекста данных и сло= 074;аря данных. Некоторые вводятся сверху-вниз,<sp= an style=3D'mso-spacerun:yes'> другие = - снизу-в = 74;ерх, и все они итеративно определяютl= 9;я заново с помощью сотрудничеl= 9;тва. <o:p></o:p> Статическl= 6;е представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;го анализа <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-weight:bold'>- представля= ;ет собой диаграмму класса, а так&#= 1078;е диаграмму объекта для представлеl= 5;ия определеннl= 6;го экземпляра класса, куда входят комп = 86;ненты атрибутов, служб и отношений наряду с понятиями, взятыми из иерархии, абстракции, инкапсуляцl= 0;и и наследованl= 0;я. Идентифициl= 8;уются ответственl= 5;ости классов, затем обработка идет наверх, а для достоверноl= 9;ти применяютсn= 3; сценарии вариантов использоваl= 5;ия. В этом случа= 077; реализуетсn= 3; подход снизу-вверх.<sp= an style=3D'mso-spacerun:yes'> Подоб= ;ный способ достаточно хорош, но сущ&#= 1077;ствует еще путь сверху-вниз,<sp= an style=3D'mso-spacerun:yes'> когда при идентиф = 80;кации классов начинают с практическl= 0;х примеров, а затем продолжаетl= 9;я обработка вниз, доходя до сценарие = 74;. Если начать = 089; классов можно сначала иде = 85;тифицирова&#= 1090;ь их через абстракции. Затем для каждого = 082;ласса перечисляюm= 0;ся ответственl= 5;ости, идентифициl= 8;уются атрибуты и операции (поведение <sp= an style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - снова через абстр = 72;кцию) и, наконец, обращаются = 82; сценариям вариантов и = 89;пользовани&#= 1103; для подтверждеl= 5;ия диаграммы класса. Однако сначала рас = 89;матриваетс&#= 1103; описание диаграмм кл = 72;ссов.<o:p></o:p> Статическl= 6;е представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;й разработки проекта = - k= 6;иаграммы взаимодейсm= 0;вия и сотрудничеl= 9;тва - отобр= ;ажают взаимодейсm= 0;вия, которые пространстk= 4;енно ориентировk= 2;ны на окружени = 77; модели и характеризm= 1;ют классы и асс= 086;циации (экземпляры = 080; связи). Целью сотрудничеl= 9;тва является определениk= 7; способов реализации вариантов использоваl= 5;ия. Диаграмма сотрудничеl= 9;тва отображает отношения между экземпляраl= 4;и объектов. Поведение р = 77;ализуется с помощью набора объектов, обменивающl= 0;хся входными сигналами в рамках общего взаи = 84;одействия, что позволяет достичь пос = 90;авленной цели. Для представлеl= 5;ия механизмов, применяемыm= 3; при разработке, = 074;ажно обращать вн = 80;мание только на определеннm= 9;е объекты и из= 091;чать взаимодейсm= 0;вие между ним. Ра&#= 1089;сматриваем= ые объекты всегда выделяются = 80;з большей системы, в которой данные объекты являются лишь компон = 77;нтами.<o:p></o:p> Сотрудничk= 7;ство уточняет ко = 85;текст, который позволяет в = 99;разить поведение р = 77;ализуемого элемента в терминах, единых для в= 089;ех участников сотрудничеl= 9;тва. Таким образ = 86;м, в то время как модель представляk= 7;т систему в целом, сотрудничеl= 9;тво является ли = 96;ь частичным отображениk= 7;м данной модели. Имен= 085;о сотрудничеl= 9;тво определяет = 01;ффективнос&#= 1090;ь применения подмножестk= 4;а содержимогl= 6; модели. Сотрудничеl= 9;тво можно охара = 82;теризовать на двух различных уровнях: на уровне спецификацl= 0;и или на уровн= 077; экземпляра. Диаграмма, представляn= 2;щая сотрудничеl= 9;тво на уровне спецификацl= 0;и, характеризm= 1;ет роль классо = 74; и ассоциаци = 81;. В то же время диаграмма н = 72; уровне экземпляра отображает = 01;кземпляры и связи, которые сог = 83;асуются с ролями в сотрудничеl= 9;тве. При отображ = 77;нии сотрудничеl= 9;тва указываетсn= 3;, какие экземпляры свойств должны принимать участие в со= 090;рудничеств&= #1077;, т.е. каждый участник указывает необходимыk= 7; свойства, ко= 090;орыми должен обла = 76;ать согласуемыl= 1; экземпляр.<o:p></o:p>= Динамичесl= 2;ое представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния - диаграммы взаимодейсm= 0;вия и последоватk= 7;льные диаграммы </sp= an>= - демонст= ;рируют взаимодейсm= 0;вие, отображеннl= 6;е в динамике. В ней отображ = 72;ются экземпляры, участвующиk= 7; во взаимоде = 81;ствии с помощью соответствm= 1;ющих линий жизни, а также входные сиг = 85;алы, которыми он = 80; обмениваютl= 9;я. Эти сигналы собраны во временную п = 86;следовател&#= 1100;ность. В отличие от диаграммы сотрудничеl= 9;тва, последоватk= 7;льная диаграмма включает временные последоватk= 7;льности, но не содержит объектных отношений. П= 086;следовател&= #1100;ная диаграмма может сущес = 90;вовать в общей форм= 077; (описывать все возможные сценарии) и в форме экзем = 87;ляра (описывать один действ = 80;тельный сценарий). Последоватk= 7;льные диаграммы и диаграммы с = 86;трудничест&#= 1074;а выражают подобную информацию, однако, используют различные способы. Последоватk= 7;льная диаграмма имеет две размерностl= 0;: размерностn= 0; по вертикал = 80; представляk= 7;т время; размерностn= 0; по горизонт = 72;ли представляk= 7;т различные объекты. <o:p></o:p> Динамичесl= 2;ое представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;й разработки проекта = - диаграммы переходов между состояниямl= 0; = - представлn= 3;ют, основанное на состояни = 80;, поведение класса экземпляроk= 4; объектов дл= 03; всех сценар = 80;ев. Обычно моделируютl= 9;я лишь классы = 089; объектами, к= 086;торые, как ожидается, проходят через набор = 99; состояний. Состо= 103;ние представлn= 3;ет условие или ситуацию во время жизни объекта, при которой удо = 74;летворяетс&#= 1103; определеннl= 6;е условие, реа= 083;изуется некоторая д = 77;ятельность или же ожидается какое-либо событие. Диаграмма состояния = 86;тображает механизм состояния = - поведение, определяющk= 7;е последоватk= 7;льности состояния, которые проходит объект или взаимодейсm= 0;вие во время своей жизни при отклике на события, вместе с соответствm= 1;ющими откликами и действиями.<o:p= ></o:p> Механизм состояния определяет набор понятий, которые могут использоваm= 0;ься для моделироваl= 5;ия дискретногl= 6; поведения с помощью кон = 77;чных систем переходных = 89;остояний. Экземпляры событий генерируютl= 9;я в результат = 77; определеннl= 6;го действия в п= 088;еделах системы или её окружени= 03;. Затем событие ори = 77;нтируется на одну или несколько ц = 77;лей. Средства, с помощью которых экземпляры событий транспортиl= 8;уются к месту назн= 072;чения, зависят от типа действия, це= 083;и, свойств среды коммуникацl= 0;и и многих других факт = 86;ров. В некоторых случаях это происходит = 87;рактически мгновенно и вполне надежно, в то время как в других случаях могут происходитn= 0; периодичесl= 2;ие задержки передачи, по= 090;еря событий, переупорядl= 6;чивание или дублированl= 0;е. Поддерживаk= 7;тся полная гибк = 86;сть при моделир = 86;вании различных типов коммуникацl= 0;онных возможностk= 7;й. Событие получено, &#= 1077;сли оно размещено в очереди событий по ц= 077;левому назначению. Событие отправлен = 86;, если оно извлечено и = 79; очереди событий и до= 089;тавлено к механизму состояния для обработ = 82;и. С этой точки зрения на не= 075;о ссылаются как на текущее событие. На= 082;онец, событие поглощено, </= span>если завершена его обработка. Поглощенноk= 7; событие ста = 85;овится недоступныl= 4; для обработки. Никакие тре = 73;ования не предъявляюm= 0;ся к интервала = 84; времени между получ = 77;нием события, отправлениk= 7;м и поглощениеl= 4;. <o:p></o:p> Состояние становится актив= 085;ым, если оно вводится ка = 82; результат некоторого перехода, а неакт= 080;вным, если завершаетсn= 3; как результат перехода. Со= 089;тояние может быть завершено и начато как р= 077;зультат одного и тог= 086; же перехода. Диаграммы состояния представляn= 2;т объекты, способных к динамическl= 6;му поведению, путем указания соответствm= 1;ющего отклика на получение экземпляроk= 4; события. Обычно они применяютсn= 3; при описани = 80; поведения классов. Сос= 090;ояние представляk= 7;т собой условие во время жизни объекта или взаимодейсm= 0;вие, во время которого он = 86; удовлетворn= 3;ет некоторое условие, выполняет определеннl= 6;е действие ил = 80; ожидает некоторое событие. Кон= 094;ептуально объект остается в состоянии в = 86; время некоторого = 80;нтервала времени. <o:p></o:p> Инструменm= 0;альные средства анализа и проектировk= 2;ния ПС созданы для поддерж = 82;и моделироваl= 5;ия систем на этапах жизн = 77;нного цикла программнm= 9;х средств. Они поддерживаn= 2;т создание, редактировk= 2;ние и анализ графическиm= 3; нотаций, используемm= 9;х в структурныm= 3; методах. Инс= 090;рументальн&= #1099;е средства анализа и проектировk= 2;ния часто подде = 88;живают только определеннm= 9;е методы прое = 82;тирования и анализа, например об = 98;ектно-ориен&= #1090;ированные. Другие инструментk= 2;льные средства являются универсальl= 5;ыми системами редактировk= 2;ния диаграмм многих типо = 74;, которые используютl= 9;я разными методами пр = 86;ектировани&#= 1103; и анализа. Ин&#= 1089;трументаль= ные средства, ориентировk= 2;нные на определе = 85;ные методы, обычно автоматичеl= 9;ки поддерживаn= 2;т правила и базовые принципы этих методо = 74;, что позволя = 77;т выполнять автоматичеl= 9;кий контроль ди = 72;грамм.<o:p></o:p> Инструменm= 0;альные средства об = 99;чно объединяютl= 9;я через общий ре= ;позиторий, стру = 82;тура которого является собственноl= 9;тью разработчиl= 2;а пакета инст = 88;ументальны&#= 1093; средств. Центральн = 99;й репозитl= 6;рий позволяет проектировm= 7;ику найти нужны = 81; проект, компонент и соответствm= 1;ющую проектную информацию. = 054;бычно для создани= 03; общего р = 77;позитория инструментl= 6;в используютl= 9;я системы баз данных типа </s= pan>Sybase</spa= n> или Oracle. Эти пакеты инструментk= 2;льных средств сод = 77;ржат большое количество средств языков программирl= 6;вания четвертого поколения, предназначk= 7;нных для генерироваl= 5;ия программноk= 5;о кода на основе сист = 77;мной архитектурm= 9;, они также могут генер = 80;ровать базы данных. Пакеты инструментk= 2;льных средств обычно закрыты, т.е. не рассчита = 85;ы на добавлениk= 7; пользоватеl= 3;ями собственныm= 3; инструментl= 6;в или на измен= 077;ние средств пакета, в который входят:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>редакторы диаграмм, предназ= ;наченные для создани= 03; диаграмм потоков дан = 85;ых, иерархий объектов, диаграмм "сущность-сk= 4;язь", эти редакто = 88;ы не только имеют средства рисования, н= 086; и поддерживаn= 2;т различные типы объект = 86;в, используемm= 9;х в диаграмма = 93;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства проектировk= 2;ния, анализа и проверки выполня= ;ют проектировk= 2;ние ПС и создают отчеты об ошибках и дефектах в системной а = 88;хитектуре, они могут работать со = 74;местно с системой редактировk= 2;ния, поэтому обнаруженнm= 9;е ошибки можн = 86; устранять н = 72; ранней стадии процесса проектировk= 2;ния;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>словарь данных хранит информацию об объектах, которые исп = 86;льзуются в структуре системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства генерироваl= 5;ия отчетов на основе информации из централь = 85;ого репозитl= 6;рия автоматичеl= 9;ки генерируют системную документацl= 0;ю;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства создания форм определяют форматы документов = 80; экранных фо = 88;м;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства импортировk= 2;ния и экспортироk= 4;ания позво= ляют обмениватьl= 9;я информациеl= 1; из центральноk= 5;о репозитl= 6;рия различным инструментk= 2;льным средствам;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>генератор = 99; программноk= 5;о кода а= ;втоматичес = 82;и генерируют программы н = 72; основе проектов компонентоk= 4;, хранящихся = 74; центральноl= 4; репозито = 88;ии.<o:p></o:p> В некоторых случаях возможно генерироваm= 0;ь программы и = 83;и фрагменты п = 88;ограмм на основе информации, представлеl= 5;ной в системной модели. Поск= 086;льку в моделях не предусмотрk= 7;на детализациn= 3; низкого уровня, генератор программноk= 5;о кода не в состоянии сгенерировk= 2;ть законченныl= 1; комплекс программ. Обычно необходимы программисm= 0;ы для заверше = 85;ия автоматичеl= 9;ки сгенерировk= 2;нных программ.<o:p></o:p>= <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102479"></a><a name=3D"_Toc508102252">Лекция 9. Управление ресурсами в жизненном цикле &= nbsp; программнm= 9;х средств</a></h1> <h1><a name=3D"_Toc508102480"></a><a name=3D"_Toc508102253">9.1. Основные ресурсы для обеспечениn= 3; жизне= ;нного цикла = &nb= sp; сложных программныm= 3; средств</a></h1> <o= :p></o:p> = Общее= понятие = - доступные ресурсы обеспечениn= 3; жизненного цикла ПС включает реальные финансовые, временные, кадровые и аппаратурнm= 9;е ограничениn= 3; затрат, в условиях которых происходит создание и с= 086;вершенство&= #1074;ание комплексов программ. В з&#= 1072;висимости от характерисm= 0;ик объекта разработки на её выполнение выделяются ресурсы раз = 83;ичных видов и разм= 077;ров. Эти факторы проявляютсn= 3; как дополни = 90;ельные характерисm= 0;ики процессов Ж = 62; и программныm= 3; продуктов, а также их рентабельнl= 6;сти, которые сле = 76;ует учитывать и оптимизироk= 4;ать. В результат = 77; доступные ресурсы становятся косвенными критериями или факторами, в= 083;ияющими на выбор методов разработки, на достигае = 84;ые качество и эффективноl= 9;ть применения программныm= 3; продуктов. М= 085;огие проекты систем терп = 77;ли и терпят неудачу из-з= 072; отсутствия = 91; разработчиl= 2;ов и заказчико = 74; при подготовке = 82;онтракта четкого представлеl= 5;ия о реальных финансовых, трудовых, временных и иных ресурсах, необходимыm= 3; для их реализации. Поэто= ;му одной из основных задач при проектировk= 2;нии ПС является экономичесl= 2;ий анализ и определениk= 7; необходимыm= 3; ресурсов для создания и обеспечениn= 3; всего ЖЦ ПС в соответствl= 0;и с требованияl= 4;и контракта и техническоk= 5;о задания. <o:p></o:p> Наиболее общим видом ресурсов, используемm= 9;х в жизненном цикле ПС, явл&#= 1103;ются допустимые финансово-э = 82;ономически&#= 1077; затраты или эквивалентl= 5;ые им величины = 090;рудоемкост&= #1080; соответствm= 1;ющих работ (см. лекцию 5). При разработке, тестированl= 0;и и анализе ка= 095;ества этот показа = 90;ель может применятьсn= 3; или как вид ресурсных ограничениl= 1;, или как опти= 084;изируемый критерий, определяющl= 0;й целесообраk= 9;ную функционалn= 0;ную пригодностn= 0; ПС. При этом необходимо также учитывать з = 72;траты на разработку, закупку и эксплуатацl= 0;ю системы качества, на технологию = 80; комплекс автоматизаm= 4;ии проектировk= 2;ния программ и баз данных, которые могут составлять существеннm= 1;ю часть совокупной стоимости и трудоемкосm= 0;и разработки = 80; всего ЖЦ ПС.<o:p></o:= p> Затраты = в ж= изненном цикле ПС опр= ;еделяются не только n= 1;та- пами разработки, </s= pan>но и этапами </spa= n>эксплуат= ;ации и сопровож= ;дения. За- траты= на этих этапах могут значител= ;ьно превы= шать затра= ты при разра= ботке и характеризm= 1;ются своим= и особы= ми закон= омерностямl= 0; . Однако э= ;ффек-тиk= 4;ность проце= сса разра= ботки ПС невозмож= ;но опред= елять без у= ;чета эm= 2;фек- тивно= сти после= дующей эксплуатацl= 0;и, а, для, долг= о модифици= ;руемых про грамм= , <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic;mso-no-proof:yes'>- бе&= #1079; оценки n= 1;ффектив= ;ности их соп= ;ровождения. Ряд ф= ;акто ров в= ;лияет l= 5;а затраты при р= ;азработ= ;ке сложн= ых ПС не </spa= n>только l= 5;е- посре= дственно, но и ч= ерез возмо= жное измен= ение затра= т в дальней- шем п= ;ри сопровождеl= 5;ии или эк= ;сплуатации.<sp= an style=3D'mso-spacerun:yes'> Каждый из этапов: разра= ботка, сопро= вождение и экспл= 091;ата- ция= <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic;mso-no-proof:yes'>- мо&= #1078;ет быть достаточно длите= льным. В пределах= ; этапов l= 8;аз- личны= е групп= ы затра= т могут быть н&= #1077;одновремен= ;ными и раз= ;делять- ся интервал= ;ами времени, исчисляемым= и годами. = 54;днако, = 88;азновремен&#= 1085;ость затра= т трудн= о учиты= вать в общем виде, и при су = 97;ествующих ме- тодик= ах, имеется некотора= ;я услов= ность при о= ;ценке влиянии- времени на совокупные </sp= an>затраты проекта. <o:p></o:p= > В соотв= ;етствии с этапами </spa= n>жизненно= ;го цикла ПС осн= ;овные за- траты= С S , снижающие ид&= #1077;альную эффек= тивность за цикл жизни t ж , = мо&= #1078;но пред-с= ;тавить с= ;ледующими составля= ;ющими (рис.9.1): <o:p></o:p> С Р — с= овокупные затра= ты на разработ= ;ку прогр= амм и обе= ;спече- ние решения заданных= ; функцион= ;альных задач= , в т= ом числе= на тех- нолог= ическое обеспечениk= 7; и а= ппаратуру ЭВМ при разра= ботке ПС, в течение </spa= n>времени </spa= n>t Р ; <o:p><= /o:p> &nb= sp; С С= </= span>— з= атраты на сопровож= ;дение ПС за </spa= n>время t с , вклю= чающие затра= ты на хранение и к= онтроль их состояни= ;я, прове= дение модер- низац= ий и исправле= ;ние ошибок, тиражиро= ;вание верси= й; <o:p></o:p> С Э — з= атраты на эксплуат= ;ацию прогр= амм и аппаратн= ;ые средст- ва ЭВ= ;М, реализующиm= 3; ПС, а = 90;акже совокупн= ;ые потер= и эффектив- ности= за время t Э , </s= pan>всле= 076;ствие ограниченны= х харак= теристик ЭВМ и= ; н е идеально = 89;ти п= рограмм. <o:p></o:p> В ре&= #1079;ультате совок= упные затраты ресурсов на программноk= 7; средство - за вес= ;ь жизне= нный цикл </span= >длительн= ;остью t = ж<= span style=3D'font-size:14.0pt;mso-bidi-font-style:italic'> мо&= #1078;но предс= тавить в виде суммы: С Р + С С + С Э . В зависимо= ;сти от назначен= ;ия и области </spa= n>использо= ;вания про- грамм экономичесl= 2;ую эффек= тивность целес= ообразно анализиро- вать </span= >интеграл= ;ьно за весь период жизни= , либо дифферен= ;циально за едини= цу време= ни (месяц= ;, год). Для &#= 1089;овместн= ;ого анали= за составл= ;я- ющих= , определяющи = 93; эффек= тивность, необходимl= 6; унифицир= ;овать метод= ы време= нного анали= за и единицы </spa= n>измерени= ;я составляющl= 0;х затра= т. При п= ;оследую= ;щем излож= ении затра= ты рассм= атриваются на длительн= ;ости цикла= жизни или на соо&= #1090;ветствующи= ;х интер= валах време= ни: разработкl= 0;, эксплуатаци= и и сопровож= ;дения . <o:p></o:p> Разработкk= 2; сл&= #1086;жного ПС тре= ;бует во мн= ;о- го раз болn= 0;ших з= атрат, чем п= ;роизвод= ;ство каждо= го экзем= пляра при массо= вом тиражироваl= 5;ии. Поэто= му далее= производ= ;ство базового образ= ца прогр= амм не выделяется </sp= an>в самосто-ят = 77;льный этап, </spa= n>а рас= ;- сматр= ивается с= овместно с процессом = 88;азработ= ;ки ПС. Производ= ;ство серий= ных образ= цов программноk= 5;о продукта включает= ;ся в этап= ; эксплуат= ;ации. Экономичеl= 9;кая- &n= bsp; эффе= ктивность разра= ботки и распре-деле = 85;ие ресур= сов на ее выпол= нение могут= значител= ;ьно измен= яться в зави-симост = 80; от того, являе= тся ПС уни= ;кальным или б= ;удет изготовл= ;ен в сотнях n= 1;кземпля- ров= . Это обст&= #1086;ятельство приве= ло к целесооб= ;разности оценк= и затрат на разработ= ;ку ПС не </spa= n>только k= 4; а= бсолютных значе= ниях для о= ;пытно- го или базового образца, но и в о= тносительнm= 9;х величинах д&= #1086;ли затра= т на<= /span> про= ;- грамм= ы в каждом экземпля= ;ре реали= зующей (целевой) ЭВ&#= 1052; п= ри серий= ном произ= водстве систе= м. <o:p></o:p> Пр&= #1080; выделени= ;и с&#= 1086;ставляющих затрат на раз&= #1088;аботку прогр= амм </s= pan>целесооб= ;разно учиты= вать их относительl= 5;ый вес в= ; сумма= рных затра= тах и возм= ;ожность локал= изации групп= специали- стов, влияющих на </s= pan>величину= ; этих затрат. Разработ= ;ка прогр= амм являе= тся облас= тью с малой м= ;атериал= ;о- и энергоемкоl= 9;тью, и основ- ные з= ;атраты </spa= n>связаны </spa= n>с н= епосредствk= 7;нным или овеществлеl= 5;ным трудо= м специ= алистов разли= чных катег= орий. Поэто= му для и= ;змере- ния з= ;атрат l= 5;аиболее= ; универса= ;льной едини= цей стала= трудоемк= ;ость в челов= еко-месяцах или ч= ;еловеко= ;-годах. При э= ;том учитываю= ;тся все к= ;атегори= ;и специ= алистов, участ= вующих непос= редственно или косвенно в с= оздании да&= #1085;ного ПС. <o:p></o:p> Время или допустимая длительносm= 0;ь разработки определеннm= 9;х компонентоk= 4; и версий ПС является невосполниl= 4;ым ограниченнm= 9;м ресурсом реальных проектов. Этот ресурс все больше определяеm= 0; достижимое качество сложных комплексов программ в процессе их разработки = 80; сопровождеl= 5;ия. Высокие тре = 73;ования заказчиков к сжатым срок = 72;м реализации проектов, естественl= 5;о, ограничиваn= 2;т разработчиl= 2;ов и испытателеl= 1; в продолжит = 77;льности и объеме возможного системного анализа и проектировk= 2;ния, разработки = 80;, особенно, тестированl= 0;я программ. Увеличение числа, привлекаемm= 9;х для этого специалистl= 6;в, при опытной эксплуатацl= 0;и или бета- = 90;естировани&#= 1080;, только в некоторых пределах позволяет у = 89;корять разработку = 80; увеличиватn= 0; совокупное число тесто = 74; при проверках, для повышен = 80;я качества программ. <o:p></o:p></span= > Доступн= ;ые разработчиl= 2;ам ПС вычислителn= 0;ные ресурсы объ = 77;ктных и технологи = 95;еских ЭВМ являютс= 03; одним из важнейших факторов, определяющl= 0;м достижимое качество сложных ПС. В процессе пр = 86;ектировани&#= 1103; целесообраk= 9;но выделять определеннm= 9;е ресурсы ЭВМ на оперативноk= 7; обеспечениk= 7; качества, по= 074;ышение защищенносm= 0;и, безопасносm= 0;и и надежност = 80; функционирl= 6;вания. Допустимая величина и рациональнl= 6;е распределеl= 5;ие ресурсов ЭВ = 52; на отдельны = 77; методы улучшения о = 87;ределенных конструктиk= 4;ных характерисm= 0;ик качества ПС, оказывают существеннl= 6;е влияние на достигаемыk= 7; их значения. <o= :p></o:p> <s= pan style=3D'mso-spacerun:yes'> = Обобщенныl= 4;и ресурсами Ж = 62; проекта ПС являются до = 89;тупные стоимость или совокупные трудовые, временные и материальнm= 9;е затраты, необходимыk= 7; для приобре = 90;ения, создания, модификациl= 0; и эксплуата = 94;ии компонентоk= 4; и всего комплекса программ. Эт= 080; характерисm= 0;ики непосредстk= 4;енно влияют прак = 90;ически на все показатели качества и определяют рентабельнl= 6;сть покупки или создания заново конк = 88;етного программноk= 5;о продукта. Эт= 086; означает, чт= 086; качество яв = 83;яется относительl= 5;ым понятием, ко= 090;орое зависит от ресурсов и субъектов, осуществляn= 2;щих его оценку с позиции эффективноl= 9;ти использоваl= 5;ия, а также от сос= 090;ояния рынка соотв = 77;тствующей продукции, е= 105; производитk= 7;лей и технологи = 81;. Ориентациn= 3; на потребителk= 7;й подразумевk= 2;ет анализ их нужд и определениk= 7; возможност&#= 1077;й рынка удовлетворl= 0;ть эти потребн = 86;сти. При этом следует учитывать р = 99;ночную конкуренциn= 2; двух видов: между поста = 74;щиками готовых к применению программныm= 3; средств l= 9; фиксироваl= 5;ным качеством и между разра = 73;отчиками, способными обеспечить жизненный цикл ПС или его существ = 77;нную часть, с хара&#= 1082;теристикам= и качества, требующимиl= 9;я конкретномm= 1; заказчику. В последнем случае на требуемое качество могут оказывать влияние не только заказчик и непосредстk= 4;енные пользоватеl= 3;и, но и различн= 099;е посредники, организациl= 6;нные и торговые структуры, а также испол = 85;ители проекта. <o:p></o:p> В начале проектировk= 2;ния ПС всегда возникает задача оцен = 80;вания ресурсов, ко= 090;орые необходимы = 80; доступны дл= 03; создания и о= 073;еспечения всего ЖЦ ПС, а также возмо = 78;ной экономичесl= 2;ой эффективноl= 9;ти последующеk= 5;о применения комплекса программ по назначению при условии = 088;еализации требуемых характерисm= 0;ик качества. Экономичесl= 2;ая эффективноl= 9;ть и затраты имеют самостоятеl= 3;ьное значение и методологиn= 2; при анализе ЖЦ ПС. При планированl= 0;и проектов пр = 86;граммных средств, часто инициатороl= 4; разработки является разработчиl= 2;-поставщик, который сам = 86;стоятельно принимает все решения о про= ектированиl= 0; за счет собственныm= 3; ресурсов и предполагаk= 7;т возместить затраты при = 088;еализации программноk= 5;о продукта на рынке. В других случаях име = 77;тся определеннm= 9;й заказчик-по = 90;ребитель, который способен задать основные цели, характерисm= 0;ики качества и обеспечить ресурсы для реализации проекта. Так= 080;м образом, при экономичесl= 2;ом анализе ресурсов проектов П = 57; возможны два сценари= 03; (см. лекцию 5): <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здание и весь жизненный цикл комплекса п = 88;ограмм и/или базы данных орие = 85;тируется разработчиl= 2;ом на массовое тиражироваl= 5;ие и распростраl= 5;ение на рынке, для заранее не известных покупателеl= 1;-пользовате&#= 1083;ей в различных сферах прим = 77;нения, при этом отсутствуеm= 0; приоритетнm= 9;й внешний потребителn= 0;-заказчик, который определяет = 80; диктует основные требования, = 072; также финан = 89;ирует проект;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 72;зработка проекта ПС и/или БД предполагаk= 7;тся поставщикоl= 4;-разра-ботчиком для конкретногl= 6; потребителn= 3;-заказчика, задающего требования, который его финансируеm= 0;, с определеннm= 9;м, необходимыl= 4; ему тиражом и известной, ограниченнl= 6;й областью применения результатоk= 4; разработки. <o:= p></o:p> Разработкk= 2; ПС характеризm= 1;ется высокой долей творческогl= 6; труда, особенно н = 72; начальных и завершающиm= 3; этапах. Поэтому тру = 76;оемкость и длительно = 89;ть отдельных опера= ;ций, частных раб = 86;т и качество результатоk= 4; при проектировk= 2;нии существеннl= 6; зависят от индивидуалn= 0;ных особенностk= 7;й относительl= 5;о небольшого числа руков = 86;дителей и исполните = 83;ей, а также от характерисm= 0;ик конкретногl= 6; проекта. Отсюда принципиалn= 0;ной особенностn= 0;ю создания сложных ком = 87;лексов программ является необходимоl= 9;ть активного участия руководитеl= 3;ей и заказчико = 74; проекта в системном анализе, итерационнl= 6;м экономичесl= 2;ом оценивании затрат ресу = 88;сов и уточнении планов на базе протот = 80;пов завершеннm= 9;х разра= ;боток ПС и их личного опыта. <o:p></o:p> На рис. 9.1 отражены затраты на технологию, инструментk= 2;льные средства автоматизаm= 4;ии разработки = 80; ЖЦ ПС, а также затраты на аппаратуру вычислителn= 0;ных систем, необ= 093;одимую при обеспечениl= 0; жизненного цикла комплексов программ. Эти затраты тол= 00;ко обозначены = 74; данной лекции, а их описания и оценки отнесены к лекции 16. <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102481"></a><a name=3D"_Toc508102254">9.2. Ресурсы специалисm= 0;ов для обеспеч = 77;ния жизненногl= 6; цикла &= nbsp; сложных программныm= 3; средств</a></h1> <o:p> </= o:p> Ва= ;жнейшим ресурсом пр = 80; создании программныm= 3; средств являются люди – специ= алисты, с их уровнем профессионk= 2;льной квалификацl= 0;и, а также с многообразl= 0;ем знаний, опыта, стимулов и потребностk= 7;й. Быстрый рос = 90; сложности и повышение о = 90;ветственно&#= 1089;ти за качество комплексов = 87;рограмм привели к = появлению новых требований = 82; специалистk= 2;м программноl= 1; инженерии,</sp= an> обеспечиваn= 2;щим все этапы жизненного цикла ПС. Эти требования отражены, в частности, в восьми совр = 77;менных принципах управления качеством п = 88;одукции и технологи = 80; (см. лекцию 1). Теперь недо = 89;таточно навыков процедурноk= 5;о программирl= 6;вания небольших компонентоk= 4;, а необходим = 99; глубокие знания системотехl= 5;ики, технологии проектировk= 2;ния, методов обеспечениn= 3; и контроля к= 072;чества сложных ком = 87;лексов программ в определеннl= 6;й области при = 84;енения. Эти специалистm= 9; должны владеть нов = 86;й интеллектуk= 2;льной профессией, обеспечиваn= 2;щей высокое кач = 77;ство ЖЦ программныm= 3; средств, а также контр = 86;ль, испытания и удостовереl= 5;ие реального д = 86;стигнутого качества на каждом этап = 77; разработки = 80; совершенстk= 4;ования программ. Крупномасшm= 0;абное проектировk= 2;ние ПС различны = 93; классов, раз= 076;еление труда специалистl= 6;в по квалификацl= 0;и при разрабо = 90;ке программ и д= 072;нных, организациn= 3; коллективоk= 4; и экономика таких разра = 73;оток стали важне = 81;шей частью выбора, обучения и подготовки специалистl= 6;в для обеспечениn= 3; всего ЖЦ ПС.<o:p></o:= p> При проектировk= 2;нии и создании в= 099;сококачест&= #1074;енных комплексов программ, прежде всег = 86;, необходима организациn= 3; и тесное взаимодейсm= 0;вие представитk= 7;лей заказчика и разработчиl= 2;ов проекта. Взгляды и требования = 79;аказчика, в основном, отражаются = 74; функционалn= 0;ных и потребите = 83;ьских характерисm= 0;иках ПС. Устремлениn= 3; разработчиl= 2;ов направлены на способы и= 093; реализации = 89; требуемым качеством. Эти различи= 03; исходных точек зрени= 03; на проект пр= 080;водят к тому, что некоторые неформализl= 6;ванные представлеl= 5;ия тех и других имеют зоны неоднозначl= 5;ости и взаимного непониманиn= 3;, что может приводить к конфликтам. Организациn= 3; четкого взаимодейсm= 0;вия и сокращени = 77; этих зон тре= 073;ует проведения определеннm= 9;х мероприятиl= 1; и контактов п = 86; обмену знан = 80;ями, взаимному повышению к = 74;алификации и обучению. <o:p></o:= p> Представиm= 0;ели заказчика, участвующиk= 7; в проектировk= 2;нии, должны обучаться ф = 86;рмализации автоматизиl= 8;уемых технологичk= 7;ских процессов, для которых предназначk= 7;ны соответствm= 1;ющие ПС, и иметь представлеl= 5;ие об эффектив = 85;ых путях их реализации. = 057; другой стороны, разработчиl= 2;и должны имет= 00; в своем сост= 072;ве квалифицирl= 6;ванных менеджеров, проблемно-о = 88;иентирован&#= 1085;ых системных архитекторl= 6;в (рис. 9.2), способных переводить функционалn= 0;ные требования = 79;аказчика в конкретны = 77; спецификацl= 0;и и техническиk= 7; требования = 82; комплексу программ и его компонентаl= 4;. Специалистm= 9; по проектир = 86;ванию сложных ПС (системные архитекторm= 9;) должны имет= 00;, прежде всег = 86;, хорошую подготовку по системному анализу алгоритмов = 80; пакетов прикладных программ, по методам оценки эффе = 82;тивности проектов, организациl= 0; и планирова = 85;ию крупномасшm= 0;абных разработок программ и баз данных. Им необходима высокая квалификацl= 0;я по архитект = 91;рному построению, комплексноl= 1; отладке и испытаниям ПС определеннm= 9;х классов, умение орга = 85;изовать коллектив для решения общей целевой задачи сист = 77;мы. Это позволи = 90; на ранних этапах искл= 02;чать или сокращать дефекты, обусловленl= 5;ые различием представлеl= 5;ия ими целей и задач проектов, а также их пок= 072;зателей качества.<o:p></o:p>= = Крупномасm= 6;табные ПС являются одними из наиболее сложных объектов, со= 079;даваемых человеком, и в процессе и= 093; разработки </sp= an>= - творчеl= 9;тво как поиск новых методов, альтернатиk= 4;ных решений и способов ос = 91;ществления заданных требований, = 072; также форми = 88;ование и декомпози = 94;ия этих требований составляют = 79;начительну&#= 1102; часть всех трудозатраm= 0;. Индустриалl= 0;зация разработки ПС позволяе = 90; автоматизиl= 8;овать нетворческl= 0;е, техническиk= 7; и рутинные операции и этапы, а также облег = 95;ает творческий процесс за счет селекц = 80;и, обработки и подготовки информации, необходимоl= 1; для приняти= 03; творческих решений. Следствием этого является значительнl= 6;е сокращение доли k= 9;атрат на творческий труд в непосредстk= 4;енных затратах на разработку комплексов программ. <o:p></o:p></span= > = Однако в программноl= 1; инженерии неуклонно повышается сложность с = 86;здаваемых ПС, что вызывает возрастаниk= 7; затрат твор = 95;еского труда на еди= 085;ицу размера про = 75;рамм. В перспекти = 74;е, не смотря на автоматизаm= 4;ию и повышение инструментk= 2;льной оснащенносm= 0;и технологии разработки программ, доля творческогl= 6; труда при создании полностью н = 86;вых крупномасшm= 0;абных ПС возрастает. Даже при сокращении суммарных з = 72;трат на разработку программныm= 3; компонентоk= 4; за счет автоматизаm= 4;ии нетворческl= 6;го труда, все бо&#= 1083;ее определяющk= 7;й для технико-эко = 85;омических показателеl= 1; (ТЭП) создания ПС становится доля затрат на творческий труд и возрастают требования = 82; творческим способностn= 3;м специалистl= 6;в. <o:p></o:p> = Необходимl= 6;сть всегда выполнять значительнm= 1;ю долю творче = 89;ких работ, которые даже для высококвалl= 0;фицированн= 099;х коллективоk= 4; требуют опр = 77;деленных затрат, приводит к пониманию наличия потенциальl= 5;ых предельных значений ТЭ = 55; для новых ра= 079;работок. По мере повы= 096;ения квалификацl= 0;и коллектива = 80; автоматизаm= 4;ии творческой части труда следует ожидать асимптотичk= 7;ского приближениn= 3; к предельны = 84; значениям ТЭП. Эти предельные значения определяютl= 9;я интеллектуk= 2;льными возможностn= 3;ми человека по интенсивноl= 9;ти принятия творческих = 88;ешений. Они позволили выявить предельные значения производитk= 7;льности труда и длительносm= 0;и разработки сложных комплексов программ (см. лекцию 5). Р&= #1077;альным путем их оценки, является и = 79;учение и экстраполяm= 4;ия прецедентоk= 4; и эксперименm= 0;альных данных реальных ра = 79;работок ПС с наилучшими ТЭП, с учетом возр = 72;стания квалификацl= 0;и специалистl= 6;в и уровня автоматизаm= 4;ии разработок.</sp= an> Эти факторы способствуn= 2;т эволюционнl= 6;му, относительl= 5;о медленному приближениn= 2; к пределn= 0;ным значений ТЭ = 55; для новых ПС. Вряд ли можн= 086; ожидать в ближайшие годы повыше = 85;ия производитk= 7;льности труда на порядок при создании по = 83;ностью новых, сложных про = 75;раммных продуктов. Еще более консерватиk= 4;на длительносm= 0;ь таких разра = 73;оток.<o:p></o:p> Принципиаl= 3;ьным путем улучш = 77;ния ТЭП при разработке сложных ПС является исключение творчества на тех этапах, где возможны ти = 87;овые, стандартныk= 7; решения и апробироваl= 5;ные заготовки, н= 077; требующие при их применении высококвалl= 0;фицированн= 086;го творческогl= 6; труда. Основ= 086;й такого подхода является применение = 91;нифицирова&#= 1085;ной технологии, готовых исп = 99;танных компонентоk= 4; и стандартизl= 0;рованной архитектурm= 9; определеннm= 9;х классов ПС. Использоваl= 5;ие готовых апр = 86;бированных модулей почти исключает творческий труд по их пр&#= 1086;граммирова= нию, автономной отладке и документирl= 6;ванию. На этих этап= 072;х творческие усилия необ = 93;одимы только для отбора готовых компонентоk= 4; и разработк = 80; новых, отсут= 089;твующих среди апробироваl= 5;ных. Однако практическl= 0; полностью с = 86;храняется творческий труд при системном анализе, при комплексирl= 6;вании компонентоk= 4; и их комплек= 089;ной отладке, а также во вре= 084;я испытания П = 57; в целом (см. лекцию 14). <o:p></o:p> Для реализации сложных проектов ПС наиболее часто приме = 85;яются две схемы ор= 075;анизации коллективоk= 4; специалисm= 0;ов:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>ф = 86;рмирование для выполнения каждого про = 77;кта жесткой орг = 72;низационно&#= 1081; структуры целостного коллектива = 89; полным составом не = 86;бходимых специалистl= 6;в под единым, централизоk= 4;анным руководствl= 6;м лидера прое = 82;та; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 99;деление руководитеl= 3;я (главного конструктоl= 8;а) и небольшой группы инте = 75;раторов, по заданиям которых выполняютсn= 3; частные работы узкими специалистk= 2;ми по компонен = 90;ам, не входящим = 80; организациl= 6;нно в единый коллектив для реализа = 94;ии каждого конкретногl= 6; крупного проекта.<o:p></o:p> Первая схема предпочтитk= 7;льна, когда фирма реализует небольшое число особенно кр = 91;пных проектов-за = 82;азов и имеет возможностn= 0; для каждого из них скомплектоk= 4;ать полноценнуn= 2;, организациl= 6;нно замкнутую, “команду”. Она полностью реализует проект и нес= 077;т ответственl= 5;ость за его качество. Однако при этом возможны простои отдельных с = 87;ециалистов из-за несинхроннl= 6;го ожидания за = 76;аний или результатоk= 4; последоватk= 7;льных этапов проектировk= 2;ния компонентоk= 4; другими специалистk= 2;ми. Вторая схем = 72; для фирмы может иметь преимущестk= 4;а при большом числе относительl= 5;о небольших проектов, бл= 080;зких по содержанию = 80; функционалn= 0;ному назначению компонентоk= 4;. В этом случа= 077; большинствl= 6; специалистl= 6;в одновременl= 5;о участвуют в нескольких заказах по локальным заданиям лидеров и интеграторl= 6;в различных проектов, и может использоваm= 0;ься более полно. Однако задачи интеграторl= 6;в при этом усложняютсn= 3; и требуют бо= 083;ее высокой квалификацl= 0;и. Хотя за качество проекта в целом также несут ответ = 89;твенность руководитеl= 3;ь – лидер и группа инте = 75;раторов, усложняетсn= 3; взаимодейсm= 0;вие с поставщик = 72;ми компонентоk= 4; и руководст = 74;о их качество = 84;. <o:p></o:p> Для реализации мероприятиl= 1; по планиров = 72;нию и управлени= 02; жизненным циклом= концептуаl= 3;ьно целостных, крупных ПС и обеспечениn= 3; их качества, необходимы организациl= 6;нные действия системных архитекторl= 6;в, направленнm= 9;е на подбор и обучение ко = 83;лектива специалистl= 6;в разных категорий и специализаm= 4;ий (см. рис. 9.2). Концепция – ключевой, исходный документ сложного жизненного цикла ПС. Он непосредстk= 4;енно ориентировk= 2;н на решение проблемы ко = 84;плексной реализации требований = 80; является документом, = 082; которому можно обратиться = 74; любой момен = 90;, чтобы увиде = 90;ь, что продукт или система должны дела = 90;ь. <o:p></o:p> Практич= ;ески в каждом усп= 077;шном проекте должен быть или был лиде= 088;. Лидером продукта может быть: менеджер пр = 86;дукта, менеджер проектировk= 2;ния, руководитеl= 3;ь проекта. Лидер долже = 85;:<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>р = 91;ководить процессом выявления и формированl= 0;я требований заказчика; <o:p></o:p= > <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;ссматриват&#= 1100; конфликтуюm= 7;ие пожелания, поступающиk= 7; от различны = 93; участников проекта и находить компромиссm= 9;, необходимыk= 7; для определениn= 3; набора функций, пре= 076;ставляющих наибольшую ценность дл= 03; максимальнl= 6;го числа участников;<o:p= ></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 77;сти переговоры = 89; заказчиком, руководствl= 6;м, пользоватеl= 3;ями и разработч = 80;ками и поддерживаm= 0;ь равновесиk= 7; между тем, чего хочет з= 072;казчик, и тем, что может предо = 89;тавить команда разработчиl= 2;ов за ресурсы и время, отведенные заказчиком для реализа = 94;ии проекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 89;уществлять проверку спецификацl= 0;й программноk= 5;о средства, чтобы удостовериm= 0;ься, что они соответствm= 1;ют реальной ко = 85;цепции, предс= ;тавленной детальными функциями; <o:p></o:p> <![if= !supportLists]>-&nb= sp; = <![endif]>осущест= ;влять управление изменением приоритетоk= 4; задач, а также добав = 83;ением и исключениеl= 4; функций.<o:p></o:p> История развития разработок = 87;рограммных продуктов – это история роста их масштабов. Крупные проекты, как правило, требуют коо = 88;динированн&#= 1086;й работы больших коллективоk= 4; и многих команд. Возр= 072;стание сложности снижает способностn= 0; человека решать задачи интуитивно по мере их возникновеl= 5;ия. Чтобы добиться успеха в большом проекте, нео= 073;ходима четкая координациn= 3; действий “команды”, которая должна рабо = 90;ать по общей методологиl= 0;, чтобы решит= 00; проблему комплекса требований = 80; качества. Успешное управление требованияl= 4;и заказчика м = 86;жет осуществляm= 0;ься только эффективно организоваl= 5;ной командой разработчl= 0;ков. <o:p></o:p> &nb= sp; Одним из наиболее важных факторов является то, что члены ко= 084;анды имеют разли = 95;ные, профессионk= 2;льные навыки и квалификацl= 0;ю. Поэтому трудно ожидать, что некий универсальl= 5;ый способ организациl= 0; команды будет во все= 093; случаях предпочтитk= 7;льнее, чем альтернатиk= 4;ные варианты. Те= 084; не менее, определеннm= 9;е общие элементы присутствуn= 2;т во многих успешных командах. Поэтому важно рассм = 86;треть некую гипотетичеl= 9;кую структуру команды. <o:p></o:p> Руковод= ;ство крупным проектом ПС должны осущ = 77;ствлять один или два лидера – менеджера (см. рис. 9.2): <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>м = 77;неджер проекта = - этот специалист, обеспечиваn= 2;щий коммуникацl= 0;ю между заказчиком = 80; проектной командой, ег= 086; задача -</span= > опредеl= 3;ить и обеспечит= 00; удовлетворk= 7;ние требований = 79;аказчика; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>м = 77;неджер-архи&= #1090;ектор комплекса программ = - управляет коммуникацl= 0;ями и взаимоотн = 86;шениями в проектной команде, явл= 103;ется координатоl= 8;ом создания компонентоk= 4;, разрабатывk= 2;ет базовые, фун= 082;циональные спецификацl= 0;и и управляет = 080;ми, ведет графи = 82; проекта и отчитываетl= 9;я за его состояние, инициирует принятие кр = 80;тичных для хода про= 077;кта решений. <o:p></o:p> В реализации крупного проекта можно выдел = 80;ть две категории с = 87;ециалистов: разрабатывk= 2;ющих компоненты = 80; ПС в целом и обеспечиваn= 2;щие технологию = 80; качество пр = 86;граммного продукта. Организациl= 6;нное разделение специалистl= 6;в, осуществляn= 2;щих разработку ПС (первая категория), и специалистl= 6;в, контролируn= 2;щих и управляющиm= 3; его качеств = 86;м в процессе разработки = 80; всего ЖЦ (вто&#= 1088;ая категория), должно обеспечиваm= 0;ь независимыl= 1;, достоверныl= 1; контроль качества ре = 79;ультатов разработки = 80; эффективноk= 7; достижение заданных характерисm= 0;ик.<o:p></o:p> Специал= ;исты первой категории непосредстk= 4;енно создают компоненты = 80; ПС в целом с заданными показателяl= 4;и качества. В процессе разработки их функции заключаютсn= 3; в тщательно = 84; соблюдении принятой в фирме технологии и в формированl= 0;и всех предпи = 89;анных руководствk= 2;ми исходных и отчетных документов. При этом предполагается, что выбранн = 72;я технология способна обеспечить необходимыk= 7; значения конструктиk= 4;ных показателеl= 1; качества, а достижение заданных фу = 85;кциональны&#= 1093; характерисm= 0;ик гарантируеm= 0;ся тематическl= 6;й квалификацl= 0;ей соответствm= 1;ющих специалистl= 6;в и регулярны = 84; контролем этих характерисm= 0;ик в процессе р= 072;зработки. Система стандартизl= 0;рованного документирl= 6;вания частных работ должн = 72; обеспечить объективноk= 7; отражение качества компонентоk= 4; и процессов и = 93; создания на всех этапах ЖЦ ПС (см. лекц= ию 17). <o:p></o:p></span= > Разделе= ;ние труда специалистl= 6;в этой катего = 88;ии в крупных пр= 086;ектных коллективаm= 3; приводит к необходимоl= 9;ти их дифференциk= 2;ции по квалифик = 72;ции и областям деятельносm= 0;и:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>с = 87;ецификатор&#= 1099; подготавлиk= 4;ают описания функций соответствm= 1;ющих компонентоk= 4; с уровнем детализациl= 0;, доста= ;точным для коррект = 85;ой разработки текстов программ пр = 86;граммистам&#= 1080; и их интерфе= 081;сов;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;зработчики программныm= 3; компонентоk= 4; = - программисm= 0;ы создают компонентm= 9;, удовлетворn= 3;ющие спецификацl= 0;ям, реал= изуют возможностl= 0; продукта, отслеживаn= 2;т и исправляю = 90; ошибки, при разработке сложных систем это требует детального знания высо = 82;оуровневых языков программирl= 6;вания, визуальногl= 6; программирl= 6;вания, сетевых тех = 85;ологий и проектировk= 2;ния баз данных; <o:p></o:= p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>с = 80;стемные интеграторm= 9; сложных проблемно-о = 88;иентирован&#= 1085;ых ПС работают над проектами в значительнl= 6;й степени отличными о = 90; программисm= 0;ов методами, на разных языках прое = 82;тирования, используют различные средства автоматизаm= 4;ии и имеют на вы&#= 1093;оде различные результаты крупных ком = 87;онентов и комплексо = 74; программ;<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>тестировщ&#= 1080;ки обеспечиваn= 2;т проверку функционалn= 0;ных спецификацl= 0;и, систем обеспечениn= 3; производитk= 7;льности, пользоватеl= 3;ьских интерфейсоk= 4;, разрабатывk= 2;ют стратегию, планы и выполняют тестированl= 0;е для каждой и= 079; фаз и компон= 077;нта проекта, должны быть администраm= 0;ивно независимыl= 4;и от программ = 80;стов и специфика = 90;оров; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>у = 87;равляющие сопровождеl= 5;ием и конфигура = 94;ией, инструкторm= 9; интерфейсоk= 4; отвечают за снижение затрат на модификациn= 2; и сопровождеl= 5;ие продукта, обеспечениk= 7; максимальнl= 6;й эффективноl= 9;ти работы разр = 72;ботчиков по взаимодейсm= 0;вию компонентоk= 4; и реализации версий ПС, пр&#= 1080;нимают участие в обсужденияm= 3; пользоватеl= 3;ьского интерфейса = 80; архитектурm= 9; продукта;<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>д = 86;кументатор&#= 1099; процессов и объектов ЖЦ ПС обеспечи = 74;ают подготовку = 80; издание сводных технологичk= 7;ских и эксплуатацl= 0;онных документов = 74; соответствl= 0;е с требовани= 03;ми стандартов.<o:p= ></o:p> Успех и качество пр = 80; разработке сложных про = 75;раммных комплексов все больше з= 072;висит от слаженностl= 0; работы и профессионk= 2;лизма коллектива этой катего = 88;ии специалистl= 6;в на всех этапах и уровнях создания таких проектов. Пр= 080; выборе заказчиком надежного поставщика- = 88;азработчик&#= 1072; проекта необходима оценка тема = 90;ической и технологичk= 7;ской квалификацl= 0;и возможного коллектива специалистl= 6;в, а также его способностl= 0; реализоватn= 0; проект с заданными требованияl= 4;и и качеством. Тематическm= 1;ю квалификацl= 0;ю специалистl= 6;в в области создания ПС определеннl= 6;го функционалn= 0;ного назначения приближеннl= 6; можно харак = 90;еризовать средней про = 76;олжительно&#= 1089;тью работы в данной проблемной области осн = 86;вной части команды, непосредстk= 4;енно участвующеl= 1; в разработк = 77; алгоритмов, = 089;пецификаци&= #1081;, программ и баз данных. Важнейшую роль при это= 084; играет квал = 80;фикация руководитеl= 3;ей – лидеров разработкl= 0; и системных аналитиков функционалn= 0;ных компонентоk= 4; и в меньшей степени непосредстk= 4;енных разработчиl= 2;ов программ в конкретной прикладной области. Особенно важна не индивидуалn= 0;ная характерисm= 0;ика каждого специалистk= 2;, а, прежде всего, интегральнm= 9;й показатель квалификацl= 0;и “команды”, реализующеl= 1; некоторую, достаточно крупную функционалn= 0;ную задачу или весь проект. При низкой тематическl= 6;й квалификацl= 0;и допускаютсn= 3; наиболее гр = 91;бые системные ошибки, требующие больших затрат при доработке программ ил = 80; даже делающие проект практическl= 0; не реализуе = 84;ым.<o:p></o:p> Техноло= ;гическая квалификацl= 0;я коллектива характеризm= 1;ется опытом и дли= 090;ельностью работы с регламентиl= 8;ованными технологияl= 4;и, инструментk= 2;льными комплексамl= 0; автоматизаm= 4;ии разработки, языками проектировk= 2;ния, программирl= 6;вания и тестированl= 0;я ПС. Особое значение имеет коллективнm= 9;й опыт органи = 79;ации и выполнени= 03; сложных проектов на = 073;азе современныm= 3; автоматизиl= 8;ованных технологий = 80; инструментk= 2;льных средств. Опы= 090; применения конкретногl= 6; комплекса автоматизаm= 4;ии и языков проектировk= 2;ния ПС может являться су = 97;ественным фактором пр = 80; выборе технологии для создани= 03; новых компо = 85;ентов и обеспечен = 80;и качества ПС.<o:= p></o:p> В детальной<sp= an style=3D'mso-spacerun:yes'> модели СОСОМО (см. лекцию 5)значительн= 086;е внима-ние уделено влиянию организациl= 0; и взаимодейсm= 0;вия коллектива разра-ботчи = 82;ов на трудоемкосm= 0;ь создания сложных программныm= 3; средств – таблица 9.1. В составе организациl= 6;нных характерисm= 0;ик коллектива реко-мендуе = 90;ся учитывать согласованl= 5;ость целей специалистl= 6;в, участвующиm= 3; в проекте, их психологичk= 7;скую совместимоl= 9;ть и способностn= 0; к дружной коллективнl= 6;й работе, наличие опыта работ = 99; в данном коллективе = 80; другие объективныk= 7; и субъектив = 85;ые свойства участников проекта. При этом большо = 77; значение может иметь личная моти = 74;ация и психологичk= 7;ские особенностl= 0; поведения разных специалистl= 6;в при комплек = 89;ной работе над сложным проектом. Эт= 080; характерисm= 0;ики могут быть обобщены в качес-твенн = 99;й показатель влияния сложности взаимодейсm= 0;вия специалистl= 6;в в коллектив = 77;, которому сопоставлеl= 5;ы коэффициенm= 0;ы изменения трудо= ;ем-кости разработки ПС (последня= 103; строка в таблице 9.1). Наилучшим счита-ется непрерывноk= 7; корректное взаимодейсm= 0;вие организоваl= 5;ных специали-ст = 86;в с большим опытом работы в данном колл = 77;ктиве при полной согласо-ван = 85;ости их целей, планов и методов работы. В остальных случаях в то= 081; или иной степени (даж= 077; в 3 – 5 раз) може = 90; возрастать трудоемкосm= 0;ь разра-ботки ПС, что нельзя не учитывать при прогноз = 80;ровании ТЭП и обоснова-ни = 80; разработки крупных проектов. <o:p></o:p> Специ= алисты второй категории = - технологи, обслуживаюm= 7;ие и сопровожд = 72;ющие технологичk= 7;ский инструментk= 2;рий, который при = 84;еняется специалистk= 2;ми первой категории, о= 073;еспечивают применение системы кач = 77;ства проекта или предприятиn= 3;, контролируn= 2;т и инспектир = 91;ют ее использо = 74;ание (см. рис. 9.2). Осно&= #1074;ные задачи второй категории специалистl= 6;в должны быть сосредоточk= 7;ны на контроле процессов и результатоk= 4; выполнения работ и на принятии организациl= 6;нных и технологи = 95;еских мер для достижения их необходимоk= 5;о качества, обеспечиваn= 2;щего выполнение всех требов = 72;ний техническоk= 5;о задания на ПС.<o:p></o:p> Технологи должны выбирать, пр= 080;обретать и осваивать наиболее эффективныl= 1; инструментk= 2;рий для проекто = 74;, реализуемыm= 3; конкретной фирмой с уче= 090;ом особенностk= 7;й создаваемыm= 3; ПС требуемо = 75;о качества и рентабельнl= 6;сти технологичk= 7;ских средств. Они должны разрабатывk= 2;ть регламентиl= 8;ованный технологичk= 7;ский процесс и систему качества, поддерживаn= 2;щие весь ЖЦ ПС и обучать разработчиl= 2;ов ПС квалифицирl= 6;ванному применению соответствm= 1;ющих инструментk= 2;льных средств и технологий. <o:= p></o:p> Специал= ;исты, управляющиk= 7; обеспечениk= 7;м качества ПС, должны овладеть стандартамl= 0; и методикам = 80; фирмы, поддерживаn= 2;щими регистрациn= 2;, контроль, документирl= 6;вание и воздейств = 80;я на показатели качества на всех этапах ЖЦ программ. Они должны обеспечиваm= 0;ь эксплуатацl= 0;ю системы качества проекта, выя= 074;ление всех отклонений от заданных = 087;оказателей качества объектов и процессов, а также от предписаннl= 6;й технологии на промежут = 86;чных и заключителn= 0;ных этапах разработки. Эти же специ= 072;листы должны анализировk= 2;ть возможные последствиn= 3; выявленных = 86;тклонений от требований техническоk= 5;о задания или спецификацl= 0;и на ПС. В результате должны приниматьсn= 3; меры либо по устранению отклонений, либо по корректироk= 4;ке требований, если устранение отклонений требует чре = 79;вычайно больших ресурсов. <o:p></o:p></span= > Инспекторm= 9;-испытатели по проверке систем качества пр = 77;дприятия и качества п= 088;ограммных продуктов должны пройти обуч = 77;ние, дающее им знания и квалификацl= 0;ю, необходимыk= 7; для проведения испытаний, оценки их результатоk= 4; и эффективноl= 9;ти применения систем каче = 89;тва. Для них (см. ISO 10011-2) необх= 086;димыми считаются знание и понимание стандартов = 80; нормативныm= 3; документов, = 074; соответствl= 0;и, с которыми должны осуществляm= 0;ься оценки применения = 89;истем качества, а также обследованl= 0;е, анкетироваl= 5;ие и составлен = 80;е отчетов по испытаниям. Инспектор-э = 82;сперт, в соответст = 74;ии со стандартом, должен быть непредубежk= 6;енным; обладать зд = 88;авым смыслом; иметь аналитичесl= 2;ий склад ума и твердость воли; обл = 72;дать способностn= 0;ю реально оценивать сложные действия с точки зрени= 03; их дальнейшей перспективm= 9; в рамках общ= 077;й организациl= 6;нной структуры:<o:p></o:p>= <![if= !supportLists]>-&nb= sp; = <![endif]>получат= ;ь и справедливl= 6; оценивать объективныk= 7; данные испы = 90;аний характерисm= 0;ик продуктов и систем качества пр = 80; незаинтереl= 9;ованном проведении = 87;роверок;<o:p></o:p> <![if= !supportLists]>-&nb= sp; = <![endif]>относит= ;ься к персоналу системы качества, по= 076;вергающему&= #1089;я проверке, таким образом, что= 073;ы получить наилучшие результаты;<o:p= ></o:p> <![if= !supportLists]>-&nb= sp; = <![endif]>приходи= ;ть к приемлемы = 84; для разработчиl= 2;ов и заказчика выводам, основанным на реальных наблюденияm= 3; в процессе испытаний характерисm= 0;ик качества ПС.<o:= p></o:p> Пере = 95;исленные выше специализаm= 4;ии и квалифика = 94;ии персонала, участвующеk= 5;о в крупных проектах ПС, требуют соответствm= 1;ющей их подготов = 82;и, отбора и непрерывноk= 5;о обучения, которые являются самостоятеl= 3;ьной, важной проблемой проектировk= 2;ния и всего ЖЦ комплексов программ. Обучение представляk= 7;т собой процесс и требует организациl= 0; и сопровожд = 77;ния обучаемого персонала. Должны быть разработанm= 9; и документи = 88;ованы планы, требования = 80; цели обучения, а также разработанm= 9; руководствk= 2;, включая материалы, используемm= 9;е для обучения (см. ше= 089;тую часть стандарта ISO<= span style=3D'font-size:14.0pt'> 15504). Персонал, ответственl= 5;ый за выполнен = 80;е конкретных задач, если это необход = 80;мо, должен быть аттестован на основе соответствm= 1;ющего образованиn= 3;, подготовки и/или опыта работы. Може= 090; также стать необходимыl= 4; включение в подготовку, ознакомленl= 0;е со специфич = 77;ской (проблемно-о= 088;иентирован&= #1085;ой) областью, в которой будет работ = 72;ть данное прог = 88;аммное средство, и повышение квалификацl= 0;и в этой области. Требования = 82; квалификацl= 0;и, обучению персонала и их реализац = 80;и должны быть документалn= 0;но оформлены в системном п = 88;оекте. <o:p></o:p> = Совещани= ;я предоставлn= 3;ют заинтересоk= 4;анным специалистk= 2;м из различны = 93; команд и организациl= 1; возможностn= 0; работать вм = 77;сте над достиже = 85;ием общей цели крупного проекта. Надлежащаn= 3; подготовка является залогом успеха совещаний. Первым дело = 84; необходимо распростраl= 5;ить идею внутри организациl= 0;, разъясняя преимущестk= 4;а проведения = 89;овещаний членам команды. Подготовка включает в себя также выявление заинтересоk= 4;анных лиц, которые могут повлиять на процессы ЖЦ ПС и чьи потребностl= 0; необходимо учесть, чтоб= 099; гарантировk= 2;ть успешный результат. <o:p></o:p= > Необ= ходимо заранее разослать подготовитk= 7;льные материалы, чтобы подго = 90;овить участников, = 072; также повысить производитk= 7;льность проводимогl= 6; совещания. Подготовитk= 7;льные материалы должны стимулировk= 2;ть как конкретное, так и свободное мышление. Для гk= 2;рантии успеха рекомендуеm= 0;ся, чтобы совещ = 72;ние проводилосn= 0; сторонним человеком, имеющим опы = 90; в решении уникальных = 79;адач управления. Если совещание проводится членом команды, это= 090; человек вначале не должен= вносить свои идеи и участвоватn= 0; в обсуждени = 80;. Иначе существует опасность, что совещание утратит, необх= ;одимую для получен = 80;я реальных фактов объе = 82;тивность и не будет способствоk= 4;ать созданию атмосферы, в которой мож = 85;о достигнуть консенсуса. = 042; любом случа = 77; специалист, = 074;едущий встречи играе= ;т ключевую роль в успех= 077; совещания и должен:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>у = 89;тановить правила проведения встречи и до= 073;иваться их выполнен = 80;я;<o:p></o:p> <![if !supportLists]>- = ; <![endif]>управлят&= #1100; течением дискуссии и удерживать команду на главной цел = 80; совещания;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 87;особствова&#= 1090;ь процессу принятия решения и до= 089;тижения консенсуса, но избегать участия в содержателn= 0;ной части диску = 89;сии;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 76;остоверить&#= 1089;я, что все заинтересоk= 4;анные лица участвуют и их пожелани= 03; учтены;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;нтролирова&#= 1090;ь поведение участников, которое может приве = 89;ти к расколу ил= 080; мешает прод = 91;ктивной работе.<o:p></o:p> Следует активно привлекать заказчиков = 82; совещаниям, управлению их требован = 80;ями и масштабом проекта, чтобы обеспечить как качеств = 86;, так и своевр= 077;менность разработки ПС. Именно заказчики несут финан = 89;овую ответственl= 5;ость за выполнение внешних обязательсm= 0;в перед пользоватеl= 3;ями. Необходимы указания заказчиков при приняти = 80; основных решений, и только они могут реально опр = 77;делить, как, сократи= 074; функции ПС, п&#= 1086;лучить полезный комплекс пр = 86;грамм высокого качества, выполненныl= 1; в срок и в пределах бюджета. Исключенныl= 1; из процесса принятия решений заказчик бу = 76;ет недоволен и, естественнl= 6;, будет стремиться обвинить разработчиl= 2;ов в недостаточl= 5;ой старательнl= 6;сти. Привлечениk= 7; заказчика помогает наименее болезненно решить проблемы управления масштабом и функциями проекта. <o:p></o:p> Для защиты, как проекта, та= 082; и бизнес- = 94;елей заказчика может понад = 86;биться вести переговоры об объеме работ для команды. Во время перег = 86;воров с заказчико = 84; о техническ = 86;м задании и требованияm= 3; базового ур = 86;вня следует l= 8;уководство= 074;аться принципом меньше обещ = 72;ть и больше делать. Тогд= 072; неизбежные издержки разработки ПС (непредви= 076;енные технологичk= 7;ские риски, изменения требований, задержки пр = 80; приобретенl= 0;и закупаемых компонентоk= 4;, непредвидеl= 5;ный уход основных членов кома = 85;ды и т.п.) не приведут к нарушению графика ваш = 77;го проекта. Однако зака = 79;чики, внешние или внутренние, естественнl= 6; желают получить ка = 82; можно больш = 77; функционалn= 0;ных возможностk= 7;й в каждой версии ПС. Именно эти функционалn= 0;ные возможностl= 0; создают добавленнуn= 2; стоимость, которая важна им для достижения их бизнеl= 9;-целей. Следует с пониманием = 86;тноситься к требованияl= 4; клиентов, поскольку именно они, в конечном сч = 77;те, добиваются успеха на рынке. Однак= 086; если пойти на встреч = 91; требованияl= 4; заказчика повышения функционалn= 0;ности, это может негативно сказаться н = 72; качестве и общей жизнеспосоk= 3;ности проекта. <o:p></o:p> Обычно наиболее важным для р= 077;ализации проекта ПС и завl= 0;сящим от больш= ;инства его особенностk= 7;й и факторов является тl= 8;удоемкость,<s= pan style=3D'mso-spacerun:yes'> непос= ;редственно определяющk= 2;я стоимость</spa= n> создаваемl= 6;го комплекса программ. Значения длительносm= 0;и разработки = 80; числа специалистl= 6;в взаимосвязk= 2;ны и в некоторы= 093; пределах могут размениватn= 0;ся. Поэтому оценки этих показателk= 7;й затрат можно варьироватn= 0;, и при недост= 072;точном числе специалистl= 6;в естественнl= 6; возрастает длительносm= 0;ь разработки, хотя трудое = 84;кость может остаться практическl= 0; неизменной. Многократl= 5;ое применение = 86;дних и тех же апробироваl= 5;ных компонентоk= 4; и/или адаптация П = 57; к различным условиям применения является од = 85;им из перспективl= 5;ых методов повышения качества и снижения затрат труд = 72; специалистl= 6;в в жизненном цикле сложных комплексов программ.<o:p></o:p>= <o:p></o:p= > <h1><a name=3D"_Toc508102482"></a><a name=3D"_Toc508102255">9.3. Ресурсы для обеспечениn= 3; функционалn= 0;ной приго= ;дности при рk= 2;зработке сложных программныm= 3; средств</a> </h1> <o:p> </o:p> При проектировk= 2;нии ПС необходимо учитывать, что экономи = 95;еские, временные, вычислителn= 0;ные и другие ресурсы на разработку = 80; весь ЖЦ прог= 088;амм всегда ограниченнm= 9; и используемm= 9;е затраты для улучшения каждой характерисm= 0;ики должны учитывать эти ограничениn= 3;. Для рациона = 83;ьного распределеl= 5;ия этих ресурс = 86;в необходимо знать как от= 088;ажается изменение затрат на улучшении к = 72;ждой характерисm= 0;ики качества ПС. Эта взаимос = 74;язь затрат ресурсов и значений каждой хара = 82;теристики зависит от назначения, = 072; также от ряд= 072; свойств и других особенностk= 7;й комплекса программ, чт= 086; усложняет учет влияни= 03; таких связе = 81;. Тем не менее,<s= pan style=3D'mso-spacerun:yes'> выявл= ;ены основные те = 85;денции такого взаимодейсm= 0;вия, которые мог = 91;т служить ориентирамl= 0; при выборе и установленl= 0;и требований = 82; определеннm= 9;м характерисm= 0;икам качества в конкретных проектах ПС. <o= :p></o:p> Обеспеч= ;ение функционалn= 0;ной пригодностl= 0; является ос = 85;овной целью при использоваl= 5;ии финансовых, трудовых, вычислителn= 0;ных и других ресурсов в жизненном цикле ПС. Одн&#= 1072;ко это не значит, что затраты на р= 077;шение этой основной задачи всегда являются до = 84;инирующими по величине. Необходимоl= 9;ть выполнения ряда требований = 82; остальным, к= 086;нструктивн&= #1099;м характерисm= 0;икам качества, ча= 089;то приводит к тому, что исп&#= 1086;льзование ресурсов на их реализацию может превышать б = 72;зовые затраты на обеспечениk= 7; функционалn= 0;ной пригодностl= 0;. В то же время, затраты на выполнение этих требований, всегда напр = 72;влены на повышени = 77; и совершенс = 90;вование функционалn= 0;ной пригодностl= 0;. Поэтому обычно трудно четк = 86; выделить и количествеl= 5;но оценить все виды затрат = 99;, используемm= 9;е только на функционалn= 0;ную пригодностn= 0;. <o:p></o:p> В любом прогр = 72;ммном средстве можно выделить компоненты, = 074; которых сосредоточk= 7;ны функционалn= 0;ные алгоритмы и программы, предназначk= 7;нные для решения основных целевых задач ПС. В некоторые и = 79; них органическl= 0; входят компоненты для повышен = 80;я качества решения фун = 82;циональных задач или он= 080; построены с учетом требований = 74;ысокого качества результатоk= 4; основных функций. Для анализа затрат ресурсов в ж= 080;зненном цикле ПС при проектировk= 2;нии, их целесообраk= 9;но разделить н = 72; две части:<o:p></o:p></span= > <p class=3DMsoBodyTextIndent2 style=3D'margin:0cm;margin-bottom:.0001pt;tex= t-align: justify;text-indent:35.45pt;line-height:normal;mso-pagination:none;mso-list: l135 level1 lfo141;tab-stops:list 14.2pt'><![if !supportLists]>- &nb= sp; <![endif]>з = 72;траты на создание программныm= 3; компонентоk= 4;, обеспечиваn= 2;щих базовые свойства функционалn= 0;ной пригодностl= 0; комплекса п = 88;ограмм для его прим= 077;нения по прямому назначению пользоватеl= 3;ями, в соответст = 74;ии с требованияl= 4;и контракта и техническоk= 5;о задания;<o:p></o:p> <p class=3DMsoBodyTextIndent2 style=3D'margin:0cm;margin-bottom:.0001pt;tex= t-align: justify;text-indent:35.45pt;line-height:normal;mso-pagination:none;mso-list: l135 level1 lfo141;tab-stops:list 14.2pt'><![if !supportLists]>- &nb= sp; <![endif]>о = 89;новные составляющl= 0;е дополнителn= 0;ных затрат, обеспечиваn= 2;щие требуемые конструктиk= 4;ные характерисm= 0;ики качества дл= 03; улучшения функционалn= 0;ной пригодностl= 0; ПС в соответствl= 0;и с целями и сферой его применения. <o:p></o:p> Кр= оме того, следуе= 090; учитывать совокупносm= 0;ь затрат ресурсов на технологию, = 080;нструмента&= #1088;ий автоматизаm= 4;ии разработки = 80; систему качества, обеспечиваn= 2;щие жизненный цикл ПС. Эта составляющk= 2;я затрат зависит не только от характерисm= 0;ик проектируеl= 4;ого ПС, но и от интенсивноl= 9;ти применения технологичk= 7;ских средств (см. рис. 9.1). = <o:p></o:p> За= траты на обеспечениk= 7; функционалn= 0;ной пригодностl= 0; зависят, в первом приближениl= 0;, от сложност = 80; алгоритмов, объема комп = 83;екса программ и баз данных, которые опр = 77;деляют затраты труда и длительносm= 0;ь полного цикла их разработки. Основные затра= ;ты идут на овеществлеl= 5;ный, преимущестk= 4;енно, интеллектm= 1;альный труд специа = 83;истов различных категорий. Поэтому для иm= 3; измерения наиболее универсальl= 5;ой единицей ст = 72;ли трудозатраm= 0;ы специалистl= 6;в в человеко-дн= 03;х или человеко-ме = 89;яцах, которые обычно дост = 72;точно просто могу = 90; преобразовm= 9;ваться в стоимость процесса разработки. <o:= p></o:p> &nb= sp; Для учета классов крупномасшm= 0;абных ПС с позиции затрат на их разработку проведено ранжированl= 0;е эксперименm= 0;альных данных и выд= 077;лены классы (см. ISO<= span style=3D'font-size:14.0pt'> 12182), наиболее сильно отличающиеl= 9;я затратами н = 72; функционалn= 0;ную пригодностn= 0;, при одном и том же общем размере пол = 85;остью новых программ и информации баз данных, которые характеризm= 1;ются (см. лекцию 5):<o:p></o:p><= /span> <![if !supportLists]>- &nb= sp; <![endif]>м = 72;ксимальной трудоемкосm= 0;ью - ПС систем управления динамическl= 0;ми объектами или процессами = 74; реальном време= ;ни (СРВ);<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 88;едней трудоемкосm= 0;ью - ПС администрk= 2;тивных, организациl= 6;нных и инфор= ;мационно-по= 080;сковых систем (ИПС);<o:p></o= :p> <![if !supportLists]>- &nb= sp; <![endif]>м = 80;нимальной трудоемкосm= 0;ью созда= ;ния - пакеты автономных расчетных п = 88;икладных программ (ППП).<o:p></o:p> Все остальные типы ПС могу= 090; быть упорядоченm= 9; между выдел = 77;нными классами и для них получен = 99; оценки изменения трудоемкосm= 0;и (стоимости) относительl= 5;о максимальнl= 6;й для ПС реального в = 88;емени. Малые проекты, создаваемыk= 7; небольшими коллективаl= 4;и специалистl= 6;в характеризm= 1;ются большим коэффициенm= 0;ом вариации – разбросом значений п = 88;едполагаем&#= 1086;й трудоемкосm= 0;и, вследствиk= 7; высокой рол = 80; индивидуалn= 0;ных способностk= 7;й отдельных специалистl= 6;в. Трудоемкосm= 0;ь разработки крупномасшm= 0;абных ПС объемом с= 074;ыше 100 тыс. строк отражается более определеннm= 9;ми закономернl= 6;стями и стабильнымl= 0; значениями, что обусловленl= 6; усреднениеl= 4; творческих возможностk= 7;й специалистl= 6;в и условий их труда в больших коллективаm= 3;, а также возрастаниk= 7;м доли затрат = 080; роли руково = 76;ящего и вспомогатеl= 3;ьного персонала в ЖЦ ПС.<o:p></o:p> Основные составляющl= 0;е дополнителn= 0;ных затрат, обеспечиваn= 2;щие требуемые х = 72;рактеристи&#= 1082;и качества ПС целесообраk= 9;но структурирl= 6;вать в соответст = 74;ии с их номенкл= 072;турой в стандарте </s= pan>ISO<= span style=3D'color:windowtext'> 9126 (см. лекцию 11). Однако желательно эти затраты связать с процессами ЖЦ ПС. Важней&#= 1096;ее значение имеет устан = 86;вление и формализацl= 0;я исходных требований = 82; характерисm= 0;икам ПС. По= 01;тому целесообраk= 9;но выделять значительнm= 9;е ресурсы на системный анализ и про= 077;ктирование требований ко всему комплексу х = 72;рактеристи&#= 1082; и их атрибут= 099; на начальны = 93; этапах проекта ПС (см. рис. 9.1). На этих этапах неопределеl= 5;ность оценки влияния факторов наибольшая, тем не менее даже приблизитеl= 3;ьный их учет позволяет избегать грубых ошибок (в несколько раз) при оцен&#= 1082;е затрат на разработку, = 082;оторые делаются экспертами без детального анализа влияния различных факторов на = 090;ребуемое качество ПС. Подобный анализ може = 90; быть базой для рациона = 83;ьного, первичного распределеl= 5;ия ограниченнm= 9;х ресурсов разработки = 80; для управле = 85;ия их использоваl= 5;ием по мере разв= 080;тия проекта. Уче= 090; возможного = 80;зменения затрат в зависимостl= 0; от основных = 087;араметров проекта способствуk= 7;т упорядоченl= 0;ю процесса разработки ПС и концент= 088;ации усилий на те= 093; факторах и затратах, ко= 090;орые могут дать максимальнm= 9;й эффект в повышении качества, пр= 080; конкретных условиях со = 79;дания программ и реальных ограничениn= 3;х ресурсов. <o:p></o:p></span= > После проведения системного = 87;роектирова&#= 1085;ия, а также пред= 074;арительног&= #1086; распределеl= 5;ия ресурсов, возможна ошибка в оце= 085;ке совокупных затрат на разработку ПС с требуемым к = 72;чеством, приблизитеl= 3;ьно в полтора-дв= 072; раза. Разработка архитектурm= 9; комплекса п = 88;ограмм на основе прототипов = 80; подготовка = 82; программиl= 8;ованию готовых апр = 86;бированных алгоритмов позволяет е = 77; уменьшить д = 86; 20-30%. Такую достоверноl= 9;ть можно получить, ко= 085;ечно, только при п= 086;дробном анализе и оценке влия = 85;ия важнейших факторов и требований = 82; качеству конкретногl= 6; ПС (см. лекцию = 5).<o:p></o:p> Крупные затраты, достигающиk= 7; 30% от полных затрат на разработку сложных ПС, могут приходитьсn= 3; на верифика = 94;ию и тестированl= 0;е программныm= 3; компонентоk= 4;, что должно обеспечиваm= 0;ь корректносm= 0;ь и надежност= 00; ПС в целом. Хотя эти характерисm= 0;ики и их атрибут= 099; принципиалn= 0;но различаютсn= 3;, ресурсы на и= 093; реализацию полностью разделить н = 77;возможно. Поэтому оценивание = 80; выделение р = 77;сурсов на решение этих задач целесообраk= 9;но анализировk= 2;ть совместно. <o:p></o:p= > Затраты на квалификацl= 0;онное тестированl= 0;е и испытания ПС в целом обычно могу = 90; быть достаточно четко выделены из остальных ресурсов, та= 082; как в этих процессах непосредстk= 4;енно участвуют заказчик и пользоватеl= 3;и. Величина этих затрат, без учета ре= 089;урсов, необходимыm= 3; для имитаци = 80; внешней среды, может составлять около 10% от общих затра = 90; на разработ = 82;у. При этом практическl= 0; невозможно разделять затраты на о= 094;енивание отдельных стандартизl= 0;рованных характерисm= 0;ик и их атрибут= 086;в. <o:p></o:p> Затраты на обеспечениk= 7; безопасносm= 0;и и надежност = 80; функционирl= 6;вания ПС определя= 02;тся требуемым уровнем защищенносm= 0;и и сложность= 02; (размером) программ дл= 03; ее реализац = 80;и (см. лекцию 11). При наличии осо = 73;енно высоких требований = 82; безопасносm= 0;и критическиm= 3; ПС эти затра= 090;ы могут даже в 2 – 4 раза превышать затраты на решение базовых, функционалn= 0;ных задач. Для типовых администраm= 0;ивных систем труд = 86;емкость создания программныm= 3; средств защиты обыч = 85;о составляет 20 – 40% затрат на решение основных, функционалn= 0;ных задач. В более прос = 90;ых случаях, доля таких затра = 90; может снижа = 90;ься до 5 – 10%.= Затраты на = 086;беспечение высокой надежности в составе ра = 79;работки ПС могут достигать 2 – 3 кратного увеличения общих затрат, при высок= ;их требованияm= 3; наработки н = 72; отказ. Для ми&#= 1085;имального обеспечениn= 3; автоматичеl= 9;кого рестарта в о= 088;динарных системах он = 80; составляют порядка 10 – 20%. Однак= ;о практическl= 0;, в любых сист= 077;мах должен присутствоk= 4;ать минимум про = 75;раммных компонентоk= 4;, обеспечиваn= 2;щих надежность = 80; защиту от пр= 077;днамеренны&= #1093; и слуm= 5;айных угроз.<o:p></o:p> <s= pan style=3D'mso-no-proof:yes'>Затраты= ; на создание доста= точно полного </spa= n>комплект= ;а докумен- тации= практичесl= 2;и пропо= рциональны размеру комплекса = 87;рограмм= ;. Удель= ные затра= ты на документацl= 0;ю завис= ят от класса, = 85;азначен= ;ия и широты l= 7;рименен= ;ия прогр= амм, что тр= ;удно учест= ь в достаточ= ;но общем= виде. Эти затраты сопутств= ;уют в некоторой = 89;тепени </spa= n>всем этапа= м разра= ботки, однак= о, оформ= ление эксплуатацl= 0;онных доку- менто= в обычн= о локал= изуется в спец= и-альном э= тапе работ. Затраты на разработ= ;ку комплекта эксплуатаци= 086;нной докум= ентации для </span= >сложных программныm= 3; продуктов , подле= жащих дл&= #1080;-тельному</spa= n> с= опровожденl= 0;ю, обычн= о опред= еляются затра= тами ориентир-ов = 86;чно 5 – 10 страниц </spa= n>на тысячу строк текст= а прогр= аммы. <o:p></o:p> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-align:justify;text-inden= t: 35.45pt;line-height:normal'>Достато= 095;но определеннl= 6; могут быть выделены и оценены зат = 88;аты на обеспече = 85;ие и реализаци= 02; требований = 82; характерисm= 0;икам: защищенносm= 0;и, сопровоk= 8;даемости, мобильностl= 0; и практичносm= 0;и (последние в части документирl= 6;вания) ПС. Эти затра&#= 1090;ы состоят из двух связанных частей: затр= 072;т на реализацию соответствm= 1;ющих характерисm= 0;ик качества в программныm= 3; продуктах и затрат при и= 089;пользовани&= #1080; этих характерисm= 0;ик в процессе эксплуатацl= 0;и комплекса программ. Обычно совершенстk= 4;ование качества и повышение затрат на реализацию = 93;арактерист&#= 1080;к способствуk= 7;т снижению затрат при и= 093; эксплуатацl= 0;и. Последние трудно оцен = 80;ть априори, так как они зависят от внешней сре = 76;ы и активност = 80; применения конкретногl= 6; ПС, а не от его свойств и требуемого качества. Поэтому дал = 77;е основное внимание акцентировk= 2;но на затратах, которые необходимы для достиже = 85;ия требуемых характерисm= 0;ик качества. <o:p></o:p></span= ></h2> При анализе затрат на обеспечениk= 7; требуемых функций крупномасшm= 0;абных ПС доминиру= 02;щим фактором, влияющим на их величину, является сложность ф = 91;нкциональн&#= 1086;й части комплекса программ и базы данных.<sp= an style=3D'mso-spacerun:yes'> Понятие сложности программ ак = 90;ивно исследовалl= 6;сь последние д = 77;сятилетия, и предложен ряд показат = 77;лей и методов дл= 103; ее измерени= 03;. Наибольшее внимание исследоватk= 7;лей привлекала статистичеl= 9;кая мера сложно = 89;ти и мера структурноl= 1; сложности программ. Дл= 103; относительl= 5;о небольших программ эт = 80; методы позволили повысить достоверноl= 9;ть определениn= 3; сложности программ и установить адекватносm= 0;ь этого показ = 72;теля величине трудоемкосm= 0;и их создания. Однако для П= 057; средней и вы= 089;окой сложности ряд дополнителn= 0;ных факторов затрудняет подобные оц = 77;нки. В крупныm= 3; ПС обычно реал = 80;зуются задачи различной сложности. При наличии особо сложной функционалn= 0;ной задачи возрастаниk= 7; затрат на ее реализацию = 84;ожет нивелироваm= 0;ься рядом други = 93; типовых и более простых задач. Поэтому пок = 72; не проявили = 89;ь преимущестk= 4;а приведенныm= 3; мер сложнос = 90;и и они не нашли широкого практическl= 6;го применения.<o:p= ></o:p> = Наиболее активно в качестве простейшегl= 6; показателя сложности используетl= 9;я размер – масштаб комплекса п = 88;ограмм, выраженный числом операторов (команд) или строк текст = 72; на языке программирl= 6;вания (с учетом коэффициенm= 0;а, зависящего от класса ПС и специфики языка) (см. лекцию 5). Размер про = 75;рамм без комментариk= 7;в является од = 85;ой из наиболее достоверно измеряемых = 93;арактерист&#= 1080;к сложности П = 57; и достаточн = 86; адекватен экономичесl= 2;им затратам на его разрабо = 90;ку. Реальное изменение создаваемыm= 3; в настоящее время новых сложных ПС объемом от 103</= sup> до 106 строк определяет диапазон трудоемкосm= 0;и разработки таких программ от человеко-го = 76;а до тысяч человеко-ле = 90;. С друk= 5;ой стороны, отсутствуюm= 0; какие-либо данные о значительнl= 6;м преимущестk= 4;е других дост = 72;точно простых мер сложности при прогнозироk= 4;ании ресурсов на разработку крупномасшm= 0;абных ПС. <o:p></o:p> Ограниченl= 5;ые ресурсы вре = 84;ени реализации проектов ПС являются одним из самых сильных факторов, влияющих на достижимое качество комплексов программ. Из= 073;ыточный оптимизм многих разработчиl= 2;ов и давление заказчиков относительl= 5;о сроков реализации контрактов на ПС, негативно отражается, прежде всег = 86;, на характерисm= 0;иках качества ПС. Поэтому при выборе и формализацl= 0;и в контракте значений требуемых характерисm= 0;ик качества ПС, особое вним = 72;ние следует обращать на возможностn= 0; их достигну = 90;ь в согласова = 85;ные сроки. Чем сложнее комплекс программ, а с&#= 1086;ответствен= но, чем выше в нем вероятностn= 0; ошибок и деф= 077;ктов, тем больше времени требуется для их устранения = 80; на весь процесс разработки. При реальном допустимом времени реализации проекта, оно ограничиваk= 7;т затраты на все промежуточl= 5;ые этапы работ, и тем самым на качество их выполнен = 80;я. <o:p></o:p> Пр= и современныm= 3; технологияm= 3; полностью н = 86;вые, крупномасшm= 0;абные комплексы программ, реализуемыk= 7; в допустимо = 77; время= ; 2 – 4 года, ограничены объем= ;ом 106 = - 10 7 стро= 082; текста. Выше отмечалось (см. лекцию 5), что диапазону размеров со = 74;ременных ПС в три-четыре порядка (до 10 млн. строк) соответствm= 1;ют приблизитеl= 3;ьно такие же диапазоны изменения трудоемкосm= 0;и и стоимости их разработ = 86;к. Очевидна принципиалn= 0;ная нерентабелn= 0;ность разработки очень сложн = 99;х ПС за= 5 -</span= > 10 лет. С другой стороны, даж= 077; относительl= 5;о небольшие программы высокого качества в несколько тысяч строк по полному технологичk= 7;скому циклу с сертификацl= 0;онными испытаниямl= 0; продукции = 88;едко создаются з = 72; время, меньшее, чем полгода = - год. Таким образом, диапазон вариации длительносm= 0;ей разработок ПС много меньше, чем вариация их трудоемкосm= 0;и, а эти длител= 100;ности ограничены сверху и снизу, и объем новых программ яв = 83;яется одним из осн= 086;вных факторов, определяющl= 0;м эти границы.<o:= p></o:p> Размер баз = 99; данных ПС в некоторой с = 90;епени коррелировk= 2;н с размером текстов программ. Эт= 086; привело к тому, что в ряде эконом = 80;ческих исследованl= 0;й размер базы данных либо совсем не учитывался, либо включа = 83;ся в объем ПС. В статистичеl= 9;кой теории слож = 85;ости программ показано, чт= 086; для программныm= 3; модулей и относительl= 5;о небольших групп программ имеется корреляция числа имен переменных = 80; операторов = 74; программе. О= 076;нако для крупl= 5;ых ПС корреляц = 80;я может быть меньше. Это определило необходимоl= 9;ть разделения ПС на два типа: на осущ&#= 1077;ствляющие преимущестk= 4;енно сложную логическую обработку о = 90;носительно небольшого = 87;отока данных и на информациоl= 5;но-поисковы&#= 1077; системы при наличии бол= 00;ших объемов информации баз данных и <s= pan class=3DGramE>при относительl= 5;о простой их обработк = 77;. Степень этого влияния тру = 76;но формализовk= 2;ть, так как большую рол= 00; играет структура базы данных = 080; ее функционалn= 0;ное назначение. = 055;оэтому обычно этот фактор отдельно не учитываетсn= 3; и только для очень больших и сложных структур ба = 79; данных рекомендуеm= 0;ся увеличиватn= 0; оцениваемуn= 2; трудоемкосm= 0;ь разработки.<o:p= ></o:p> = <o:p></o:p> <h1> = <a name=3D"_Toc508102483"></a><a name=3D"_Toc508102256">9.4.&= nbsp; Ресурсы на реализациn= 2; конструктиk= 4;ных характерисm= 0;ик качес= ;тва программныm= 3; средств</a> </h1> <o:p> </o= :p> Им= еющийся опыт показывает, что кроме функционалn= 0;ной пригодностl= 0; и мобильнос = 90;и большинствl= 6; факторов может изменять тр = 91;доемкость процессов разработки программ на десятки про = 94;ентов и не более чем в 2 -</span= > 3 раза. Приводимыk= 7; ниже экспертные = 86;ценки относятся = 82; разработке полностью нового, круп= 085;ого ПС, без использоваl= 5;ия готовых про = 75;раммных компонентоk= 4;. Эти оценки могут служи = 90;ь ориентирамl= 0;, которые должны напо = 84;инать разработчиl= 2;ам, что каждое повышение требований = 82; качеству ПС реализуемо за счет дополнителn= 0;ных ресурсов, которые могут быть с= 086;измеримыми или даже превышать затраты на р= 077;шение основных, функционалn= 0;ных задач. = <o:p></o:p> = Анализ затрат на обеспечениk= 7; корректносm= 0;и зависит от полноты прослеживаl= 5;ия реализации требований = 82; ПС сверху вн= 080;з, в требовани= 03;х к компонент = 72;м вплоть до объектного кода программ и о= 090; степени их п= 086;крытия тестами. Эти затраты входят непо = 89;редственно в процесс разработки = 80; зависят от объема и дет= 072;льности процессов верификациl= 0; и тестирова = 85;ия. Для с= ;ложных ПС при требовании их высокой корректносm= 0;и они могут составлять = 76;о 30% от затрат на обеспечениk= 7; первичной, функционалn= 0;ной пригодностl= 0;. Для относительl= 5;о простых комплексов программ эт = 72; величина в среднем не превышает 20%.<o:p></= o:p> = Затраты на взаимодейсm= 0;вие программныm= 3; средств и их компонентоk= 4; с внутренне = 81; и внешней средой определяютl= 9;я сложностью (объемом) программ и затратами производитk= 7;льности ЭВМ, реализу= 102;щими эти функции. Они включаю = 90; затраты на визуализацl= 0;ю информации, обеспечиваn= 2;щей функционалn= 0;ную пригодностn= 0;, телекоммунl= 0;кацию с внешними абонентами системы и с операционнl= 6;й системой и могут соста = 74;лять 10 – 20% затрат на обеспечениk= 7; основных функций ПС.<o:p></o:p= > <s= pan style=3D'mso-spacerun:yes'> Особенносm= 0;и затрат на реализацию остальных требований = 82; конструктиk= 4;ным характерисm= 0;икам качества отмечаются при предста = 74;лении соответствm= 1;ющих характерисm= 0;ик (см. лекцию 11) и сво= ;дятся к следующем = 91;:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>д = 86;полнительн&#= 1099;е затраты на обеспечениk= 7; высокой над = 77;жности ПС могут дост = 80;гать 2 – 3 кратного увеличения затрат относительl= 5;о функционалn= 0;ной пригодностl= 0; при требованияm= 3; наработки на отказ в десятки тысяч часов, а для минимальноk= 5;о обеспечениn= 3; автоматичеl= 9;кого рестарта в ординарных системах со = 89;тавляют порядка 10 – 20%;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>д = 83;я повышения эффективноl= 9;ти использоваl= 5;ия ресурсов ЭВ = 52; затраты могут быть относительl= 5;о невелики (несколько процентов) и их трудно вы= 076;елить из затрат на решение основных, функционалn= 0;ных задач;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;траты на обеспечениk= 7; практичносm= 0;и зависят в основном от сложности применения ПС, от качества и количества эксплуатацl= 0;онной документацl= 0;и и электронныm= 3; учебников и могут составлять до 20% затрат на решение основных, функционалn= 0;ных задач. <o:p></o:p> Стремлениk= 7; уменьшить затраты в период разработки без учета последующеk= 5;о испол= ;ьзования ПС, его компо= ;нентов и всего жизн= 077;нного цикла может оказаться мало полезн = 99;м, а в некоторых случаях привести к значительl= 5;ому увеличению совокупных = 79;атрат в ЖЦ. При применении сложных ПС эти затраты исчисляютсn= 3; сотнями человеко-ле = 90;, что определ= 03;ет особую актуальноl= 9;ть снижения этих k= 9;атрат. Поэтому необходим с = 80;стемный анализ распределеl= 5;ия и испl= 6;льзования ресурсов н = 72; разработку программ с у= 095;етом всего их жизненного цикла, включая соп = 88;овождение и перенос на другие платформы. При использ = 86;вании приведенныm= 3; данных, необходимо учитывать, что они могу= 090; служить только ориентирамl= 0; при приближ = 77;нной оценке затрат на непосредстk= 4;енную разработку = 80; обеспечениk= 7; качества ко = 85;кретного ПС. <o:p></o:p> </spa= n>Сопровож = 76;аемость ПС можно оценивать потребностn= 0;ю трудовых и временных ресурсов дл= 03; ее обеспече = 85;ия и для реализ= 072;ции. Возможные затраты рес = 91;рсов на развитие = 080; совершенстk= 4;ование качества комплекса программ зависят не только от внутренних свойств программ, н= 086; также от запросов и потребностk= 7;й пользоватеl= 3;ей на новые функции и от готовности заказчика и разработчиl= 2;а удовлетворl= 0;ть эти потребностl= 0; (см. лекцию 15). <o:p></o:p> В современныm= 3; проектах ПС большую или меньшую дол= 02; составляют готовые апробироваl= 5;ные компоненты = 80;з других подобных разработок R= 11; прототипы и/или покупн= 099;е пакеты прикладных программ. Эт= 086; позволяет значительнl= 6; ускорять работы и сок= 088;ащать затраты на создание сложных комплексов программ. Перед= ; разработчl= 0;ками проекта ПС зачастую возникает дилемма: разрабатывk= 2;ть ли весь комплекс программ по = 83;ностью из новых компонентоk= 4; или использ = 86;вать, адаптироваm= 0;ь и приспосаб = 83;ивать готовые ком = 87;оненты, какие и в каком количестве. = 042; результате при первичном экономичесl= 2;ом анализе рес = 91;рсов на создание ПС с требуем= 099;ми характерисm= 0;иками качества, целесообраk= 9;но рассматривk= 2;ть два альтерн = 72;тивных варианта определениn= 3; затрат на разработку:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1087;олностью нового ПС, для которог = 86; отсутствуюm= 0; или недоступны подходящие готовые компоненты R= 11; прототипы и/или их заведомо нерентабелn= 0;но использоваm= 0;ь;<o:p></o:p> <![if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>програм= ;много продукта на базе компле = 82;сирования набора готовых программныm= 3; компонентоk= 4; и информаци = 80; баз данных, для которог = 86; почти не требуется создания но = 74;ых компонентоk= 4;.<o:p></o:p> = Мобильносm= 0;ь и затраты ко= 085;кретных ресурсов дл= 03; переноса программ и д= 072;нных на иные аппаратные = 80; операционнm= 9;е платформы при проектировk= 2;нии могут быть учтены, только очен= 00; приблизитеl= 3;ьно. Эти субх = 72;рактеристи&#= 1082;и включают адаптируем&#= 1086;сть, простоту установки и <sp= an class=3DSpellE>замещаем = 86;сть программ, ко= 090;орые целесообраk= 9;но оценивать количествеl= 5;но: совокупнымl= 0; затратами, стоимостью, трудоемкосm= 0;ью и длительносm= 0;ью на реализац = 80;ю процедур переноса прогр= ;амм и данных. Оценки мобильностl= 0; зависят не только от вн= 091;тренних субхараl= 2;теристик ПС, но также от организа = 94;ии, технологии = 80; документирl= 6;вания реализации жизненного цикла и процессов переноса комплексов программ и и= 093; компонентоk= 4; (см. лекцию 15). <o:p></o:p= > При переносе программ и данных свойства систем практическl= 0; всегда изменяются, что следует учитывать при системном а = 85;ализе целесообраk= 9;ности и эффективноl= 9;ти переноса, а также могут быть необходимы = 90;естировани&#= 1077;, испытания и сертификацl= 0;я получаемых ПС в новой среде. Кроме того, любой перенос связан с затратами. При создани= ;и мобильных П = 57; трудно предусмотрk= 7;ть все возможн = 99;е особенност= и и различия платформ и внешней среды, для которых декларируе= тся мобильностn= 0; конкретных программныm= 3; средств. Эти особенностl= 0; и возможное расширение свойств окружающих прикладных программ и данных могу = 90; преподносиm= 0;ь неприятные сюрпризы не = 89;тыковки, для ликвида = 94;ии которых потребуютсn= 3; дополнителn= 0;ные ресурсы. Требования мобильностl= 0; компонентоk= 4; ПС приводят = 082; необходимоl= 9;ти их проектироk= 4;ания как автоном = 85;ых комплектуюm= 7;их изделий. Это реализуетсn= 3; за счет стан= 076;артизации их построения = 80; организациl= 0; интерфейсоk= 4;, унификации структуры базы данных = 080; гарантии качества функционирl= 6;вания. В результат = 77; подготавлиk= 4;ается возможностn= 0; создание новых ПС из набора готовых про = 75;раммных модулей или функционалn= 0;ных групп программ, ранее использоваl= 5;ных и испытанны = 93; в другом сочетании при решении = 085;есколько иных функци = 86;нальных задач. Однак= 086; в любом комплексе п = 88;ограмм вряд ли возможно и нужно повторно ис = 87;ользовать все 100% готовых программныm= 3; модулей. При сборке нового ПС из комплектуюm= 7;их компонентоk= 4;, может= ; потре= ;боваться доработка некот= ;орых из них, или создание специальныm= 3; программ, для их взаимодейсm= 0;вия.<o:p></o:p> В ряде случаев целесообраk= 9;на настройка - адаптация готовых ком = 87;онентов на новые условия применения. При больших изменениях условий при = 84;енения, эффективноl= 1; может оказаться сборка нового ПС с частичным использоваl= 5;ием апробироваl= 5;ных компонентоk= 4; и с разработкоl= 1; небольшой части прогр = 72;ммных модулей, обеспечиваn= 2;щих новые функц = 80;и, интерфейсы = 80; условия применения ПС. При этом относительl= 5;ое снижение за = 90;рат пропорционk= 2;льно доле исполь = 79;ования готовых комплектуюm= 7;их компонентоk= 4; и степени их пригодностl= 0; для использ = 86;вания в новом ПС. В пределе при построении нового ПС н= 072; 80 - 90% из готовых компонентоk= 4; суммарные затраты мог = 91;т сокращатьсn= 3; в 3 - 5 раз. В этом случае, кроме 10 <span style=3D'font-size:14.0= pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";color:windowtext;mso-char-type:symbol;mso-symbol-font-fam= ily: Symbol'>= - 20% затрат на создание новых программныm= 3; компонентоk= 4;, необходимы ресурсы на комплексирl= 6;вание нового ПС, его квалификацl= 0;онное тестированl= 0;я, испытания и документирl= 6;вание. <o:p></o:p> = Практичесl= 2;и всегда необ = 93;одимо время и трудоемкосm= 0;ь на системны = 81; анализ, и оценивание целесообраk= 9;ности разработки комплекса программ из = 075;отовых компонентоk= 4; с учетом стоимости приобретенl= 0;я и адаптации переносимыm= 3; программ. Интегрироk= 4;ание компонентоk= 4; в новой операционнl= 6;й среде, тестироваl= 5;ие и испытания = 074; комплексе с унаследоваl= 5;ными программамl= 0;, также почти всег = 76;а требует времени и других ресу = 88;сов. Некоторые, казалось бы, второстепеl= 5;ные, детали и факторы не = 89;овместимос&#= 1090;и готовых, пе= 088;еносимых программ и новой платформы могут заметно отражаться на трудоемк = 86;сти проекта. Особенно тщательно и = 93; следует анализироk= 4;ать в унаследоваl= 5;ных систе= ;мах, в котl= 6;рых относительl= 5;о мелкие детали взаи = 84;одействия новых и старых программ могут= ; сущес= ;твенно влиять на экономичеl= 9;кие характерисm= 0;ики проекта. <o:p></o:p> Обычно наиболее важным для р= 077;ализации проекта и завl= 0;сящим от большинстk= 4;а его особенностk= 7;й и факторов я= 074;ляется трудоемкосm= 0;ь, непосредсm= 0;венно определяющk= 2;я стоимость создаваемl= 6;го комплекса п = 88;ограмм. Значения длительносm= 0;и разработки = 80; числа специалистl= 6;в взаимосвязk= 2;ны и в некоторы= 093; пределах могут разме = 85;иваться. Поэтому оценки этих показ= ;ателей можно варьироватn= 0;, и при недост= 072;точном числе специ = 72;листов естественнl= 6; возрастает длительносm= 0;ь разработки, хотя трудое = 84;кость может остаться пр = 72;ктически неизменной. Многократнl= 6;е применение одних и тех же апробироваl= 5;ных компонентоk= 4; и/или многократнk= 2;я адаптация П = 57; к различным условиям применения является од = 85;им из самых пер= 089;пективных методов повышения качества и снижения затрат труд = 72; специалистl= 6;в в жизненном цикле крупномасшm= 0;абных комплексов программ.<o:p></o:p>= <o:p> </o= :p> <h1><a name=3D"_Toc508102484"></a><a name=3D"_Toc508102257">9.5. Ресурсы на имитацию внешней среды для об= 077;спечения те&#= 1089;тирования и испытаний программныm= 3; средств</a></h1> = <o:p></o:p> При создании крупных ПС, одной из больших составляющl= 0;х могут быть н= 077;обходимые ресурсы на генерацию т = 77;стов. В ряде случаев они соизмеримы = 89; затратами н = 72; создание основных функций комплексов программ, чт= 086; определяетl= 9;я принципиалn= 0;ным соответствl= 0;ем сложности необходимыm= 3; наборов тес = 90;ов и тестового покрытия программ, и сложности функций, реализуемыm= 3; испытываемm= 9;м ПС. Создание представитk= 7;льных совокупносm= 0;ей тестов возможно путем испол= 00;зования реальных объектов внешней сре = 76;ы или с помощь= 102; программныm= 3; имитаторов, адекватных этим объектам по результатаl= 4; функционирl= 6;вания и генерируе = 84;ой информации. При этом возникает проблема = - какой метод и когд= 072; выгодней по затратам на генерацию тестов и по обеспечениn= 2; необходимоl= 1; степени пок = 88;ытия тестами испыт= ;ываемых ПС (см. лекцию = 14).<o:p></o:p> = Имитаторы тестов необходимы не только дл= 103; оценивания = 76;остигнутых характерисm= 0;ик качества комплексов программ, но также для их комплексноl= 1; отладки, квалификацl= 0;онного тестированl= 0;я, испытаний и <sp= an class=3DGramE>при создания версий. Поэтому затраты на п= 088;ограммные имитаторы и их экономич = 77;скую эффективноl= 9;ть целесообраk= 9;но рассматривk= 2;ть в проекте с учетом всег = 86; комплекса задач, которые они способны и должны решать в ЖЦ ПС. Анализ эффективноl= 9;ти программноl= 1; имитации внешней сре = 76;ы при разработке = 80; определениl= 0; качества ПС целесообраk= 9;но разделить н = 72; две части: оценка факторов, определяющl= 0;х эффективноl= 9;ть средств имитации те = 89;тов, и оценка экономичесl= 2;ого выигрыша пр = 80; моделирова&= #1085;ии внешней среды на ЭВМ по сравнени= 02; с натурными эксперименm= 0;ами в реальных с= 080;стемах.<o:p></o:p> = Факторы, определяющl= 0;е эффективноl= 9;ть программноl= 1; имита= ;ции внешней сре = 76;ы на ЭВМ при разработке ПС, могут оцениватьсn= 3; в основном п= 086; их воздействиn= 2; на качество создаваемыm= 3; программ. Эт= 086; влияние трудно непосредстk= 4;енно измерить, од= 085;ако качественнm= 9;й анализ пока = 79;ывает, что автоматизиl= 8;ованная имитация мо = 78;ет значительнl= 6; изменять не только достигаемыk= 7; характерисm= 0;ики качества разрабатывk= 2;емого ПС, но также т&= #1088;удоемкость и длительносm= 0;ь его создани= 03;. Программнаn= 3; имитация внешней сре = 76;ы на ЭВМ может обеспечиваm= 0;ь широкие наб = 86;ры тестов и дос= 090;аточно полные тест = 86;вые покрытия ПС = 080; компонентоk= 4; при испытан = 80;ях, в том числе за пределами характерисm= 0;ик реально сущ = 77;ствующих или доступн = 99;х источников тестов, а также соответствm= 1;ющие критическиl= 4; или опасным ситуациям функционирl= 6;вания объектов внешней среды. Для каждого пар = 72;метра, отражающегl= 6; внешнюю среду, отношение диапазона или числа тестов, возможных п = 88;и программноl= 1; имитации на ЭВМ по сравнению с натурными эксперименm= 0;ами, может служи = 90;ь оценкой величины, возрастаниn= 3; достоверноl= 9;ти определениn= 3; характерисm= 0;ик качества ПС.<o:= p></o:p> &nb= sp; При тестированl= 0;и необходимо учитывать н = 77; только соот = 85;ошение размеров об = 83;астей изменения параметров тестов, но и распределеl= 5;ие вероятностk= 7;й значений каждого пар = 72;метра в этих областях дл= 03; реальных и п= 077;рспективны&= #1093; объектов внешней среды. Некот= 086;рые значения те = 89;тов не только трудно создать при натурных эксперименm= 0;ах, но они являю= 090;ся маловероятl= 5;ыми в реальных условиях. Однако таки = 77;, даже маловероятl= 5;ые ситуации и значения тестов могу = 90; быть критическиl= 4;и и/или особо важными для функционирl= 6;вания всей систем = 99;, для которой разрабатывk= 2;ется ПС. Выбор и имитация подобных ситуаций позволяют отрабатываm= 0;ь и оценивать качество ПС = 074; критическиm= 3; маловероятl= 5;ых ситуациях, которые невозможно или опасно создавать н = 72; реальных объектах, но без их выпол= 085;ения некоторые П = 57; не допустимо = 01;ксплуатиро&#= 1074;ать в критическиm= 3; системах уп = 88;авления и обработки информации. <o:= p></o:p> Э= 082;ономическу&= #1102; эффективноl= 9;ть программноl= 1; имитации внешней среды на ЭВМ по сравнени= 02; с натурными эксперименm= 0;ами целесообраk= 9;но оценивать при одинаковых объемах тестовых данных для испытаний и определениn= 3; качества ПС.<sp= an style=3D'mso-spacerun:yes'> Показ= ;ателем экономичесl= 2;ой эффективноl= 9;ти имитации может служи = 90;ь соотношениk= 7; затрат ресурсов на проведение натурных эксперименm= 0;ов и затрат на программнуn= 2; имитацию то = 81; же совокупн = 86;сти тестовых и эталонных данных. <o:p></o:p> Затраты ресурсов на натурные эксперименm= 0;ы для генерац = 80;и тестов при проведении разработки, испытаний и определениn= 3; качества пр = 86;порциональ&#= 1085;ы реальному времени функционирl= 6;вания проверяемоk= 5;о ПС и затратам на применение привлекаемm= 9;х средств реа = 83;ьной внешней среды. Они включают стоимость э = 82;сплуатации реального объекта, соз= 076;ающего тесты в единицу времени (напрl= 0;мер, затраты на функционирl= 6;вание администраm= 0;ивной системы, прокатного стана или системы управления воздушным движением и всех управляемыm= 3; ею объектов). Таким образ = 86;м, затраты на натурные эксперименm= 0;ы для оценива = 85;ия характерисm= 0;ик ПС определя= 02;тся использоваl= 5;ием всей реальной вн = 77;шней среды, в которой пре = 76;стоит в дальнейше = 84; функционирl= 6;вать программам, а также затра = 90;ами на средства измерения характерисm= 0;ик этой среды и проверяемоk= 5;о ПС в процесс= 077; разработки, испытаний и определениn= 3; качества.<o:p></o:p>= &nb= sp; Затраты на программнуn= 2; имитацию тестовых данных определяютl= 9;я ресурсами необходимыl= 4;и на проектир = 86;вание и эксплуатацl= 0;ю сложных комплексов программ дл= 03; этих целей и<sp= an style=3D'mso-spacerun:yes'> следующимl= 0; составляющl= 0;ми:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;тратами на разработку комплекса программ для имитации информации внешних объектов и среды их функционирl= 6;вания;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;тратами на эксплуатацl= 0;ю программ имитации за время прове = 76;ения тестированl= 0;я, испытаний и/или определениn= 3; характерисm= 0;ик качества те = 89;тируемого ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;тратами на первичну= 02; установку и эксплуатацl= 0;ю моделирующk= 7;й ЭВМ и вспомогатеl= 3;ьного оборудованl= 0;я, используемl= 6;го в имитацион = 85;ом стенде.<o:p></o:p> &nb= sp; Имитационl= 5;ые стенды практическl= 0; всегда являются ун = 80;кальными и достаточн = 86; полно используют = 88;есурсы моделирующk= 7;й ЭВМ. В ряде сл&= #1091;чаев эти комплексы программ могут иметь = 086;бъем порядка 104 <sp= an style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - 106 стро = 82; текста и должны создаватьсn= 3; с применени = 77;м современныm= 3; технологичk= 7;ских систем. Затраты на эксплуатацl= 0;ю программ имитации в о= 089;новном определяютl= 9;я длительносm= 0;ью проведения тестированl= 0;я, испытаний и/или измере= 085;ия характерисm= 0;ик качества ПС. Значения эт = 86;го времени соответствm= 1;ют реальному времени генерации тестовых данных и тестированl= 0;я программ. Затраты на эксплуатацl= 0;ю ЭВМ, использ= 091;емую в моделирую = 97;ем имитационнl= 6;м стенде (МИС), включают: первичные затраты на з= 072;купку и установку оборудованl= 0;я, необходимоk= 5;о для имитаци = 80; тестовых да = 85;ных, стоимость имитирующеl= 1; ЭВМ и устройств сопряжения имитационнl= 6;го стенда с ЭВМ, на которой функционирm= 1;ют тестируемыk= 7; программы. <o:p></o:p= > = Обычно МИС используетl= 9;я для тестированl= 0;я нескольких ПС разного, но близкого целевого назначения. Следователn= 0;но, затраты на и= 084;итационный стенд и на часть его программ ра = 89;пределяютс&#= 1103; на число про= 077;ктов ПС, тестируемыm= 3; с его использоваl= 5;ием. В результат = 77; удельные затраты на создание и эксплуатацl= 0;ю стендов быстро убывают при унификации имитаторов = 80; расширении области их п= 088;именения для тестированl= 0;я и оценивани= 03; качества большого числа ПС, имеющих бли = 79;кое функционалn= 0;ное назначение. Даже прибли = 78;енные оценки при системном анализе соотношениn= 3; этих затрат = 074; большинствk= 7; случаев пок = 72;зывают высокую рен = 90;абельность программныm= 3; имитаторов внешней среды, особенно дл= 03; квалификацl= 0;онного тестированl= 0;я и оценивани= 03; характерис&= #1090;ик качества кр = 91;пномасштаб&#= 1085;ых ПС реальног = 86; времени. Например, пр= 080; тестированl= 0;и ПС для управ= 083;ения воздушным движением, применение имитационнm= 9;х стендов, по крайней мер = 77;, на порядок снижает затраты по сравнению с натурными эксперименm= 0;ами и использоваl= 5;ием реальных объектов (самолетов), а для управления космическиl= 4;и аппаратами или атомным = 80; электростаl= 5;циями это соотношениk= 7; может быть значительнl= 6; больше (~ 10 -</span= > 100). При соk= 9;дании и определениl= 0; качества администраm= 0;ивных систем с полной загр = 91;зкой, имитация способна заменить сложную организациn= 2; функционирl= 6;вания по определеннl= 6;й программе большого коллектива операторов банка, налоговой инспекции или таможен = 85;ого органа. <o:p></o:p> &nb= sp; При разработке = 80; тестированl= 0;и компонентоk= 4; повторяемоl= 9;ть некоторых тестов окол = 86; 3 - 5, а при испытаниях = 80; определениl= 0; качества кр = 91;пномасштаб&#= 1085;ых ПС достигае = 90; 2 - 3. Поэтому целесообраk= 9;но запоминать имитированl= 5;ые данные для и= 093; многократнl= 6;го использоваl= 5;ия и создавать фильмы сценариев поведения и характерисm= 0;ик тестов, отра= 078;ающих внешнюю среду. В результате затраты на имитацию могут быть уменьшены в = 085;есколько раз за счет однократноl= 1; имитации каждой сово = 82;упности тестов с полным испо = 83;ьзованием МИС. Предваритеl= 3;ьная подготовка фильмов позволяет удобно контролироk= 4;ать имитированl= 5;ые данные, боле= 077; эффективно использоваm= 0;ь МИС, а также обеспечиваn= 2;т абсолютную повторяемl= 6;сть эксперименm= 0;ов. Однако они н= 077; позволяют у = 95;итывать в имитирова = 85;ных данных реакцию функционирl= 6;вания испытываемm= 9;х комплексов программ. Поэтому не полностью исключаютсn= 3; сложные экс = 87;ерименты с одновреме = 85;ным использоваl= 5;ием всей реальной аппаратуры = 52;ИС и оцениваем = 86;й системы, но обеспечиваk= 7;тся сокращение = 74; несколько раз количес = 90;ва таких экспе = 88;иментов. <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102485"></a><a name=3D"_Toc508102258">Л= 077;кция 10. Дефекты, ошибки и риски в жизненном цикле = программнm= 9;х средств</a><= span class=3Da4> = <o:p></o:p></h1> <o:p> </o:p></spa= n> <h1><a name=3D"_Toc508102486"></a><a name=3D"_Toc508102259">10.1. Общие особенностl= 0; дефектов, ошибок и рисков = = &nb= sp; k= 4; сложных программнm= 9;х средствах</spa= n></a><o:p></o:p></h1> <o:p> </o:p> Статистикk= 2; ошибок и дефектов в комплексах программ и и= 093; характерисm= 0;ики в конкретных типах проектов ПС, могут служи = 90;ь ориентl= 0;рами для разрабо = 90;чиков при распред = 77;лении ресурсов в ж= 080;зненном цикле ПС &#= 1080; предохраняm= 0;ь их от излишнего оптимизма п = 88;и оценке достигнутоk= 5;о качества программныm= 3; продуктов. </s= pan>Источни= ;ками ошибок в ПС являются специалистm= 9; – конкретны = 77; люди с их индивидуалn= 0;ными особенностn= 3;ми, квалификацl= 0;ей, талантом и опытом. При этом можно в= 099;делить п= ;редсказуем = 99;е модификациl= 0;, расширения = 80; совершенстk= 4;ования ПС и изменения, обусловленl= 5;ые выявлением случайных, нk= 7;предсказуе= 084;ых дефектов и о= 096;ибок. Вследствие этого, плотность потоков и ра= 079;меры необходимыm= 3; корректироk= 4;ок в модулях и компонентаm= 3; при разрабо = 90;ке и сопровожд = 77;нии ПС может различатьсn= 3; в десяток раз. Однако, в крупны&#= 1093; комплексах программ статистика = 80; распределеl= 5;ие типов выполняемыm= 3; изменений для коллект = 80;вов разных специалистl= 6;в нивелируютl= 9;я и проявляютсn= 3; достаточно общие закономернl= 6;сти, которые могут испол= 00;зоваться к= ;ак ориентиры при их выявл= 077;нии и системати = 79;ации. Этому могут помогать оценки типо = 74;ых дефектов, модификациl= 1; и корректироk= 4;ок, путем их нак= 086;пления и обобщения по опыту создания определеннm= 9;х классов ПС в конкретных предприятиn= 3;х. <o:p></o:p> К пl= 6;нятию риски= относятся негативные события и их величины, отражающие потери, убытки или ущерб от про= 094;ессов или продукт = 86;в, вызванные д = 77;фектами при проекти = 88;овании требованиl= 1;, недостаткаl= 4;и обоснованиn= 3; проектов ПС, а также при последующиm= 3; этапах= разработкl= 0;, реализации = 80; всего жизне = 85;ного цикла комплексов программ. В ЖЦ ПС не всегда удается достигнуть требуемого = 87;оложительн&#= 1086;го эффекта и может проявлятьсn= 3; некоторый ущерб – риск<sp= an style=3D'mso-spacerun:yes'> в созk= 6;аваемых проектах, программныm= 3; продуктах и их характерисm= 0;иках. Ри= ски проявляютсn= 3;, как нk= 7;гативные последствиn= 3; дефектов функционирl= 6;вания и применения ПС, которые спо = 89;обны вызвать ущерб системе, внешней среде или пользоватеl= 3;ю, в резm= 1;льтате о= ;тклонения характериl= 9;тик объектов ил = 80; процессов, от заданных требованиn= 3;ми заказчика, согласоваl= 5;ными с разработчиl= 2;ами. <o:p></o:p> = Оценки качества программныm= 3; средств могут проводитьсn= 3; с двух позиц= 080;й: с позиции положительl= 5;ой эффективноl= 9;ти и непосредстk= 4;енной адекватноl= 9;ти их характер = 80;стик назначениn= 2;, целям создания и п= 088;именения, а также с негати= вной позиции возможного при этом ущерба – риска от использоваl= 5;ия ПС или системы. Показатели качества пр = 77;имуществен&#= 1085;о отражают положительl= 5;ый эффект от применения системы или ПС и основна= 103; задача разработчиl= 2;ов проекта сос = 90;оит в обеспечениl= 0; высок= ;их значений качества. Риски характеризm= 1;ют возможные негативныk= 7; последствиn= 3; дефектов ил = 80; ущерб пользоватеl= 3;ей при применении = 80; функционирl= 6;вании ПС и системы, и задача разработчиl= 2;ов сводится к сокращению дефектов и ликвидации рисков. Поэт= 086;му методы и системы управления качеством в жизненном цикле ПС близки к методам анализа и управления рисками про = 77;ктов комплексов программ, он= 080; должны их до= 087;олнять и совместно способствоk= 4;ать совершенстk= 4;ованию программныm= 3; продуктов и систем на их основе. <o:p></o:p> Характериl= 9;тики дефектов и рисков непосредстk= 4;енно связаны с достигаемоl= 1; корректносm= 0;ью, безопасносm= 0;ью и надежностьn= 2; функционирl= 6;вания прогр= ;амм и поl= 4;огают:</= span><o:p></o:p></sp= an> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 94;енивать реальное состояние проекта и пл= 072;нировать необходимуn= 2; трудоемкосm= 0;ь и длительносm= 0;ь для его положительl= 5;ого завершения; <o:= p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 99;бирать методы и средства автоматизаm= 4;ии тестированl= 0;я и отладки программ, адекватные текущему состоянию разработки = 80; сопровождеl= 5;ия ПС, наиболее эффективныk= 7; для устране = 85;ия определеннm= 9;х видов дефек = 90;ов и рисков;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 72;ссчитывать необходимуn= 2; эффективноl= 9;ть контрмер и дополнителn= 0;ных средств оперативноl= 1; защиты от потенциальl= 5;ых дефектов и не выявленных ошибок; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 94;енивать требующиесn= 3; ресурсы ЭВМ по расширен = 80;ю памяти и производитk= 7;льности, с учетом затрат на реализацию = 82;онтрмер при модифик = 72;ции и устранени = 80; ошибок и рисков.<o:p></o:p> </spa= n>&#= 1055;онятие ошибки в программе</spa= n> &#= 8211; в общем случае под ошибкой подразумевk= 2;ется неправильнl= 6;сть, погрешностn= 0; или неумышл = 77;нное искажение объекта или процесса, чт= 086; может быть </s= pan>&#= 1087;ричиной ущерба – риска при функционирl= 6;вании и применени = 80; программы. При этом предполагаk= 7;тся, что извесm= 0;но правильное, эталонное состояние объекта или процесса, по отношени= 02; к которому может быть определено наличие отк = 83;онения – ошибки или дефекта. Исходным эт = 72;лоном для любого П= 057; являются специ= ;фикация требований = 79;аказчика или потенциальl= 5;ого пользоватеl= 3;я, предъ= ;являемых к программам. Подоб= ;ные документы устанавливk= 2;ют состав, содержание = 80; значения результатоk= 4;, которые должен полу = 95;ать пользоватеl= 3;ь при определеннm= 9;х условиях и исходных данных. Любо= 077; отклонение = 88;езультатов функционирl= 6;вания программы о = 90; предъявляеl= 4;ых к ней требований = 80; сформироваl= 5;ных по ним эталонов-те = 89;тов, следует ква = 83;ифицироват&#= 1100; как ошибкm= 1; – дефект = 74; программе</spa= n>, наносящий некоторый ущерб. Раз= 083;ичие между ожидаемыми и полученныl= 4;и результатаl= 4;и функционирl= 6;вания программ могут быть следствием ошибок не только в соз= 076;анных программах, но и ошибок в первичных требованияm= 3; спецификацl= 0;й, явившихся базой при создании эталонов-те = 89;тов. Тем самым проявляетсn= 3; объективнаn= 3; реальность, = 079;аключающая&= #1089;я в невозможноl= 9;ти абсолютной = 82;орректност&#= 1080; и полноты исходных спецификацl= 0;й и эталонов для сложных проектов ПС.<o:= p></o:p> На практик = 77; в процессе Ж= 062; ПС исходные требования = 87;оэтапно уточняются, = 084;одифицирую&= #1090;ся, расширяютсn= 3; и детализируn= 2;тся по согласов = 72;нию между заказчиком = 80; разработчиl= 2;ом. Базой= ; таких уточнений я = 74;ляются н= ;еформализо = 74;анные представлеl= 5;ия и знания специалистl= 6;в-заказчико&#= 1074; и разработчиl= 2;ов, а также результаты промежуточl= 5;ых этапов проектировk= 2;ния. Однако установить не корректн = 86;сть таких эталонов ещ = 77; труднее, чем обнаружить дефекты в сопровождаk= 7;мых программах, так как принципиалn= 0;но отсутствуюm= 0; формализовk= 2;нные данные, которые можно использоваm= 0;ь как исходны = 77;. В процессе декомпозицl= 0;и и верификац = 80;и исходной спецификацl= 0;и требований на ПС, возможно появление ошибок в спе= 094;ификациях на группы программ и н= 072; отдельные модули. Это способствуk= 7;т расширению спектра возможных дефектов и вызывает необходимоl= 9;ть создания гаммы метод = 86;в и средств тестированl= 0;я для выявлен = 80;я некорректнl= 6;стей в спецификацl= 0;ях на компонен = 90;ы разных уровней. <o:p></o:p> Важной особенностn= 0;ю процесса выявления ошибок в программах является &#= 1086;тсутствие полностью определеннl= 6;й программы-э = 90;алона, которо = 81; должны соот = 74;етствовать текст и результаты функционирl= 6;вания разрабатывk= 2;емой программы. Поэтому установить = 85;аличие и локализоваm= 0;ь дефект непосредстk= 4;енным сравнением = 89; программой без ошибок в большинствk= 7; случаев невозможно. При отладке = 080; тестированl= 0;и обычно сначала обн = 72;руживаются вторичны= е ошибки = 80; риски, т.е. последствиn= 3; и результаты проявления некоторых внутренних дефектов ил = 80; некорректнl= 6;стей программ (ри= 089;.10.1). Эти внутрен = 85;ие дефекты следует квалифицирl= 6;вать как перв= ичные ошибки или причины обнаруженнm= 9;х аномалий результатоk= 4;. Последующаn= 3; локализациn= 3; и корректироk= 4;ка таких первичных ошибок= должна при = 74;одить к устранени= 02; ошибок, первоначалn= 0;но обнаруживаk= 7;мых в результатаm= 3; функционирl= 6;вания программ.<o:p></o:p>= Потери эффективноl= 9;ти и риски прог= 088;амм за счет неполной ко = 88;ректности в первом приближениl= 0; можно счита = 90;ь прямо пропорционk= 2;льными (с коэффицие= 085;том) вторичным ошибкам в выходных результатаm= 3;. Типичным является случай, когд= 072; одинаковые по величине = 080; виду вторич = 85;ые ошибки в различных результируn= 2;щих данных существеннl= 6; различаютсn= 3; по своему воздействиn= 2; на общую эффективноl= 9;ть и риски применения комплекса программ. Эт= 086; влияние вторичных ошибок, в лучшем случ = 72;е, можно оценить мет = 86;дами экспертногl= 6; анализа при условии пре = 76;варительно&#= 1081;, четкой классификаm= 4;ии видов возмо = 78;ных первичных ошибок в программах = 80; выходных величин. Таким образом, оценка посл = 77;дствий, отражающиm= 3;ся на втl= 6;ричных ошибках и функционирl= 6;вании программ, может, в п = 88;инципе, производитn= 0;ся по значения = 84; ущерба – рис= 082;а вследствие не устраненныm= 3; их причин – первичных ошибок в программе. В= 090;оричные ошибки являются определяющl= 0;ми для эффективноl= 9;ти функционирl= 6;вания программ, однако не каждая перв = 80;чная ошибка вносит заме = 90;ный вклад в выходные результаты. Вследствие этого ряд первичных о = 96;ибок может оставаться не обнаруженнm= 9;м и, по существ&#= 1091;, не влияет на функционалn= 0;ные характерисm= 0;ики ПС.<o:p></o:p> Появление ошибок в программах, естественнl= 6;, предшествуk= 7;т их обнаружениn= 2; и устранени= 02; на основе вторичных проявлений. Наибольшее число перви = 95;ных ошибок внос = 80;тся на этапах системного анализа и разработки модификациl= 1; программ. Пр= 080; этом на долю системного анализа приходятся наиболее сл = 86;жные для обнаружениn= 3; и устранени= 03; дефекты. На последующиm= 3; этапах разработки изменений П = 57; ошибки вносятся и устраняютсn= 3; в программа = 93; в процессе и= 093; корректироk= 4;ки по результатаl= 4; тестированl= 0;я. Общие тенде = 85;ции состоят в быстром росте затра = 90; на выполнен = 80;е каждого изменения н = 72; последоватk= 7;льных этапах процессов модификациl= 0; программ. <o:p></o:p></span= > Пр&#= 1080; системном анализе модификациl= 1; интенсивноl= 9;ть обнаружениn= 3; ошибок отно = 89;ительно не велика, и ее трудно выделить из процесса проектировk= 2;ния ПС. Интенсивноl= 9;ть проявления = 80; обнаружени&= #1103; вторичных ошибок наиболее ве = 83;ика на этапе акт= 080;вного тестированl= 0;я и автономно = 81; отладки программныm= 3; компонентоk= 4;. Затем она снижается приблизитеl= 3;ьно экспоненциk= 2;льно. Различия интенсивноl= 9;тей устраl= 5;ения первичных о = 96;ибок, на основе их вторичных проявлений</spa= n>, и внесения первичных ошибок при корректироk= 4;ках программ определяют скорость достижения заданного качества ве = 88;сий ПС. Уровень сер= 00;езности последствиl= 1; ошибок варьирует о = 90; классов проектов и о= 090; предприятиn= 3;, но, в общем, можно разделить ошибки= на три уров= 085;я. <o:p></o:p> Небольшимl= 0; ошибками называю= ;т такие, на которые средний пол= 00;зователь не обратит внимания пр = 80; применении ПС, вследствиk= 7; отсутствия их проявлен = 80;я, и последств = 80;я которых обычно так и не обнаружи = 74;аются. Небольшие ошибки могу = 90; включать ор = 92;ографическ&#= 1080;е ошибки на экране, пропущенныk= 7; разделы в справочникk= 7; и другие мелкие проб = 83;емы. Такие ошибк = 80; никогда не помешают выпуску и применению версии сист = 77;мы и программноk= 5;о продукта. По десятибаллn= 0;ной шкале риско = 74; небольшие ошибки находятся в пределах от 1 до 3 приорите&#= 1090;а (см. ниже).<o:p></o:p> </spa= n>Уl= 4;еренными ошибками называют те, которые вли= 03;ют на конечног = 86; пользоватеl= 3;я, но имеются слабые последствиn= 3; или обходны = 77; пути, позволяющиk= 7; сохранить достаточнуn= 2; функционалn= 0;ность ПС. Это такие дефекты, как неверные ссылки на страницах, ошибочный текст на экране и даж= 077; сбои, если эти сбои трудно воспроизвеl= 9;ти, и они не оказывают влияния на существеннl= 6;е число пользоватеl= 3;ей. Некоторые умеренные ошибки, возможно, пр= 086;никают в конечный программныl= 1; продукт. Ошибки, кото= 088;ые можно испра = 74;ить на этом уровне, след= 091;ет исправлять, если на это есть время и возможностn= 0;. По десятиба = 83;льной шкале умеренные ошибки нахо = 76;ятся в диапазоне от 4 до 7 приоритета.<o:p= ></o:p> Кl= 8;итические ошибки останавливk= 2;ют выпуск версии программноk= 5;о продукта. Это могут быть ошибки с высоким влиянием, которые выз = 99;вают сбой в системе или потерю данн = 99;х, отражаются на надежнос = 90;и и безопасносm= 0;и применения ПС, с которым&#= 1080; никогда не передается комплекс прогр= ;амм пользоватеl= 3;ю. По десятибаллn= 0;ной шкале – от 8 до 10= приоритетk= 2;.<o:p></o:p> Совокупноl= 9;ть ошибок, дефектов и последствиl= 1; модификациl= 1; проектов кр = 91;пномасштаб&#= 1085;ых комплексов программ можно упоря = 76;очить и условно пр= 077;дставить в виде перев= 077;рнутой пирамиды в зависимостl= 0; от потенциа = 83;ьной опасности и возможной величины корректироk= 4;ок их последст = 74;ий – рис. 10.2. В верхней части перечня расположенm= 9; модификациl= 0;, дефекты и ошибки, последствиn= 3; которых обычно треб = 91;ют наибольших = 79;атрат ресурсов дл= 03; реализации изменений, и &#= 1086;ни постепенно сокращаютсn= 3; при снижени = 80; по перечню. Такое представлеl= 5;ие величины типов корре = 82;тировок программ и данных= полезно ис = 87;ользовать к= ;ак ориентир для учета необходимыm= 3; ресурсов пр = 80; разработке = 80; сопровожде&= #1085;ии ПС, однако оно может содержать значительнm= 9;е отклонения при упорядоченl= 0;и статистичеl= 9;ких данных реальных проектов. Каждому тип = 91; корректироk= 4;ок соответствm= 1;ет более или менее определеннk= 2;я категория специалисm= 0;ов, являющихся = 80;сточником изменений данного тип = 72; (таблица 10.1). Та= 082;ую корреляцию целесообраk= 9;но рассматривk= 2;ть и учитывать как общую качественнm= 1;ю тенденцию при анализе = 080; поиске их причин. <o:p></o:p> </spa= n><o:p></o:p> <h1><a name=3D"_Toc508102487"></a><a name=3D"_Toc508102260">10.2. Причины и свойства дефектов, ошибок и мод= 080;фикаций в = сложных программнm= 9;х средствах</spa= n></a><o:p></o:p></h1> <o:p> </o:p> Одной из основных причин изме = 85;ений комплексов программ яв = 83;яются организациl= 6;нные дефекты при модификациl= 0; и расширени = 80; функций ПС, которые отличаются от остальны = 93; типов и усло= 074;но могут быть в= 099;делены как самостоятеl= 3;ьные (см. рис. 10.2). Ошибки и деф= 077;кты данного тип = 72; появляются из-за недост= 072;точного понимания коллективоl= 4; специалистl= 6;в технологии процесса ЖЦ ПС, а также вследствие отсутствия четкой его организациl= 0; и поэтапног = 86; контроля качества продуктов и изменений. Это порождаетсn= 3; пренебрежеl= 5;ием руководитеl= 3;ей к организациl= 0; всего технологичk= 7;ского процесса Ж = 62; сложных ПС и &#= 1087;риводит к серьезной недооценке его дефекто = 74;, а также трудоемкосm= 0;и и сложности модификациl= 1;. При отсутствии планомерноl= 1; и методично = 81; разработки = 80; тестированl= 0;я изменений П = 57;, остается не выявленным = 79;начительно&#= 1077; количество ошибок, и, прежде всег = 86;, дефекты взаимодейсm= 0;вия отдельных ф = 91;нкциональн&#= 1099;х компонентоk= 4; между собой = 080; с внешней средой. Для сокращения этого типа массовых ошибок, активную роль должны играть лидеры – мен= 077;джеры и системотехl= 5;ики, способные вести контроль и к= 086;нфигурацио&= #1085;ное управление требованияl= 4;и, изменениямl= 0; и развитием версий и ком= 087;онентов ПС. <o:p></o:p></= span> Изменения характерисm= 0;ик системы и внешней среды, приня= 090;ые в процессе р= 072;зработки ПС за исходные, могут быть р= 077;зультатом аналитичесl= 2;их расчетов, моделироваl= 5;ия или исследованl= 0;я аналогичныm= 3; систем. В ряде случае = 74; может отсут = 89;твовать полная адек = 74;атность предполагаk= 7;мых и реальных характерисm= 0;ик, что являетс= 03; пl= 8;ичиной сложных и тр= 091;дно обнаруживаk= 7;мых системных ошибок и дефектов ра = 79;вития проекта. Ситуация с т= 072;кими ошибками дополнителn= 0;но усложняетсn= 3; тем, что эксперименm= 0;ы по проверке взаимодейсm= 0;вия ПС с реально= 081; внешней средой во всей област = 80; изменения п = 72;раметров зачастую сложны и дор= 086;ги, а в отдельны= 093; случаях, при создании опасных ситуаций, недопустимm= 9;. В этих случаях приходится использоваm= 0;ь моделироваl= 5;ие и имитацию внешней среды с заве= 076;омым упрощением её отдельны = 93; элементов и характерисm= 0;ик, хотя степен= 00; упрощения н = 77; всегда удается оце = 85;ить с необходимоl= 1; точностью. Однако полн = 86;й адекватносm= 0;и моделей внешней среды и реал= 100;ной системы добиться трудно, а во многих случаях и не= 074;озможно, что может являться причиной зн = 72;чительного числа крупн = 99;х дефектов.<o:p></o:p>= Первичные ошибки в программах проектов можно анализировk= 2;ть с разной сте= 087;енью детализациl= 0; и в зависимостl= 0; от различны = 93; факторов. Практическl= 0;й опыт показа = 83;, что наиболее существеl= 5;ными факторами, влияющими н = 72; характерисm= 0;ики обнаруживаk= 7;мых ошибок явля= 02;тся:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тодология, технология = 80; уровень авт = 86;матизации системного = 80; структурноk= 5;о проектировk= 2;ния ПС, а также непосредстk= 4;енного программирl= 6;вания компонентоk= 4;;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>д = 83;ительность с начала процесса тестированl= 0;я и текущий этап разработки или сопрово = 78;дения и модификациl= 0; комплекса п = 88;ограмм;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>к = 83;асс ПС, масштаб (размер) и типы компонентоk= 4;, в которых обнаруживаn= 2;тся ошибки;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды, виды и уровень автоматизаm= 4;ии верификациl= 0; и тестирова = 85;ия, их адекватн = 86;сть характерисm= 0;икам компонентоk= 4; и потенциал= 00;но возможным в программах ошибкам;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 80;ды и достоверноl= 9;ть эталонов-те = 89;тов, которые используютl= 9;я для обнаруж = 77;ния ошибок.<o:p></o:p> Пk= 7;рвичные ошибки в ПС в порядке уменьшения их влияния н= 072; сложность обнаружениn= 3; и масштабы корректироk= 4;ок можно разде = 83;ить на следующи = 77; группы= (см. рис. 10.2):<o:p></o:p> <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки, обусловленl= 5;ые сложностью компонентоk= 4; и ПС в целом и наиболее сильно влияющие на размеры модификациl= 1;;<o:p></o:p> <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки вследствие большого маl= 9;штаба – размера ко= 084;плекса программ, а также высоких тре = 73;ований к его качеству;<o:p></o:p>= <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки планированl= 0;я и корректносm= 0;и требований модификациl= 1; часто могут быть наиболее кр = 80;тичным для общего успеха ЖЦ ПС и системы;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки проектировk= 2;ния, разработки структуры и функций ПС в более полны = 77; и точные техническиk= 7; описания сценариев того, как комплекс пр = 86;грамм и система бу = 76;ут функционирl= 6;вать;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>с = 80;стемные ошибки, обусловленl= 5;ые отклонениеl= 4; функционирl= 6;вания ПС в реальной системе, и характерисm= 0;ик внешних объектов от предполагаk= 4;шихся при проекти = 88;овании;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>а = 83;горитмичес&#= 1082;ие ошибки, связанные с неполным формированl= 0;ем необходимыm= 3; условий решения и некорректнl= 6;й постановкоl= 1; целей функц = 80;ональных задач;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>о = 96;ибки реализации спецификацl= 0;й изменений – программныk= 7; дефекты, воз= 084;ожно, ошибки нарушения требований или структу = 88;ы компонентоk= 4; ПС; <o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>п = 88;ограммные ошибки, вследствие неправильнl= 6;й записи текс = 90;ов программ на языке программирl= 6;вания и ошибок тра= 085;сляции текстов изменений программ в о= 073;ъектный код;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>о = 96;ибки в документацl= 0;и, которые наиболее ле = 75;ко обнаруживаn= 2;тся и в наименьшей степени влияют на фу= 085;кционирова&= #1085;ие и применени = 77; версий ПС; <o:p></o:p> <![if !supportLists]>-&nb= sp; = &nb= sp; <![endif]>т = 77;хнологичес&#= 1082;ие ошибки подготовки физических носителей и документацl= 0;и, а также ввод= 072; программ в память ЭВМ и вывода резу = 83;ьтатов на средства отображениn= 3;.<o:p></o:p> </spa= n> Сложн= ость проявления, обнаружениn= 3; и устранени= 03; ошибок зна = 95;ительно конкретизиl= 8;уются и стан= 086;вятся измеримой, когда устан = 72;вливается связь этого понятия с конкретнымl= 0; ресурсами, необходимыl= 4;и для решения соответствm= 1;ющей задачи и воз= 084;ожными проявленияl= 4;и дефек= ;тов. При разработке = 80; сопровождеl= 5;ии проk= 5;рамм основным лимитирующl= 0;м ресурсом обычно являются допустимые трудозатраm= 0;ы специалистl= 6;в, а также ограниченl= 0;я на сроки раз= 088;аботки, параметры ЭВМ, техноло&sh= y;гию проектировk= 2;ния корректироk= 4;ок ПС. П</span= >оказат= 077;ли сложности при анализе = 084;ожно разделить на две большие гру = 87;пы:<o:p></o:p> <![if !supportLists]><sp= an style=3D'mso-list:Ignore'>-&nb= sp; = <![endif]>сложно= ;сть ошибок при создании корректироk= 4;ок компонентоk= 4; и комплекса программ <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";letter-spacing:.3pt;mso-char-type:s= ymbol; mso-symbol-font-family:Symbol'>- статическаn= 3; сложность, когда реали = 79;уются его требуемые функции, вносятся ос = 85;овные дефекты и ош= 080;бки;<o:p></o:p> <= ![if !supportLists]>- = &nb= sp; <![endif]>сложно&= #1089;ть проявления ошибок функционирl= 6;вания программ и получения р = 77;зультато= ;в <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";letter-spacing:.3= pt; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- динамическk= 2;я сложность, <sp= an style=3D'font-size:14.0pt;letter-spacing:.3pt'>когд= а проявляютсn= 3; дефекты и ошибки, отражающиеl= 9;я на функционалn= 0;ном назначении, рисках и кач= 077;стве применения версии ПС.<o:p></o:p> К группе факторов, влияющих на <sp= an style=3D'mso-bidi-font-style:italic'>сложн= 086;сть ошибок= &= #1082;омплексов программ, от= 085;осятся:<o:p></o:p> = <![if !supportLists]>- &nb= sp; = <![endif]>величина – размер модифицируk= 7;мой программы, выраженная числом стро = 82; текста, функционалn= 0;ных точек или количеством программныm= 3; модулей в комплексе;<o:p></o:p> = <![if !supportLists]>- &nb= sp; = <![endif]>количествl= 6; обрабатываk= 7;мых переменных или размер и структура п = 72;мяти, используемl= 6;й для размещения базы данных корректироk= 4;ок;<o:p></o:p> <![if !supportLists]><sp= an style=3D'mso-list:Ignore'>-&nb= sp; = &nb= sp; <![endif]>трудоемкос= ;ть разработки изменений комплекса п = 88;ограмм;<o:p></o:p> <![if !supportLists]>- &= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; <![endif]>длительнос= ;ть разработки = 80; реализации корректироk= 4;ок;<o:p></o:p> = <![if !supportLists]>- &nb= sp; = <![endif]>число специалистl= 6;в, участвующиm= 3; в ЖЦ комплекса прог= рамм.<o:p></o:p> Не= которые из перечисленl= 5;ых параметров коррелир = 86;ванны между собой, причем, определяющl= 0;ми часто являю = 90;ся размер изменений программы и объем базы д= 072;нных. Остальные характерисm= 0;ики можно рассм = 72;тривать как вторичные, однако они могут предс = 90;авлять самостоятель= ;ный интерес при анализе сложности и = 087;рогнозиров&= #1072;нии вероятного числа дефектов в измененной программе. <sp= an style=3D'font-size:14.0pt;letter-spacing:.5pt;mso-bidi-font-weight:bold; mso-bidi-font-style:italic'>Сложноl= 9;ть ошибок комплекl= 9;ов программ целесообраk= 9;но анализировk= 2;ть на базе трех наиболее специфичесl= 2;их компонентов:<s= pan style=3D'font-size:14.0pt'><o:p></o:p> <= ![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>сложно= ;сть ошибок изменяемых программныm= 3; компонентоk= 4; и модулей опре= ;деляется конструктивн= ой сложностью модификациl= 0; оформленноk= 5;о компонента программы и может быть оценена с по= 079;иции сложности внутренней структуры и преобразовk= 2;ния данных в каждом модуле, а также инте</span= >грал= ;ьно по некоторы = 84; внешним статистичеl= 9;ким характерисm= 0;икам размеров моду= ;лей;<o:p></o:p> <![if !supportLists]><sp= an style=3D'mso-list:Ignore'>-&nb= sp; = &nb= sp; = <![endif]>сложнl= 6;сть ошибок корректироk= 4;ок структуры комплекса или компонентоk= 4; и связей межд= 091; модулями по передачам управления = 80; по обмену ин&sh= y;формацией определяетl= 9;я глубиной взаимодейсm= 0;вия модулей и ре&sh= y;гуля= рностью структуры межмодульнm= 9;х связей;<o:p></o:p> <= ![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>сложно= ;сть ошибок изменения структуры д = 72;нных оп= ределяется количествоl= 4; и с= труктурой глобальных = 80; обменных пе = 88;еменных в базе данных, регулярносm= 0;ью их = размещения в массивах, а также сложн = 86;стью доступа к эт= 080;м данным.<o:p></o:p> Масштаб – размер компле= ксов программ и и= 093; изменяемой части наиболее си = 83;ьно влияет на количество ошибок, а также на тре= 073;ования к качеству ПС (см. лекцию 5). К= ;ачество откорректиl= 8;ованного ПС характер = 80;зуется многими показателяl= 4;и, состав кото = 88;ых зависит от класса и кон= 082;ретного назначения комплекса программ. Ниже предполагаk= 7;тся, что всегда модификациl= 0; ПС соответствm= 1;ют заданному функционалn= 0;ному назначению = 80; основным требованияl= 4; заказчика к = 080;х качеству. По мере увелич = 77;ния размера и повышения требований = 82; качеству ПС = 080; его корректироk= 4;кам, затраты на обнаружениk= 7; и устранени = 77; ошибок ПС ув= 077;личиваются все более высокими темпами. Одновременl= 5;о расширяетсn= 3; диапазон неопределеl= 5;ности достигаемоk= 5;о качества. В зоне высоко = 75;о качества программ во = 79;растают трудности измерения этих характерисm= 0;ик, что может приводить к необходимоl= 9;ти изменения з = 72;трат в несколько раз в зависимостl= 0; от применяе = 84;ых методов и результатоk= 4; оценки каче = 89;тва ПС. Вследствие этого в ЖЦ сложных и св= 077;рхсложных ПС всегда велики проявления не устранен = 85;ых ошибок и недостаточl= 5;а достоверноl= 9;ть оценок достигнутоk= 5;о качества.<o:p></o:p>= </spa= n>Оm= 6;ибки корректносm= 0;и формированl= 0;я и планирова = 85;ия выполнения требований = 82; ПС часто считаются наиболее критичным для общего успеха версий программноk= 5;о продукта и системы. Ошибки требований = 03;вляются наиболее трудными дл= 03; обнаружениn= 3; и наиболее сложными дл= 03; исправлениn= 3;. Вот почему и= 089;правление ошибок треб = 86;ваний может быть в 15 – 70 раз дороже, чем ошибок и= 093; программирl= 6;вания. Требование = 82; изменению может быть пропущено в спецификацl= 0;и к системе и ПС. Это ведет к неудовлет= ;воренности пользоватеl= 3;я, и программа считается заказчиком = 80; пользовате= лем ошибочной. Пропуск некоторых требования – это наиболее обычная проблема среди ошибо = 82; требований. Ошибка треб = 86;ваний может представляm= 0;ь собой конфликтуюm= 7;ие требования = 74; спецификацl= 0;и модификациl= 1;. Напри= ;мер, два требования, которым необходимо следовать, имеют противополl= 6;жный смысл. Может проявлятьсn= 3; неопределk= 7;нность требований R= 11; такой спосо = 73; формулировk= 2;ния требования, что даже есл= 080; и не конфлик= 090;ует с другим требование= м, оно выражен = 86; недостаточl= 5;о ясно, чтобы п&#= 1088;ивести к единственнl= 6;му, конструкти= вному решению при разработке = 80;зменения. Конечный пользоватеl= 3;ь часто назыв = 72;ет это ошибкой, хотя на самl= 6;м деле это выбор конст = 88;уктивного решения на основе непо = 83;ного или неопред = 77;ленного требования. Многочислеl= 5;ные исследованl= 0;я показали, чт= 086; ошибки требований дороже всег = 86; исправить и труднее всего обнар = 91;жить. <o:p></o:p> &nbs= p; Ошибки проектировk= 2;ния и разработк = 80; структуры П = 57; опредеl= 3;яются процессами перевода неопределеl= 5;ных и общих полl= 6;жений, сделанных н = 72; стадии спецификацl= 0;й требований, = 074; более точны = 77; техническиk= 7; описания сценариев того, как измененные ПС и система должны рабо = 90;ать. Ошибки структуры легче обнар = 91;жить, чем ошибки требований, но они в коне&#= 1095;ном итоге могут оказаться при корректироk= 4;ках такими же дорогостояm= 7;ими. Главная причина тог = 86;, что ошибки структуры дорого исправлять, состоит в том, что они могут влият= 00; на систему в целом. Испрk= 2;вление изменений всей систем = 99; сложнее, и при этом воз= 085;икает большая опасность з = 72;нести новые ошибк = 80;, чем при исправлениl= 0; нескольких нарушенных строк кода или при замене одного моду = 83;я. <o:p></o:p> Ошибки структуры можно разде = 83;ить на три категории: п= 088;опуски, конфликты и ошибки перевода. Пропуски означают неспособноl= 9;ть включить изменения одного или б= 086;лее требований в окончател= 00;ную структуру П = 57;. Когда пропуск новой функц = 80;и или компоне = 85;та попадает в окончательl= 5;ую структуру, о= 085; станет ошибкой в конечном программноl= 4; продукте. Конфликты возникают, когда модификациn= 3; двух различ = 85;ых, конструктиk= 4;ных свойств имеют конфликтуюm= 7;ую структуру. Э= 090;о может происходитn= 0; в случае явного конф = 83;икта, когда в структуре установленl= 6;, что файл может быть открыт двум= 03; разными людьми в одн= 086; и то же время, тогда как в б&#= 1072;зовом классе определяетl= 9;я только однопользоk= 4;ательский доступ. Ошибки, которые основаны на конфликтах на этом уровне, част= 086; невозможно = 80;справить без полного переписываl= 5;ия модулей версии ПС. <o:p></o:p></spa= n> Ошибки перевода – наиболее коварные среди всех ошибок стру = 82;турного уровня. Они проявляютсn= 3;, когда требо = 74;ания заказчика интерпретиl= 8;уются неправильн= о, по крайней мере, с точки зрения коне = 95;ного пользоватеl= 3;я. Если разраб= ;отчик структуры либо неверн = 86; прочитает т = 88;ебования, либо не увидит содержание требования также как конечный по = 83;ьзователь, появится ошибка разработки = 89;труктуры данного ком = 87;онента или ПС. <o:p></o:p> Системные ошибки в ПС<sp= an style=3D'font-size:14.0pt'> определяютl= 9;я, прежде всег = 86;, неполной информациеl= 1; о реальных процессах, п= 088;оисходящих в источника = 93; и потребите = 83;ях информации. Кроме того, эти процесс = 99; зачастую зависят от самих алгоритмов = 80; поэтому не могут быт= 100; достаточно определены = 80; описаны заранее без исследованl= 0;я изменений функционирl= 6;вания ПС во взаимодейсm= 0;вии с внешней средой. На начальных этапах не всегда удается точ = 85;о и полно сформулироk= 4;ать целевую задачу всей системы, а также целевые зад = 72;чи основных групп программ, и эти задачи у= 090;очняются в процессе п= 088;оектирован&= #1080;я. В соответствl= 0;и с этим уточн= 103;ются и конкретиз = 80;руются спецификацl= 0;и на отдельны = 77; компоненты = 80; выявляются отклонения от уточненн = 86;го задания, которые могут квалифицирl= 6;ваться как системные ошибки.<o:p></o:p> Характериl= 9;тики внешних объ = 77;ктов, принятые в качестве ис = 93;одных данных в процессе разработки алгоритмов, могут являться результатоl= 4; аналитичесl= 2;их расчетов, мо= 076;елирования или исследованl= 0;я аналогичныm= 3; систем. Во всех случая = 93; может отсут = 89;твовать полная адекватносm= 0;ь условий получения предполагаk= 7;мых и реальных характерисm= 0;ик внешней среды, что является причиной сл = 86;жных и трудно обнаруживаk= 7;мых ошибок. Это усугубляетl= 9;я тем, что очень часто = 085;евозможно заранее пре = 76;усмотреть все разнообразl= 0;е возможных внешних условий и реальных сц = 77;нариев функционирl= 6;вания и применени= 03; версий программноk= 5;о продукта.<o:p></o:p>= Пр&= #1080; автономноl= 1; и в начале комплексноl= 1; отладки версий ПС, относительl= 5;ая доля системных о = 96;ибок может быть невелика (около 10%), но он= 072; существеннl= 6; возрастает (до 35–40%) на завершающиm= 3; этапах комп = 83;ексной отладки новых базовых версий ПС. В процессе сопровождеl= 5;ия системные ошибки явля= 02;тся преобладаюm= 7;ими (около 60 – 80% от всех ошибок). Следует также отметить большое количество команд, корректируk= 7;мых при исправлениl= 0; каждой тако = 81; ошибки (окол= 086; 20 – 50 команд на одну ошибку).<o= :p></o:p> Алгоритмиm= 5;еские ошибки программ трудно поддаются обнаружениn= 2; методами статическоk= 5;о автоматичеl= 9;кого контроля. Тр= 091;дность их обнаружениn= 3; и локализациn= 3; определяетl= 9;я, прежде всег = 86;, отсутствиеl= 4; для многих логических программ строго формализовk= 2;нной постановки задачи, полной и точной спецификацl= 0;и, которую можно использоваm= 0;ь в качестве эталона для сравнения результатоk= 4; функционирl= 6;вания программ. К алгоритмичk= 7;ским ошибкам следует отнести, прежде всег = 86;, ошибки, обусловленl= 5;ые некорректнl= 6;й постановкоl= 1; требований = 82; функционалn= 0;ным задачам, когда в спецификацl= 0;ях не полность= 02; оговорены все условия, необходимыk= 7; для получения правильногl= 6; результата. Эти условия формируютсn= 3; и уточняются = 74; значительнl= 6;й части в процессе тестированl= 0;я и выявления ошибок в результатаm= 3; функционирl= 6;вания программ. Ошибки, обусловленl= 5;ые не полным учетом всех условий решения зад = 72;ч, являются наиболее ча = 89;тыми в этой групп= 077; и составляю = 90; до 50 – 70% всех алгоритмичk= 7;ских ошибок.<o:p></o:p> К алгоритмичk= 7;ским ошибкам сле = 76;ует отнести также ошибк = 80; интерфейса = 84;одулей и функционалn= 0;ных групп программ, когда инфор = 84;ация, необходимаn= 3; для функцио = 85;ирования некоторой части программы, оказываетсn= 3; не полность= 02; подготовлеl= 5;ной программамl= 0;, предшествуn= 2;щими по времени включения, или неправильнl= 6; передается информация = 80; управление между взаимодейсm= 0;вующими модулями. Этот вид ошибок сост = 72;вляет около 10% от общего количества, = 080; можно квалифицирl= 6;вать как ошибки некорректнl= 6;й постановки задач. Алгоритмичk= 7;ские ошибки проя = 74;ляются в неполном учете диапазонов изменения переменных, = 074; неправильнl= 6;й оценке точности используемm= 9;х и получаемы = 93; величин, в неправильнl= 6;м учете корреляции между различными переменнымl= 0;, в неадекват = 85;ом представлеl= 5;ии формализовk= 2;нных условий решения задачи в вид= 077; частных спецификацl= 0;й или блок-схем, подлежащих программирl= 6;ванию. Эти обстоят = 77;льства являются причиной того, что для исправлениn= 3; каждой алго = 88;итмической ошибки приходится изменять в среднем около 20 команд (стр= 086;к текста), т.е. существеннl= 6; больше, чем при программныm= 3; ошибках.<o:p></o:p> Особую, весьма существеннm= 1;ю, часть алгоритмичk= 7;ских ошибок в системах ре = 72;льного времени, при сопровождеl= 5;ии составляют просчеты в использоваl= 5;ии доступных ресурсов вычислителn= 0;ной системы. Получающиеl= 9;я при модификациl= 0; программ попытки пре = 74;ышения использоваl= 5;ия выделенных ресурсов, сл= 077;дует квалифицирl= 6;вать как ошибку, так как зате= 084; всегда след = 91;ет корректироk= 4;ка с целью удовлетворk= 7;ния имеющимся ограничениn= 3;м. Одновременl= 5;ая разработка множества модулей различными специалистk= 2;ми затрудняет оптимальноk= 7; и сбалансироk= 4;анное распределеl= 5;ие ограниченнm= 9;х ресурсов ЭВ = 52; по всем зада= 095;ам, так как отсутствуюm= 0; достоверныk= 7; данные потребных ресурсов дл= 03; решения каждой из них. В резуль&#= 1090;ате возникает либо не достаточноk= 7; использоваl= 5;ие, либо, в подав&#= 1083;яющем большинствk= 7; случаев, нехватка каких-то ресурсов ЭВ = 52; для решения задач в перв= 086;начальном варианте. Наиболее крупные про = 89;четы обычно допу = 89;каются при оценке в= 088;емени реализации различных групп программ ре = 72;льного времени, и при распределеl= 5;ии производитk= 7;льности ЭВМ. Алгорит= 084;ические ошибки этог = 86; типа обусловленm= 9; техническоl= 1; сложностью расчета времени реализации программ и сравнительl= 5;о невысокой достоверноl= 9;тью, определениn= 3; вероятностl= 0; различных маршрутов обработки и = 85;формации.<o:p></o:p></sp= an> Ошибки реализации спецификацl= 0;й компонентоk= 4; – это пр= 086;граммные дефекты, воз= 084;ожно, ошибки требований, структуры или програм= ;мные ошибки комп = 86;нентов. Ошибки реализации наиболее обычны, и, в общем, наиболее легки для исправлениn= 3; в системе, что не делае= 090; проблему легче для программисm= 0;ов (см. таблицу 10.1). В отличие от ошибок треб = 86;ваний и структурныm= 3; ошибок, которые обычно специфичны для приложения, программисm= 0;ы часто совершают при кодиров = 72;нии одни и те же в&= #1080;ды ошибок. <o:p></o:p> Первую категорию составляют дефекты, которые приводят к отображениn= 2; для пользоватеl= 3;я сообщений о = 73; ошибках при = 090;очном следовании порядку вып= ;олнения требуемых функций. Хот= 103; эти сообщен = 80;я могут быть вполне законны, пользовате= ли могут посчи = 90;ать это ошибкой, поскольку они делали в= 089;е правильно и, тем не менее, получили со = 86;бщение об ошибке. Часто ошибк = 80; этого типа вызваны либ = 86; проблемами = 89; ресурсами, л= 080;бо специфичесl= 2;ими зависимост= ями от данных.<o:p></o:p></span= > Вторая категория модификациl= 1; может содержать ошибки, связ= 072;нные с дефектами = 074; графическоl= 4; интерфейсе пользоватеl= 3;я. Такие ошибк = 80; могут являт= 00;ся либо нестандартl= 5;ыми модификациn= 3;ми пользоватеl= 3;ьского интерфейса, которые приводят к тому, что пол&#= 1100;зователь совершает н = 77;верные действия, либо они мог= 091;т быть стандартныl= 4;и компонентаl= 4;и пользоватеl= 3;ьского интерфейса, используемm= 9;ми иначе, чем ожидает кон= ;ечный пользоватеl= 3;ь. <o:p></o:p> &n= bsp; <o:p></o:p> &n= bsp; Третья категория может содержать п = 88;опущенные на стадии реализации функции, что всегда считается ошибкой, возможно, с большим риском. Многие т = 77;стировщики</= span> и пользоватеl= 3;и бета-версий = 089;ообщают об ошибках, которые на самом деле я= 074;ляются желательныl= 4;и улучшениямl= 0;. В данном случае можн = 86; не замечать обнаруженнm= 9;е таким образ = 86;м отсутствия функций, которых не было в специ= 092;икациях. <o:p></o:p> Прог&= #1088;аммные ошибки модифицироk= 4;анных компонентоk= 4; по количест = 74;у и типам в первую очередь определяютl= 9;я степенью ав = 90;оматизации программирl= 6;вания и глубиной статическоk= 5;о контроля те = 82;стов программ. Количество программныm= 3; ошибок зависит от квалификацl= 0;й программисm= 0;ов, от общего размера комплекса программ, от глубины инф = 86;рмационног&#= 1086; взаимодейсm= 0;вия модулей и от ряда других факторов. Пр= 080; разработке ПС программ = 85;ые ошибки можн = 86; классифициl= 8;овать по видам исп= 086;льзуемых операций на следующие крупные группы: ошибки типо = 74; операций; ош= 080;бки переменных; ошибки управления = 80; циклов. В логическиm= 3; компонентаm= 3; ПС, эти виды ошибок близ = 82;и по удельном = 91; весу, однако для автоматизаm= 4;ии их обнаружениn= 3; применяютсn= 3; различные методы. На начальных э = 90;апах разработки = 80; автономной отладки мод = 91;лей, программныk= 7; ошибки сост = 72;вляют около одной трети всех ошибок. Кажд= 072;я программнаn= 3; ошибка влечет за собой необходимоl= 9;ть изменения около 10 команд, что существеннl= 6; меньше, чем при алгорит = 84;ических и системных ошибках. <o:p></o:p> Ошибки в документацl= 0;и модификациl= 1; состоят в том, что сист&#= 1077;ма делает что-т= 086; одним образом, а документацl= 0;я отражает сценарий, чт= 086; она должна работать иначе. Во многих случаях права должн = 72; быть документацl= 0;я, поскольку она написан = 72; на основе ор= 080;гинальной спецификацl= 0;и требований системы. Иногда документацl= 0;я пишется и вк= 083;ючает допущения и комментариl= 0; о том, как, по мнению авто = 88;ов документацl= 0;и, система дол = 78;на работать. В других случаях ошибку можн = 86; проследить не до кода, а до документацl= 0;и конечных пользоватеl= 3;ей, внутренних технологичk= 7;ских документов, характеризm= 1;ющих систему, и даже до экранных подсказок и файлов помо = 97;и. Ошибки документацl= 0;и можно разде = 83;ить на три катег= 086;рии – неясность, неполнота и неточность. Неясность – это когда по= 083;ьзователю не дается достаточно информации, чтобы определить, как сделать процедуру должным образом. Неполная документацl= 0;я оставляет пользоватеl= 3;я без информации = 86; том, как правильно реализоватn= 0; и завершить задачу. Пользоватеl= 3;ь считает, что задача выпо= ;лнена, хотя на само= 084; деле это не так. Такие ош&#= 1080;бки ведут к тому, что пользоватеl= 3;ь неудовлk= 7;творен версией ПС, даже если программа в действител= ьности может сдела = 90;ь все, что хочет пользоватеl= 3;ь. Неточная до = 82;ументация – это худший вид ошибок документацl= 0;и. Такие ошибк = 80; часто возникают, когда при сопровождеl= 5;ии в систему позже вносятся изменения и об этих изменениях не сообщают лицу, пишуще= 084;у документацl= 0;ю. <o:p></o:p> Технологиm= 5;еские ошибки документацl= 0;и и фиксированl= 0;я программ в памяти ЭВМ составляют иногда до 10% от общего числ = 72; ошибок обнаруживаk= 7;мых при тестиро = 74;ании. Большинствl= 6; технологичk= 7;ских ошибок выявляется автоматичеl= 9;ки статическиl= 4;и методами. Пр= 080; ручной подг = 86;товке текстов маш = 80;нных носителей при однократноl= 4; фиксированl= 0;и исходные данные имею = 90; вероятностn= 0; искажения около 10 -3 – 10 -4 н= 072; символ. Дубл= 080;рованной подготовкоl= 1; и логически = 84; контролем вероятностn= 0; технологичk= 7;ской ошибки може = 90; быть снижен = 72; до уровня 10 -5 – 10 -7 на симво= л. Непосредсm= 0;венное участие чел = 86;века в подготовк = 77; данных для ввода в ЭВМ и при анализе результатоk= 4; функционирl= 6;вания программ по данным на дисплеях определяет = 74; значительнl= 6;й степени их уровень дос = 90;оверности и не позволяет полностью пренебрегаm= 0;ь этим типом о= 096;ибок в программа = 93;. <o:p></o:p> = В примере анализа ошибок конкретногl= 6; крупного проекта, было принят = 86;, что завершиласn= 0; инспекция н = 72;чального запрограммl= 0;рованного кода крупного ПС на предмет е= 075;о соответствl= 0;я рабочей проектной спецификацl= 0;и, в ходе которой был = 86; обнаружено 3,48 ошибок на тысячу стро = 82; кода. Наибольшее совпадение аппроксимаm= 4;ии рэлеевсl= 2;ой кривой распределеl= 5;ия ошибок с фактическиl= 4;и данными установленl= 6; для момента получения этих данных, ему соответ = 89;твует значение, равное такж = 77; 3,48. Зна&#= 1095;ения числа ошибо = 82; на тысячу строк получены, п= 088;и пересчетах на более ранние этап = 99; соответствk= 7;нно эскизного – (3,3) и рабочего – (7,8) проектировk= 2;ния программ. При прогноз = 80;ровании в соответствl= 0;и с рэлеев = 89;кой кривой распределеl= 5;ия вероятностl= 0; проявления дефектов пр = 86;грамм, на следующе = 84; этапе квалификацl= 0;онного тестированl= 0;я компонентоk= 4; следовало ожидать обнаружениn= 3; около 2,12 ошибок на ты= 089;ячу строк исходного кода. В случае сохр = 72;нения той же закон= 086;мерности, в момент поставки кл = 80;енту на испытани= 03;, программныl= 1; продукт мог содержать менее 0,07 ошибо= ;к на тысячу строк кода. Отмечается также, что частость проявления 0,1 – 0,05 ошибок на тысячу стро = 82; кода, можно считать допустимымl= 0; для ответст = 74;енных систем реального времени. <o:p></o:p> В исследованl= 0;ях 20 крупных поставляемm= 9;х программныm= 3; продуктов, созданных в 13 различных организациn= 3;х коллективы специалистl= 6;в добились среднего уровня 0,06 дефе= ;кта на тысячу строк новог = 86; и измененно = 75;о программноk= 5;о кода. При использоваl= 5;ии структурноk= 5;о метода в пят= 080; проектах достигнуто 0,04 – 0,075 ошибок на тысячу стро = 82;. Таким образом, уровенn= 0; ошибок окол = 86; 0,05 на тысячу строк кода = 074; разных публикацияm= 3; считается близким к предельном&#= 1091;, для высококачеl= 9;твенных программныm= 3; продуктов. <o:p></o:p> Другим примером оценок уровня ошиб = 86;к критическоk= 5;о ПС особенно высокого ка = 95;ества может служить программныl= 1; продукт бор = 90;овых систем Ш = 72;тла, созданный NASA= . По оценке авторов в не= 084; содержится = 84;енее одной ошибк = 80; на 10000 строк кода. Однако стоимость программноk= 5;о продукта достигает 1000 $ за строку кода, что в среднем в ст= 086; раз больше, чем для администраm= 0;ивных систем и в десять раз больше, чем – для ряда орд= 080;нарных критическиm= 3; управляющиm= 3; систем реал= 00;но времени. <o:p></o:p> Привk= 7;денные характерисm= 0;ики типов дефек = 90;ов и количествеl= 5;ные данные могу = 90; служить ориентирамl= 0; пl= 8;и прогнозироk= 4;ании возможного наличия не выявленных ошибок в ЖЦ различных сложных ПС в= 099;сокого качества. Следующим логическим шагом процесса их оценивания может быть усреднение для большог = 86; числа проектов фактическиm= 3; данных о кол= 080;честве ошибок на конкретном предприятиl= 0;, приходящихl= 9;я на тысячу строк кода, которые обнаружены в различных П = 57;. Тогда в следующем проекте буд = 77;т иметься воз = 84;ожность использоваl= 5;ия этих данных,<sp= an style=3D'mso-spacerun:yes'> в качk= 7;стве меры количества ошибок, обнаружениk= 7; которых следует ожидать при выполнении проекта с таким же уровнем качества ПС, или с целью повышения производитk= 7;льности при разработке для оценки момента прекращениn= 3; дальнейшегl= 6; тестированl= 0;я. Подобные оц = 77;нки гарантируюm= 0; оm= 0; избыточногl= 6; оптимизма при определениl= 0; сроков и при разработке = 75;рафиков разработки, = 089;опровожден&= #1080;я и реализаци = 80; модификаци&= #1081; программ с заданным качеством. Непредсказm= 1;емость конкретных ошибок в программах приводит к целесообраk= 9;ности последоватk= 7;льного, методичногl= 6; фиксированl= 0;я и анализа возможностl= 0; проявления = 83;юбого типа дефектов и необходимоl= 9;ти их исключен = 80;я на наиболее ранних этапах ЖЦ ПС прl= 0; минимальныm= 3; затратах. <o:p></o:p></span= > <o:p> </o:p> <h1><a name=3D"_Toc508102488"></a><a name=3D"_Toc508102261">10.3. Риски в жизненном цикле сложных программныm= 3; средств</a></h1> <o:p> = ;</o:p> </sp= an>Прич= 080;нами возникновеl= 5;ия и проявлени= 03; рисков могу = 90; быть: злl= 6;умышленные, активные воздействиn= 3; заинтересоk= 4;анных лиц или слm= 1;чайные негативные проявления дефектов внешней среды, системы или пользоватеl= 3;ей. В первом случае риск = 80; могут быть о= 073;условлены искажениямl= 0; прогр= ;амм и информациоl= 5;ных ресурсов и и= 093; уязвимостьn= 2; от предумыш = 83;енных, внешних воздействиl= 1; (атак) с целью незаконногl= 6; использоваl= 5;ия или искажен = 80;я информации = 80; программ, ко= 090;орые по своему содержанию предназначk= 7;ны для примене = 85;ия ограниченнm= 9;м кругом лиц. Для решения этой проблемы созданы и активно раз = 74;иваются методы, средства и стандарты обеспечениn= 3; защиты прог = 88;амм и данных от <s= pan style=3D'font-size:14.0pt;color:windowtext;mso-bidi-font-weight:normal; mso-bidi-font-style:italic'>предумm= 9;шленных негативных внешних воздействиl= 1;. Специфичесl= 2;ие факторы обеспечениn= 3; информациоl= 5;ной безопасносm= 0;и и риски, характерныk= 7; для сложных информациоl= 5;ных систем – целостностn= 0;, доступностn= 0; и конфиденц = 80;альность информациl= 6;нных ресурсов, а также ряд типовых процедур си = 89;тем защиты – криптографl= 0;ческая поддержка, идентификаm= 4;ия и аутентификk= 2;ция, защита и сохранностn= 0; данных поль = 79;ователей при предумышлеl= 5;ных атаках из внешней среды, далее не рассматр = 80;ваются.<o:p></o:p> Рl= 0;ски при случайных, дестабилизl= 0;рующих воздействиn= 3;х дефектов программныm= 3; средств и отсутствии предумышлеl= 5;ного негативногl= 6; влияния на систе= ;мы, ПС или инфор= 084;ацию баз данных существеннl= 6; отличаются от предшествуn= 2;щих задач. Эти риски объек = 90;ов и систем зависят от отказовы = 93; ситуаций, от= 088;ицательно отражающихl= 9;я на работосп = 86;собности и реализаци = 80; их основных функций, причинами которых могут быть дефек = 90;ы и аномалии в аппаратуре, программах, данных или вычислителn= 0;ных процессах. П= 088;и этом катаст = 88;офически, критически или существеннl= 6; искажается процесс функционирl= 6;вания систем, что может наносить значительнm= 9;й ущерб при их применении. Основными источникамl= 0; отказовы = 93; ситуаций могут быть некорректнm= 9;е исходные тр = 77;бования, сбои и отказ= 099; в аппаратур = 77;, дефек= ;ты или ошибки в программах = 80; данных функ = 94;иональных задач, прояв= 083;яющиеся при их испол= 085;ении в соответствl= 0;и с назначениеl= 4;. При таких воздействиn= 3;х, внешняя, функционалn= 0;ная работоспосl= 6;бность систем мож = 77;т разрушатьсn= 3; не полность= 02;, однако невозможно полноценноk= 7; выполнение заданных функций и требований = 82; качеству информации для потребителk= 7;й. Вредн= ;ые и катастрофиm= 5;еские последствиn= 3; таких отказов в ряде областей применения систем могут превышать п = 86; результатаl= 4;, последствиn= 3; злоумышленl= 5;ых воздействиl= 1;, имеют свою природ = 91;, особенностl= 0; и характерисm= 0;ики. <o:p></o:p> Рассматриk= 4;аемые риски могут = 073;ыть обусловленm= 9; нk= 2;рушениями технологий или ограничениn= 3;ми при использоваl= 5;ии ресурсов – бюджета, планов, колл= 077;ктива специалистl= 6;в, инструментk= 2;льных средств, выделенных на разработку ПС. Результируn= 2;щий ущерб = 74; совокупносm= 0;и зависит от велич= ;ины и вероятностl= 0; проявления каждого негативногl= 6; воздействиn= 3;. Этот ущерб – риск характеризm= 1;ется разнообразl= 5;ыми метриками, зависящими от объектов анализа, и в некоторых случаях может измер= 03;ться прямыми мат = 77;риальными, информациоl= 5;ными, функционалn= 0;ными потерями применяемыm= 3; ПС или систе= 084;. Одним из косвенных методов определениn= 3; величины риска может быть оценка совокупных затрат, необходимыm= 3; для ликвида = 94;ии негативных последствиl= 1; в ПС, системе или внешней среде, прояв= 080;вшихся в результат = 77; конкретногl= 6; рискового события. <o:p></o:p> Процессы анализа и сокращения рисков должны сопутствовk= 2;ть основным этапам разработки = 80; обеспечениn= 3; ЖЦ сложных п= 088;ограммных средств k= 4; соответстk= 4;ии с междунаро = 76;ными стандартамl= 0;, а также мето= 076;ам систем обеспечениn= 3; качества ПС. Эти процесс = 99; могут быть отражены пn= 3;тью этапами работ и процедур, которые рекомендуеm= 0;ся выполнять при поддержке базовых работ жизненного цикла проектов сложных программныm= 3; средств, и могут служить основой для разработки соответствm= 1;ющих планов рабо = 90; при управлении = 80; сокращении рисков – рис. 1= 0.3:<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>а = 85;ализ рисков следует начинать с подготовки детальных исходных требований = 80; характерисm= 0;ик проекта ПС, системы и внешней сре = 76;ы, для которых должны отсутствовk= 2;ть риски функционирl= 6;вания и применени= 03;;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>д = 83;я управления рисками и их сокращения = 74; рассматривk= 2;емых проектах сл = 86;жных комплексов программ ре = 82;омендуется выделять тр = 80; класса риск = 86;в: функционалn= 0;ной пригодностl= 0; ПС, конструк= 090;ивных характерисm= 0;ик качества и нарушения ограничениl= 1; ресурсов пр = 80; реализации процессов Ж = 62; ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>в каждом классе предлагаетl= 9;я анализировk= 2;ть несколько категорий наиболее важных рисков, которые упо = 88;ядочивать по степени опасности, угроз для проекта, обусловленl= 5;ых ограничениn= 3;ми ресурсов, дефектами и/или недост= 072;точным качеством разработки = 80; жизненного цикла ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>к = 86;нтрмеры для сокращения рисков рекомендуеm= 0;ся анализировk= 2;ть и применять последоватk= 7;льно, начиная с ликвидации наиболее опасных исх = 86;дных причин – угроз, затем проводить анализ и уменьшение уязвимости компонентоk= 4; и ПС в целом, а при недостаточl= 5;ости этих контрмер воздействоk= 4;ать непосредстk= 4;енно на уменьшен = 80;е итогового ущерба – риска в жизненном цикле ПС и системы;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>п = 88;оцессы устранения рисков должны завершатьсn= 3; проце= ;дурами мониторингk= 2;, сопровождеl= 5;ия и конфигура = 94;ионного управления изменениямl= 0; версий комплексов программ высокого качества с минимальныl= 4;и допустимымl= 0; рисками. <o:p></o:p> Таким образом, в жизненном ц = 80;кле программныm= 3; средств ущерб – риск= 080; могут проявлятьсn= 3; – рис.10.4:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в искажениях или не полно= 081; реализации требуемого назначения, функций или взаимодейсm= 0;вия ПС с компоне= 085;тами системы или внешней среды – недос= ;татками и дефектами <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>фm= 1;нкциональн= 086;й пригодностl= 0; комплексов = 87;рограмм;<o:p></o:p></sp= an> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в недостаточl= 5;ых и не соответствm= 1;ющих требованияl= 4;, кl= 6;нструктивн= 099;х характерисm= 0;иках качества ПС при его функционирl= 6;вании и применени = 80; по прямому назначению;<o:p= ></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в нарушениях ограничениl= 1; на использоваl= 5;ие э= ;кономическ = 80;х, временных или техническиm= 3; ресурсов при создани = 80; и применени = 80; ПС.<o:p></o:p> Анализ и оценка рисков долж = 85;ы начинаться = 89; исследованl= 0;я понятий, требований = 80; функций, способ= ствующих одобр= ;ению и применени= 02; заказч&#= 1080;ком и пользоватеl= 3;ями конкретногl= 6; программноk= 5;о продукта. Пр= 080; этом должны быть определены требования = 82; характерисm= 0;икам ПС и оценки возможного ущерба при и= 093; нарушении. = 048;сследовани&= #1103; процессов р = 72;зработки проектов ПС показали, что во многих случаях стоимость и длительносm= 0;ь их реализац = 80;и значительнl= 6; превышали предполагаk= 7;мые, а характери = 89;тики качества не соответствl= 6;вали требуемым, что наносил = 86; ущерб заказ = 95;икам, пользоватеl= 3;ям и разработч = 80;кам. Эти потери – ущерб проектов, могли бы быт= 100; значительнl= 6; сокращены своевременl= 5;ым а= ;нализом, прогнозироk= 4;анием и корректироk= 4;анием рисков воз = 84;ожного нарушения требований контрактов, техническиm= 3; заданий и спецификацl= 0;й на характер = 80;стики, выделяемые ресурсы и технологию создания ко = 84;плексов программ. <o:p></o:p></span= > Управ= ления рисками предполагаk= 7;т ясное понимание в = 85;утренних и внешних причин и реальных источников угроз, влияющи= 093; на качество проекта ПС, к&#= 1086;торые могут привести к его провалу или большом = 91; ущербу. В результате анализа следует создавать план отслеж= ивания изменения рисков в жизненном цикле ПС, который должен регу = 83;ярно рассматривk= 2;ться и корректироk= 4;аться. Главн= 086;й целью управления рисками является обнаружениk= 7;, идентификаm= 4;ия и контроль з= 072; редко встре = 95;ающимися ситуациями = 80; факторами, которые при = 74;одят к негативны = 84; – рисковым резул= ;ьтатам проекта. Это должно отра = 78;аться на прим= енении регламентиl= 8;ованных процессов, в которых факторы и уг= 088;озы рисков систематичk= 7;ски идентифициl= 8;уются, оцениваютсn= 3; и корректир = 91;ются.<o:p></o:p> Одной из самых распростраl= 5;енных причин и опасных источников рисков, явля= 102;тся ошиб = 82;и при оценке масштаба – размера проектk= 2; или программноk= 5;о продукта (см. лекцию 5). Эти ошибки, чаще всего, бываю= 090; случайными R= 11; непредумышl= 3;енными, вследствие недостаточl= 5;ой компетентнl= 6;сти заказчика или разрабо = 90;чика-постав&= #1097;ика. Однако в некоторых случаях в превышении значения со = 75;ласованног&#= 1086; масштаба заказанногl= 6; продукта могут быть заинтересоk= 4;аны разработчиl= 2;и для получения больших ресурсов от заказчика, а уменьшеннуn= 2; оценку масштаба мо = 75;ут стремиться представитn= 0; заказчики для с= окращения выделяемых = 79;атрат на разработ = 82;у проекта или программноk= 5;о продукта. Величина оцененного = 80; согласованl= 5;ого между заказчиком = 80; разработчиl= 2;ом масштаба ПС непосредстk= 4;енно отражается на:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>бюд= жете и трудоемкосm= 0;и разработки = 80; обеспечениn= 3; всего жизне = 85;ного цикла программноk= 5;о продукта;<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>зат= ратах времени и сроках с= ;оздания и всего жизненного цикла реали = 79;ации и применени= 03; ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>п = 86;требности в численност= 080; и квалификацl= 0;и специалистl= 6;в-разработ</sp= an>-чиков дл= 103; реализации проекта и создания программноk= 5;о продукта в соответствl= 0;и с требованияl= 4;и заказчика.<o:p></o:p>= Эти три ключевых ха = 88;актеристик обычно тесн = 86; связаны и могут измен= 03;ться в процессах разработки проекта заказчиком или разработчиl= 2;ом в сторону увеличения или уменьше = 85;ия в соответствl= 0;и с их интерес= 072;ми, целями и возможностn= 3;ми. При стремлении = 79;аказчика сократить сроки реали = 79;ации проекта может требоватьсn= 3; увеличить б= 02;джет (трудоемкос = 90;ь) и численностn= 0; специалистl= 6;в. При объективно недостаточl= 5;ом числе и квал= 080;фикации специалистl= 6;в, естественнl= 6;, возрастают сроки создания пр = 86;граммного продукта и, возможно, бюджет прое = 82;та. Практическl= 0; всегда основным фактором, определяющl= 0;м значения и взаимосвязn= 0; этих важней = 96;их характерисm= 0;ик и их рисков, при создании сложных ПС, является оценка и отс= 083;еживание масштаба проекта, а также его согласованl= 0;е между заказ = 95;иком и разработч = 80;ком. <o:p></o:p></spa= n> Для снижения во = 79;можного ущерба – рисков применяютсn= 3; оценки, контроль и мониторинг рисков, а также различные контрмеры. Уменьш = 77;ние рисков должно производитn= 0;ся путем макси = 84;ально возможного приближениn= 3; проекта к требованияl= 4; заказчика и = 082; выделенным ресурсам ил = 80; путем сниже = 85;ия этих требов = 72;ний и увеличени= 03; заказчиком ресурсов на проект ПС. В крупных проектах систем, испо= 083;ьзующих комплексы п = 88;ограмм, риски могут быть обусловленm= 9; дефектами функционалn= 0;ных характерисm= 0;ик самих ПС и их жизненного цикла, а также недостаткаl= 4;и систем и внешней среды, в которой они используютl= 9;я. Основной ущерб от рисков ПС проявляетсn= 3; в последств = 80;ях их применения – в дефектах и недостаткаm= 3; функционирl= 6;вания систем и внешней среды. Поэтому анализ и оценка рисков ПС должны быть тесно связаны с исследованl= 0;ем их проявления = 74; системах, гд= 077; они использ = 91;ются. <o:p></o:p> Риски ПС могут проявлятьсn= 3; в процессах проектировk= 2;ния, разработки = 80; сопровождеl= 5;ия при изменении и развитии комплексов программ и при применении готового пр = 86;граммного продукта по прямому назначению. Это приводи = 90; к необходимоl= 9;ти анализа рис = 82;ов функционирl= 6;вания ПС в условиях, ра= 079;личающихся:= <o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>и = 89;точниками и причинами </s= pan>угроз и опасного проявления рисков;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>к = 83;ассами, категориямl= 0;, уяk= 9;вимостью ПС и системы, вероятностn= 0;ю проявления = 80; величиной последствиl= 1; рисков;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>в = 86;зможными и реализуемыl= 4;и контрмера = 84;и для сокращения рисков и их э&#= 1092;фективност= ью.<o:p></o:p> Оц= енка и измерение рисков во многих случ = 72;ях характеризm= 1;ется значительнl= 6;й неопределеl= 5;ностью и применениеl= 4; качественнm= 9;х метрик. Факт= 086;ры и угрозы рисков могу = 90; быть распределеl= 5;ы, и отличатьс= 03; уязвимостьn= 2; по этапам жизненного цикла ПС и системы. При анализе и управлении рисками целесообраk= 9;но выделять, прежде всего, наиболее х = 72;рактерные этапы ЖЦ ПС: технико-эко = 85;омического обоснованиk= 7; проекта ПС; разработку требований спецификацl= 0;й; проектировk= 2;ние; кодированиk= 7;; тестированl= 0;е; и документирl= 6;вание. <o:p></o:p> <s= pan style=3D'font-size:14.0pt'> Неопр= еделенностn= 0; оценок мас = 96;таба комплексов = 80; компонентоk= 4; программ яв = 83;яется одним из важнейших факторов, влияю= 097;им на риски всего жизне = 85;ного цикла проекта ПС (см. лекцию 5). Точнос&= #1090;ь оценки разм = 77;ра нового ПС значительнl= 6; повышаетсn= 3; после формулировk= 2;ния начальных требований = 80; спецификацl= 0;й заказчиков, проведения анализ&#= 1072; требований, после завершения разработки предваритеl= 3;ьного проекта. На этап&= #1077; концепции проекта, ошибки оценки разм = 77;ра ПС ум&#= 1077;ньшаются приблизитеl= 3;ьно до 40%. Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти вопросы могут быть р= 072;зрешены во время разработки структуры и спецификацl= 0;й треб= ;ований к ПС и тогда можно оцени = 90;ь размер ПС с точностью до 15 – 20% . <o:p></o:p><= /span> Как только структура П = 57; будет разбита с учетом выделения с = 72;мых нижних, дост= 091;пных уровней компонентоk= 4;, может быть с= 086;здан более точны = 81; показатель размера ком = 87;лекса программ. Пр= 080; этом исполь = 79;уются процессы измерения и суммированl= 0;я. После &#= 1079;авершения разработкl= 0; и подтверждения проектных спецификацl= 0;й при детальн = 86;м проектировk= 2;нии комплекса программ может быть определена структура внутренних данных и функции программныm= 3; компонентоk= 4;. На этом этапе, оценка размера проекта ПС может соста = 74;ить около 10%. Уточнения размеров ПС = 080; компонентоk= 4;, могут быть решены = 082; концу детального проk= 7;ктирования, однако при этом сохраняетсn= 3; неопределе&#= 1085;ность оценки разм = 77;ра комплекса программ около 5 – 10%, связанная = 89; тем, насколько хорошо прог = 88;аммисты пони = 84;ают спецификацl= 0;и, в соответствl= 0;и с которыми они должны кодиро&#= 1074;ать программу. </s= pan><o:p></o:p> = 42; рассматривk= 2;емом ниже пример = 77; проекта ПС средние ошибки оценивания = 84;асштаба могут быть больше или меньше реал= 00;ных значений, чт= 086; по-разному отражается на характери= 089;тиках договора с з= 072;казчиком на проект, а также на факторах и типах риско = 74; – рис. 10.5. Если масштаб проекта ПС в &#= 1076;оговоре завышеl= 5;, то следстви = 77;м могут быть, прежде всего, риски – ущерб экономичесl= 2;их категорий R= 11; превышения планируемm= 9;х ресурсов: стоимости, трудоемкосm= 0;и, длительносm= 0;и разработки = 80; числа необх = 86;димых специалистl= 6;в. При этом заказчик терпит убытки, разр= 072;ботчик получает неоправданl= 5;ую прибыль. При<sp= an style=3D'mso-spacerun:yes'> реализациl= 0; функционалn= 0;ной пригодностl= 0; и конструктиk= 4;ных характерисm= 0;ик ПС разработ = 95;ик может свобо = 76;но использоваm= 0;ь ресурсы и не предпринимk= 2;ть жестких мер для их эконо= 084;ии, что может отразиться на эффективноl= 9;ти последующеk= 5;о применения комплекса п = 88;ограмм.<o:p></o:p> Если при оценке масштаба пр = 86;екта ПС его величина в договоре определена нk= 7;достаточно= 081; – заниженно = 81;, то основной ущерб – риск= 080; достаются р = 72;зработчика&#= 1084;. Они вынужде = 85;ы принимать жесткие мер = 99; для выполне = 85;ия плановых сроков, выделенногl= 6; бюджета работ при относительl= 5;о малом числе специалистl= 6;в, что угрожае = 90; рисками срыва сроко = 74; и нарушения стоимости проекта. Недооценка размера проекта комплекса программ и ресурсов дл= 03; его реализации, = 084;ожет резко увеличиватn= 0; число дефектов в п= 088;ограммах. Кроме того, ограниm= 5;енные ресурсы дл= 03; реализации = 74; полном объеме функционалn= 0;ной пригодностl= 0;, могут отражаться на ее качестве и удобстве применения, = 072; также на конструктиk= 4;ных характерисm= 0;иках: на безопасносm= 0;и, надежности, качестве взаимодейсm= 0;вия с внеm= 6;ней средой и с пользоватеl= 3;ями, качестве до = 82;ументации и других эксплуатаm= 4;ионных факторах. <o:p></o:p> Оце= нки масштаба проекта ПС и рисков долж = 85;ы быть проана = 83;изированы и скорректи = 88;ованы для установленl= 0;я в договоре м= 077;жду заказчикамl= 0; и разработч = 80;ками исходного компромиссl= 5;ого масштаба, допустимогl= 6; для разработки первичных спецификацl= 0;й требований = 89; требуемым качеством. Некоторые требования могут потребоватn= 0; изменения (обычно увел= 080;чения) масштаба, и соответствk= 7;нно ресурсов на этапах предваритеl= 3;ьного и детальног = 86; проектировk= 2;ния для обеспечениn= 3; возможностl= 0; реализации требуемой функционалn= 0;ной пригодностl= 0; с допустимымl= 0; рисками.<o:p></o:p> <o:p= ></o:p> <h1> <a name=3D"_Toc508102489"></a><a name=3D"_Toc508102262">10.4. Риски пр = 80; формированl= 0;и требований = 82; характерисm= 0;икам сложн= ;ых программныm= 3; средств</a><o:p></o:p></sp= an></h1> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'><o:p> </o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Для продолжениn= 3; разработки проекта пос = 83;е оценки рисков масштаба комплекса программ, необходимо выполнить цикл поэтап = 85;ого определениn= 3; и формированl= 0;я сово = 82;упности спецификацl= 0;й требований = 82; проекту ПС. Первым этапом является создание концепцl= 0;и проекта ПС и комплекса первичных т = 88;ебований к иерархичесl= 2;ому набору функций, на которые могут быть разбиты предполагаk= 7;мые фактическиk= 7; компоненты ПС. В дальней&#= 1096;ем разбиение может детализироk= 4;аться, формируя уп = 88;ощенный или более точный уров = 77;нь абстракции = 80; взаимодейсm= 0;вия компонентоk= 4;. Поэтапная разработка спецификацl= 0;й требований проекта ПС выпол= ;няется итерационнl= 6; после первичной оценки масштаба проекта ПС и обусловленl= 5;ых такими оценками рисков, вследствие ошибок размера в большую или меньшую сто = 88;ону (см. рис. 10.5). Ограничениn= 3; при прогноз = 80;ровании требований, <sp= an style=3D'mso-bidi-font-style:italic'> = ;определя= 02;тся, прежде всег = 86;, имеющимися данными, которые могут быть и= 089;пользован= 099; в качестве исходных аналогов ил = 80; обобщенных характерисm= 0;ик. <o:p></o:p> Для устранения или снижени= 03; рисков до допустимых пределов мо = 78;ет быть необхо = 76;имо изменение требований = 82; функционалn= 0;ной пригодностl= 0;, к конструкт = 80;вным характерисm= 0;икам и доступным ресурсам. Поэтому на этапах проектировk= 2;ния последова = 90;ельно должны определятьl= 9;я: <o:p></o:p> <p class=3DMsoBodyTextIndent2 style=3D'margin:0cm;margin-bottom:.0001pt;tex= t-align: justify;text-indent:35.45pt;line-height:normal;mso-list:l210 level1 lfo164; tab-stops:list 14.2pt 71.25pt;mso-layout-grid-align:none;text-autospace:non= e'><![if !supportLists]>- &nb= sp; <![endif]> при проектировk= 2;нии концепции и первичной оценке масш = 90;аба проекта = - предваl= 8;ительные требования = 82; назначению, функционалn= 0;ной пригодностl= 0; и к номенклатуl= 8;е необходимыm= 3; конструктиk= 4;ных характерисm= 0;ик качества ПС; <o= :p></o:p> при предваритеl= 3;ьном проектировk= 2;нии <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-weight:bold'>-</span= > уточненная оценка масштаба проекта, требованиn= 3; к функциона = 83;ьным и конструктиk= 4;ным характерисm= 0;икам качества с учетом общи = 93; ограничениl= 1; ресурсов, перечень ис = 90;очников угроз и величины возможных рисков;<o:p></o:p> при детальном проектировk= 2;нии <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-weight:bold'>-</span= > под= робные спецификацl= 0;и требований = 82; функционалn= 0;ным и конструкт = 80;вным характерисm= 0;икам качества с детальным учетом и распределеl= 5;ием реальных ог = 88;аниченных ресур= ;сов, а также интегральнm= 9;е риски при их</s= pan> оптимизацl= 0;я по критерию = 082;ачество/зат= раты.<o:p></o:p> На этапе со= 079;дания концепции и системного анализа фор = 84;ируются цели разраб = 86;тки проекта ПС, выбираются методы и алгоритмы решения основных, функциональны&#= 1093; задач, а также формулируюm= 0;ся предваритеl= 3;ьные критерии качества создаваем= ых программ. Пр= 080; этом, естественнl= 6;, встает вопрос о ресурсах, которые потребуютсn= 3; для достижения = 94;елей, и о возможностl= 0; их реализации. </s= pan>Целенаправ&= #1083;енная и методична= 03; экспертная оценка возможного масштаба и ресурсов пр = 86;екта уменьшает величину риска, однако, обычно она остается все-таки довольно бо = 83;ьшой. <o:p></o:p> До завершения разработки первичного техническоk= 5;о задания на П= 057; могут быть сформулироk= 4;аны только приближен = 85;ые исходные требования, </s= pan>отража= ;ющие объект разр = 72;ботки и условия ег= 086; создания. Посл= ;е выбора технологии, средств автоматизаm= 4;ии разработки = 80; техн= ологическиm= 3; ЭВМ появляется возможностn= 0; достоверно учесть эти исходные да = 85;ные для подготовки уточненногl= 6; сценария разработки. Регистрациn= 3; этих данных </s= pan>може= ;т служить дополнителn= 0;ным ориентиром для оценки п= 086;лных р= ;есурсов на разработку, = 080; возможных р = 80;сков.<o:p></o:p> </spa= n>Разрабо= ;тку и утверждениk= 7; спецификацl= 0;й требований = 82; функционалn= 0;ным характерисm= 0;икам и качеству П= 057; с учетом анализа рис = 82;ов, целесообраk= 9;но проводить итерационнl= 6; на этапах предваритеl= 3;ьного и детальног = 86; проектировk= 2;ния. Чем крупнее и сл= 086;жней проект ПС и соответствk= 7;нно выше его стоимость, тем тщательнее следует разрабатывk= 2;ть требования = 82; его характерисm= 0;икам и распределяm= 0;ь ресурсы на и= 093; реализацию. Поэтому при средней и относительl= 5;о невысокой сложности П = 57; во многих случаях мож = 85;о удовлетворl= 0;ться подготовкоl= 1; требований = 82; комплексу п = 88;ограмм с подробностn= 0;ю анализа, соответствm= 1;ющего предваритеl= 3;ьному проектировk= 2;нию. Для крупных = 080; особо сложных проектов необходим более детальl= 5;ый анализ факторов и рисков при разработке требований = 80; их оптимиза = 94;ия по критерию = 082;ачество/зат= раты. <o:p></o:p> При первоначалn= 0;ном определениl= 0; требований = 82; функционалn= 0;ной пригодностl= 0; и к конструктиk= 4;ным характерисm= 0;икам, заданные за = 82;азчиком ограничениn= 3; ресурсов не всегда могу = 90; учитывать ряд особенн = 86;стей и характери = 89;тик проекта, что обусловит недопустимl= 6;е снижение (ил= 080; завышение) требований = 82; некоторым характерисm= 0;икам или рискам ПС. Кроме тог&#= 1086;, возможно, чт= 086; некоторые характерисm= 0;ики противореm= 5;ивы или принцип = 80;ально нереализуеl= 4;ы в данном проекте. В результате не сбалансироk= 4;анные требования и досm= 0;упные ресурсы проявятся как риски – уще= 088;б в виде потер= 100; в качестве или в потребностl= 0; дополнителn= 0;ных ресурсов (см. рис. 10.5). <o:p></o:p> В зависимостl= 0; от сложност = 80; проекта окончательl= 5;ым результатоl= 4; работ при предваритеl= 3;ьном или детальн = 86;м проектировk= 2;нии должны быть детализироk= 4;анные и утвержденнm= 9;е требования = 82; номенклатуl= 8;е, свойствам и значениям качества и допустимым = 88;искам проекта ПС, которые достаточны для его полн= 086;ценного рабочего проектировk= 2;ния и последующ = 77;й, эффективноl= 1; эксплуатацl= 0;и. Однако на по= 089;ледующих этапах жизн = 77;нного цикла и при конфигурацl= 0;онном управлении, требования могут измен= 03;ться по согласов = 72;нию между заказ = 95;иком и разработчиl= 2;ом, которые чащ = 77; всего приурочиваn= 2;тся к подготовк = 77; новой версии= ПС. Для этого необх = 86;дим мониторинг масштаба проекта, требований = 80; реализаций характерисm= 0;ик и рисков в течение всего ЖЦ ПС. По = 89;ле определениn= 3; назначения = 80; функций ПС, подготовка исходных данных и концепции проекта должны завершатьсn= 3; выделением номенклатуl= 8;ы приоритетнm= 9;х конструктиk= 4;ных характерисm= 0;ик, имеющих достаточнl= 6; сильное влияние на функционалn= 0;ную пригодностn= 0; и сокращающиm= 3; риски ПС.<o:p></o:p> Принципиаl= 3;ьные и техническ = 80;е возможностl= 0;, точность реализации свойств и измерения значений характерисm= 0;ик ПС, а также оk= 3;щие ресурсы конкретноk= 5;о проекта вс = 77;гда ограничены = 74; соответствl= 0;и с их содержа= 085;ием и возможностn= 3;ми заказчика и разработчиl= 2;ов. Это определяет рk= 2;циональные диапазоны значений каждого риска, которые могут быть в= 099;браны для проекта ПС на основе требований = 79;аказчика, здравого смысла, а также путем анализа пилотных пр = 86;ектов и прецедентоk= 4; в спецификацl= 0;ях требований реализованl= 5;ых проектов. Пр= 080; ограниченнl= 6;сти ресурсов проекта ПС распределеl= 5;ие приоритетоk= 4; должно стан = 86;виться более строгим и могут снижаться приоритеты характерисm= 0;ик, для реализа = 94;ии которых рес = 91;рсов недостаточl= 5;о. В результат = 77; формируетсn= 3; полный набо = 88; требуемых функционалn= 0;ных и конструктиk= 4;ных характерисm= 0;ик, свойств и допустимыm= 3; рисков в ЖЦ ПС (см= ;. рис. 10.5). </span= ><o:p></o:p> Для разработчиl= 2;ов особенно ва = 78;но формализовk= 2;ть требования = 82; качеству и с= 086;гласовать их риски с заказчиком при утверждениl= 0; контракта и техническоk= 5;о задания на проект ПС. Требования = 82; функционалn= 0;ным характерисm= 0;икам, качеству и допустимым рискам, утвержденнm= 9;е после предваритk= 7;льного проектировk= 2;ния, могут быть закреплены = 74; техническоl= 4; задании как обязательнm= 9;е для детального = 80; рабочего пр = 86;ектировани&#= 1103;. Эти данные могут использоваm= 0;ься при последу= 02;щем оценивании качества и реальных рисков, и при их сопоставлеl= 5;ии с требовани= 03;ми в процессе к= 074;алификацио&= #1085;ных испытаний или сертифи = 82;ации ПС. Однако для крупном = 72;сштабных и дорогих проектов может потре = 73;оваться уточнение требований = 82; качеству при детальном проектировk= 2;нии с позиции улучшения с = 86;отношения значений качества и затрат ресу = 88;сов, которые необходимы или допустимы для их реали= 079;ации в ЖЦ ПС.&nbs= p; <o:p></o:p> = Для заказч = 80;ка и пользоватеl= 3;ей может иметь значение не только определениk= 7; функционаl= 3;ьной пригодностl= 0;, но и оценка потенциальl= 5;ого спроса на рынке конкретногl= 6; программноk= 5;о продукта, а также его кl= 6;нкурентосп= 086;собности с другими аналогичныl= 4;и по функциям ПС с учетом его качеств = 72; и стоимости. Это обстоятельl= 9;тво может определять необходимоl= 9;ть уточнения требований = 82; отдельным характерисm= 0;икам не только дл= 103; их реализац = 80;и разработчиl= 2;ами в ЖЦ ПС, но также для оценивания = 80;нтегрально&#= 1075;о качества го = 90;ового программноk= 5;о продукта по = 89;тавляемого на рынок. Для заказчиков = 80; пользоватеl= 3;ей интегральнl= 6;е качество и р= 080;ски сосредоточl= 0;ваются на функционалn= 0;ной пригодностl= 0; и метриках в использоваl= 5;ии. Для разработчиl= 2;ов важны, прежд= 077; всего, внутренние метрики и за= 090;раты ресурсов, пр= 080; которых они = 076;остигаются. Поэтому при оценивании интегральнm= 9;х характерисm= 0;ик особо сложных ПС необходимо детально учитывать это различи = 77; целей и инте= 088;есов их потребит = 77;лей. = <o:p></o:p> Обычно заказчики и разработчиl= 2;и первоначалn= 0;но устанавливk= 2;ют требования = 82; каждой характерисm= 0;ике ПС без учета относительl= 5;ых затрат на их достижение, = 072; также без детального анализа их с= 086;вместного влияния на полную функционалn= 0;ную пригодностn= 0; и риски у потребителk= 7;й. Это может приводить к значительнm= 9;м перекосам и <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>нk= 7;сбалансиро= 074;анным значениям требований </sp= an>к отдельным, взаимосвязk= 2;нным характерисm= 0;икам, на которые н= 077; рациональнl= 6; используютl= 9;я ограниченнm= 9;е ресурсы ЖЦ ПС, или к не адекватно н = 80;зким их значения = 84;. В проектах крупномасшm= 0;абных ПС это может угрожать значительнm= 9;м повышением стоимости и рисков и/или снижением конкурентоl= 9;пособности создаваемоk= 5;о программноk= 5;о продукта из-за недостаточl= 5;ого уровня отдельных показателеl= 1; качества.<o:p></o:p>= Атрибуты качества ПС имеют разли = 95;ные меры и шкалы, вследствие чего они в большинствk= 7; своем непос = 88;едственно не сопостав = 80;мы между собой. Они предваритеl= 3;ьно выбираются = 80; согласовывk= 2;ются с заказчико = 84; при последоватk= 7;льном, почти незав = 80;симом анализе каждого атрибута качества, дл= 103; использоваl= 5;ия в контракте = 080; техническоl= 4; задании. Для обобщенногl= 6; оцениваниn= 3; качества необходим учет относительl= 5;ого влияния и риска каждо = 81; конструктиk= 4;ной характерисm= 0;ики ПС, на функционалn= 0;ную пригодностn= 0;. При этом не всегда учитываютсn= 3; ресурсы для их реализац = 80;и в конкретном ПС. Это часто приводит к выдвижению ряда не раци= 086;нальных требований, которые значительнl= 6; отличаются: либо по степени влияния на функционалn= 0;ную пригодностn= 0;, либо по величине ресурсов, не= 086;бходимых для их реализации. <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>Дl= 3;я целенаправl= 3;енного эффективноk= 5;о управления рисками сложного ПС</sp= an> при проектировk= 2;нии целесообраk= 9;но иметь механ = 80;зм объединениn= 3; разнородныm= 3; характерисm= 0;ик в некоторый = 080;нтегральны&= #1081; показатель, отражающий их совокупн = 86;е влияние на его функцио = 85;альную пригодностn= 0;. Таким образом, при разработке требований = 82; характерисm= 0;икам проекта выявилась проблема анализа системной эффек= ;тивности ПС и обобщения его характерисm= 0;ик, а также оценивk= 2;ния совместногl= 6; влияния конструктиk= 4;ных характер= ;истик на функционалn= 0;ную пригодностn= 0; ПС с учетом з&#= 1072;трат на их реализ= 072;цию. <o:p></o:p> = Для управления рисками и детального сопоставитk= 7;льного оценивания выбранных характерисm= 0;ик качества целесообраk= 9;но каждому из них присваиватn= 0; коэффициенm= 0; или приорит = 77;т влияния на функционалn= 0;ную пригодностn= 0;. Группа квалифицирl= 6;ванных экспертов и = 79; состава заказчиков, потенциальl= 5;ых пользоватеl= 3;ей и/или разраб= 086;тчиков должны оценивать и устанавливk= 2;ть значения таких коэффиm= 4;иентов – рисков (приоритето = 74;) в пределах унифицировk= 2;нной шкалы, например, от единицы до десяти, для конкретногl= 6; проекта ПС. Точность определениn= 3; коэффициенm= 0;ов вряд ли може= 090; превышать 10%, поэтому ко = 83;ичество градаций шк = 72;лы целесообраk= 9;но не больше десяти. Аналогичнl= 6;, по такой же шкале экспертами целесообраk= 9;но оценивать относительl= 5;ые затраты ресурсов, которые след

MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_01D3B547.E1D69BC0" Данный документ является веб-страницей в одном файле, также называемой файлом веб-архива. Если вы видите это сообщение, значит, данный браузер или редактор не поддерживает файлы веб-архива. Загрузите браузер, поддерживающий веб-архивы, например Windows® Internet Explorer®. ------=_NextPart_01D3B547.E1D69BC0 Content-Location: file:///C:/2FFC0B4F/file7119.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Основная цель и задач= 080; учебника - представитn= 0; отечественl= 5;ым студен-там, аспирантам = 80; специалистk= 2;м современныl= 1; комплекс за = 76;ач, методов и стандартов программноl= 1; инженерии - создания и развития сложных, многоверсиl= 6;нных, тиражируемm= 9;х программныm= 3; средств и ба</t= itle>  <link rel=3DdataStoreItem href=3D"file7119.files/item0016.xml" target=3D"file7119.files/props017.xml"> <link rel=3DthemeData href=3D"file7119.files/themedata.thmx"> <link rel=3DcolorSchemeMapping href=3D"file7119.files/colorschememapping.xm= l">  <style>  </style>  </head> <body bgcolor=3D"#FFFFCC" background=3D"file7119.files/image009.jpg" lang= =3DRU link=3Dblue vlink=3Dpurple style=3D'tab-interval:35.4pt'>  <div class=3DWordSection1> <o:p> </o:p> Курс лекций по дисциплине: &la= quo;Программна&= #1103; инженерия»<o:p>= </o:p> <o:p> </o:p> Подгото= ;вил: к.э.н., доцент Гаджиев Н.К.<o:p></o:= p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <a href=3D"#_Toc50810= 2444">Аннотация.. </spa= n>6</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2445">Лекция 1. Программнаn= 3; инженерия в жизненном цикле программныm= 3; средств.. 11</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2446">1.1. Основы жизненного цикла программныm= 3; средств.. 11</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2447">1.2. Роль системотехl= 5;ики в программн = 86;й инженерии.. </spa= n>17</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2448">1.3. Системные основы современныm= 3; технологий программнl= 6;й инженерии.. </spa= n>20</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2449">Лекц&= #1080;я 2. Профили стандартов жизненного цикла систе = 84; и программнm= 9;х средств в программноl= 1; инженерии.. </spa= n>27</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2450">2.1. Назначение профилей стандартов жизненного цикла в программнl= 6;й инженерии.. </spa= n>27</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2451">2.2. Жизненный цикл профилей стандартов систем и про= 075;раммных средств.. 32</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2452">2.3. Модель профиля стандартов жизне= ;нного цикла сложных программныm= 3; средств.. 40</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2453">Лекция 3. Модели и процессы управления проектами программныm= 3; средств 43</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2454">3.1. Управление проектами программнm= 9;х средств в системе – СMMI 43</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2455">3.2. Стандарты менеджментk= 2; (администра = 90;ивного управления) качеством систем... 54</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2456">3.3. Стандарты открытых систем, регламентиl= 8;ующие структуру и интерфейсm= 9; программнm= 9;х средств.. 67</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2457">Лекция 4. Системное проектировk= 2;ние программныm= 3; средств.. 73</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2458">4.1. Цели и принципы системного проектировk= 2;ния программнm= 9;х средств.. 73</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2459">4.2. Процессы системного проектировk= 2;ния программныm= 3; средств 80</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2460">4.3. Структурноk= 7; проектировk= 2;ние сложных про = 75;раммных средств 85</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2461">4.4. Проектировk= 2;ние программныm= 3; модулей и ко= 084;понентов </= span>90</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2462">Лекция 5. Технико-эко = 85;омическое обоснованиk= 7; проектов программныm= 3; средств.. 95</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2463">5.1. Цели и процессы технико-эко = 85;омического обоснованиn= 3; проектов программныm= 3; средств.. 95</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2464">5.2. Методика 1 – экспертное технико-эк = 86;номическое<s= pan style=3D'mso-spacerun:yes'> обос= нование проектов программныm= 3; средств.. 107</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2465">5.3. Методика 2 – оценка технико-эко = 85;омических показателеl= 1; проек= ;тов программныm= 3; продуктов с учетом сово = 82;упности факторов = предваритk= 7;льной модели СОСОМО II</s= pan>. </span= >111</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2466">5.4. Методика 3 – уточненная оценка технико-эко = 85;омических пока= зателей проектов программныm= 3; продуктов с учетом полной совокупноl= 9;ти факторов детальной модели СОСОМО II</s= pan>.2000.. 115</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2467">Лекция 6. Разработка требований = 82; программныl= 4; средствам... </sp= an>119</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2468">6.1. Организациn= 3; разработки требований = 82; сложным программныl= 4; средствам... </sp= an>119</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2469">6.2. Процессы разработки требований = 82; характерисm= 0;икам сложных программныm= 3; средств.. 124</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2470">6.3. Структура основных документов, отражающих требования = 82; программныl= 4; средствам... </sp= an>131</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2471">Лекция 7. Планированl= 0;е жизненного цикла прогр= аммных средств 134</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2472">7.1. Организациn= 3; планированl= 0;я жизненного цикла сложн= ых программныm= 3; средств.. 134</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2473">7.2. Задачи планов для обеспечениn= 3; жизненного цикла сложных программнm= 9;х средств.. 138</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2474">7.3. Планированl= 0;е процессов управления качеством сложных программныm= 3; средств.. 142</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2475">Лекция 8. Объектно-ор = 80;ентированн&#= 1086;е проектировk= 2;ние программныm= 3; средств 146</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2476">8.1. Задачи и особенностl= 0; объектно-ор = 80;ентированн&#= 1086;го проек= ;тирования программнm= 9;х средств.. 146</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2477">8.2. Основные понятия и модели объектно-ор = 80;ентированн&#= 1086;го проек= тирования программныm= 3; средств.. 151</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2478">8.3. Варианты представлеl= 5;ия моделей и средства объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния программныm= 3; средств 159</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2479">Лекция 9. Управление ресурсами в жизненном ц = 80;кле программнm= 9;х средств 163</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2480">9.1. Основные ресурсы для обеспечениn= 3; жизненногl= 6; цикла &= nbsp; сложн= ых программныm= 3; средств.. 163</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2481">9.2. Ресурсы специалисm= 0;ов для обеспеч = 77;ния жизненногl= 6; цикла &= nbsp; сложных программныm= 3; средств.. 167</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2482">9.3. Ресурсы для обеспечениn= 3; функционалn= 0;ной пригодносm= 0;и при разработке сложных пр = 86;граммных средств.. 177</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2483">9.4. Ресурсы на реализациn= 2; конструктиk= 4;ных характерисm= 0;ик качества программныm= 3; средств.. 182</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2484">9.5. Ресурсы на имитацию внешней среды для об= 077;спечения тестироваl= 5;ия и испытаний программныm= 3; средств.. 186</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2485">Лекция 10. Дефекты, ошибки и риски в жизненном цикле прогр= аммных средств.. 189</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2486">10.1. Общие особенностl= 0; дефектов, ошибок и рисков в сложных программнm= 9;х средствах.. </spa= n>189</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2487">10.2. Причины и свойства дефектов, ошибок и модификациl= 1; в сложных программнm= 9;х средствах.. </spa= n>193</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2488">10.3. Риски в жизненном цикле сложных программныm= 3; средств 202</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2489">10.4. Риски при формированl= 0;и требований = 82; характерисm= 0;икам сложных программныm= 3; средств.. 208</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2490">Лекция 11. Характерисm= 0;ики качества п = 88;ограммных средств.. 214</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2491">11.1. Основные факторы, определяющl= 0;е качество сложных программнm= 9;х средств.. 214</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2492">11.2. Свойства и атрибуты качества функционалn= 0;ных возможностk= 7;й сложных программныm= 3; средств.. 218</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2493">11.3. Конструктиk= 4;ные характерисm= 0;ики качес= ;тва сложных программнm= 9;х средств.. 225</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2494">11.4. Характерисm= 0;ики качества ба = 79; данных.. 236</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2495">11.5. Характерисm= 0;ики защиты и безl= 6;пасности функционирl= 6;вания программныm= 3; средств.. 242</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2496">Лекция 12. Выбор характерисm= 0;ик качества в проектах прогр= ;аммных средств 251</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2497">12.1. Принципы выбора характерисm= 0;ик качества в проектах программнm= 9;х средств.. 251</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2498">12.2. Пример выбора и формированl= 0;я требований к характерисm= 0;икам качества программноk= 5;о средства.. 256</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2499">Лекция 13. Верификациn= 3;, тестированl= 0;е и оценивани = 77; корректноl= 9;ти программныm= 3; компонентоk= 4;.. </spa= n>262</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2500">13.1. Принципы верификациl= 0; и тестированl= 0;я программ... 262</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2501">13.2. Процессы и средства тестированl= 0;я программныm= 3; компонентоk= 4; </= span>271</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2502">13.3. Технологичk= 7;ские этапы и стратегии систематичk= 7;ского тестироваl= 5;ия программ... </sp= an>278</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2503">13.4. Процессы тестированl= 0;я структуры программныm= 3; компонентоk= 4; </= span>285</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2504">13.5. Примеры оценок сложности тестированl= 0;я программ... 293</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2505">13.6. Тестированl= 0;е обработки потоков данных про&= #1075;раммными компонентаl= 4;и.. </spa= n>298</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2506">Глава 14. Интеграция, квалификаm= 4;ионное тестированl= 0;е и испытания комплексов = 87;рограмм... </sp= an>302</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2507">14.1. Процессы оценивания характерисm= 0;ик и испытания прогр= аммных средств.. 303</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2508">14.2. Организациn= 3; и методы оценивания характерисm= 0;ик сложных комплексоk= 4; программ... 308</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2509">14.3. Средства для испытаний и определениn= 3; характерисm= 0;ик сложных комплексов = 87;рограмм... </sp= an>316</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2510">14.4. Оценивание надежности = 80; безопасносm= 0;и функционирl= 6;вания сложных программныm= 3; средств.. 327</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2511">14.5. Оценивание эффективноl= 9;ти использоваl= 5;ия ресурсов ЭВМ программнm= 9;м продуктом... </sp= an>332</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2512">Лекция 15. Сопровождеl= 5;ие и мониторин = 75; программныm= 3; средств 336</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2513">15.1. Организацl= 0;я и методы сопровождеl= 5;ия программныm= 3; средств 336</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2514">15.2. Этапы и процедуры при сопровождеl= 5;ии программныm= 3; средств 346</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2515">15.3. Задачи и процессы переноса программ и д= 072;нных на иные платформы... </sp= an>355</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2516">15.4. Ресурсы, для обеспечениn= 3; сопровождеl= 5;ия и мониторингk= 2; программнm= 9;х средств.. 365</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2517">Лекция 16. Управлениk= 7; конфигурацl= 0;ей в жизненном цикле программныm= 3; средств.. 371</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2518">16.1. Процессы управления конфигурацl= 0;ей программныm= 3; средств 371</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2519">16.2. Этапы и процедуры при управлении = 82;онфигураци&#= 1077;й программнm= 9;х средств.. 386</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2520">16.3. Технологиm= 5;еское обеспечениk= 7; при сопровождеl= 5;ии и управлении конфигурацl= 0;ей программныm= 3; средств.. 396</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2521">Лекция 17. Документирl= 6;вание программныm= 3; средств.. 402</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2522">17.1. Организациn= 3; документирl= 6;вания программныm= 3; средств 403</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2523">17.2. Формированl= 0;е требований = 82; документацl= 0;и сло&= #1078;ных программныm= 3; средств.. 408</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2524">Лекция 18. Удостовере&= #1085;ие качества и сертификацl= 0;я прогр= аммных продуктов.. </spa= n>420</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2525">18.1. Процессы сертификацl= 0;и в жизненном цикле = &nb= sp; программнm= 9;х средств.. 420</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2526">18.2. Организациn= 3; сертификаm= 4;ии программныm= 3; продуктов </= span>424</a></span= >= <o:p></o:p> <a href=3D"#_Toc50810= 2527">Литература= ;.. </spa= n>433</a></span= >= <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <h1><o:p> </o:p></h1> <h1><a name=3D"_Toc508102444"></a><a name=3D"_Toc508102217">Аннотаци= 03;</a></h1> <o:p> </o:p> = Основная цель курса лекций -</span= > представитn= 0; студентам, аспирантам = 80; менеджерам проектов современныl= 1; комплекс задач, метод= 086;в и стандарто = 74; программноl= 1; инженерии = - создания и развития сложных, = 084;ноговерсио&= #1085;ных, тиражируемm= 9;х программныm= 3; средств (ПС) и баз данных (Б&#= 1044;) требуемого высокого ка = 95;ества. Изложение ориентировk= 2;но на коллекти = 74;ную, групповую работу специалистl= 6;в над крупным = 80; программныl= 4;и проектами. Внимание акцентировk= 2;но на комплекс = 77; методов и пр= 086;цессов, которые спо = 89;обны непосредстk= 4;енно обеспечить = 01;ффективный жизненный цикл сложны = 93; высококаче= ственных программныm= 3; продуктов и баз данных. При этом пре= 076;полагаетс= 103;, что процесс = 99; и технологи= 03; создания ко = 84;плексов программ и документов опираются н = 72; совокупносm= 0;ь современныm= 3;, автоматизиl= 8;ованных методов и инструментk= 2;льных средств поддержки длительногl= 6; жизненного цикла программнm= 9;х продуктов. О= 076;нако не всегда эт= 086; может быть рентабельнl= 6; вследствие высокой стоимости т = 72;ких средств. В результате может снижаться к = 72;чество программныm= 3; продуктов и повышаться = 80;х стоимость.<o:p></o:p>= Быстрый рост областей применения, сложности функций и масштабов комплексов программ привел к принципиалn= 0;ному изменению м = 77;тодов в этой сфере &#= 1080; к переходу о= 090; технологии = 80;ндивидуаль&#= 1085;ого программирl= 6;вания отдельных небольших программок = 82; коллективн&= #1086;му созданию кр = 91;пных комплексов программ инженернымl= 0; методами проектировk= 2;ния и разработк = 80;. Накоl= 7;ление в мире знани= 081;, опыта разработки = 80; применения огромного количества различных с = 83;ожных программ дл= 03; ЭВМ, способс= 090;вовал систематизk= 2;ции и обобщению методов и т= 077;хнологий их разработ = 82;и, сокращению дефектов и н= 077;определенн&= #1086;стей в характери = 89;тиках и качестве поставляемm= 9;х и применяем = 99;х программныm= 3; продуктов. В результате сформироваl= 3;ась современнаn= 3; методологиn= 3; и инженерна= 03; дисциплина обеспечениn= 3; процессов жизненного цикла сложных программныm= 3; продуктов – программнаn= 3; инженерия для различн = 99;х областей применения. <o:= p></o:p> Программнk= 2;я инженерия = - это область компьютернl= 6;й науки и технологии, которая занимается построениеl= 4; программныm= 3; систем, настолько больших и сложных, что для этого требуется участие сла = 78;енных команд разработчиl= 2;ов различных с = 87;ециальност&#= 1077;й и квалификацl= 0;й. Обычно таки = 77; системы существуют = 80; применяютсn= 3; долгие годы, развиваясь от версии к версии, претерпеваn= 3; на своем жизненном пути множес = 90;во изменений, улучшение с = 91;ществующих функций, доб= 072;вление новых или удаление устаревших возможностk= 7;й, адаптацию для работы в новой среде, устранение дефектов и ошибок. Суть &#= 1084;етодологии программноl= 1; инженерии с = 86;стоит в применени = 80; систематизl= 0;рованного, научного и п= 088;едсказуемо&= #1075;о процесса пр = 86;ектировани&#= 1103;, разработки = 80; сопровождеl= 5;ия программныm= 3; средств.<o:p></o:p> Массовое создание сложных программныm= 3; средств l= 7;ромышлен</spa= n>ными меm= 0;одами и большими коллективаl= 4;и специалистl= 6;в вызвало необходи&#= 1084;ость их четкой организациl= 0;, планированl= 0;я работ по тре= 073;уемым ресурсам, этапам и сро&sh= y;кам реализации. Совокупные затраты в мире на таки= 077; разработки </sp= an>состав= 083;яют миллиарды, а для отдельных проектов <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";letter-spacing:.35pt;mso-char-type: symbol;mso-symbol-font-family:Symbol'>- миллионы долларов в год, поэтому требуется тщательный анализ экон = 86;мической эффективноl= 9;ти создания и и= 089;пользова<sp= an style=3D'font-size:14.0pt;letter-spacing:.4pt'>ния к= ;онкретных ПС. Для решения эти = 93; задач в прог= 088;аммной инженерии ф = 86;рмируется новая область зна= ;ния l= 0; научная дис = 94;иплина <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";letter-spacing:.3= 5pt; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- экономl= 0;ка жизненного цикла про</span= >граммнm= 9;х средств, как часть экономики п = 88;омышленнос&#= 1090;и и вычислительl= 5;ой техники в общей экономике государств = 80; предприятиl= 1;. Объекти = 74;но положение осложнено трудностью </sp= an>изме= рения экономичесl= 2;их характерисm= 0;ик таких объектов. Широкий спектр количествеl= 5;ных и качествен = 85;ых показателеl= 1;, которые с различных сторон характеризу= ;ют содержание этих объектов, и невысокая достоверноl= 9;ть оценки их значений, определяют значительнm= 1;ю дисперсию п = 88;и попытках описать и из= 084;ерить экономичесl= 2;ие свойства созд= ;аваемых или используемm= 9;х крупных ПС. <o:p></o:p> Вследствиk= 7; роста сфер применения = 80; ответственl= 5;ости функций, выполняемыm= 3; программамl= 0;, резко возро = 89;ла необходимl= 6;сть гарантировk= 2;ния высокого качества пр = 86;граммных продуктов, регламентиl= 8;ования и корректно = 75;о формированl= 0;я требований = 82; характерисm= 0;икам реальных комплексов программ и и= 093; достоверноk= 5;о определениn= 3;. В результат = 77; специалистm= 9; в области теории и мет= 086;дов, определяющl= 0;х качество продукции, в= 099;нуждены осваивать область развития и п= 088;именения нового, специфичесl= 2;ого продукта – п= 088;ограммных средств и систем в целом, и их качество пр = 80; использова&= #1085;ии. Сложность анализируеl= 4;ых объектов – комплексов программ и п= 089;ихологичес&= #1082;ая самоуверенl= 5;ость ряда програ = 84;мистов в собственноl= 1; “непогрешиl= 4;ости”, часто приводят к тому, что реальные ха = 88;актеристик&#= 1080; качества функционирl= 6;вания программныm= 3; продуктов о = 89;таются неизвестныl= 4;и не только дл= 103; заказчиков = 80; пользоватеl= 3;ей, но также для самих разра = 73;отчиков. Отсутствие четкого декларировk= 2;ния в документа = 93; понятий и требуемых значений характерисm= 0;ик качества ПС вызывает конфликты между заказчикамl= 0;-пользовате&#= 1083;ями и разработчиl= 2;ами-поставщ&#= 1080;ками из-за разной трак = 90;овки одних и тех же характер = 80;стик. <o:p></o:p> &n= bsp; Методы программноl= 1; инженерии поддерживаn= 2;т и конкретиз = 80;руют технологичk= 7;ский процесс, а также отслеживанl= 0;е значений качества ко = 84;понентов на этапах жизненного цикла ПС. Для каждого про = 77;кта, выполняющеk= 5;о ответственl= 5;ые функции, должны разр = 72;батываться и применятьсn= 3; система качества, специальныk= 7; планы и Программа, методологl= 0;я и инструмен = 90;альные средства разработки = 80; испытаний, обеспечиваn= 2;щие требуемые качество, надежность = 80; безопасносm= 0;ь функционирl= 6;вания программныm= 3; продуктов. Эти методы и процессы позво= ;ляют разработчиl= 2;ам и заказчика = 84; программныm= 3; продуктов более корре = 82;тно взаимодейсm= 0;вовать при определениl= 0; и реализаци = 80; требований контрактов = 80; техническиm= 3; заданий.<o:p></o:p> Основны= ;е концепции программноl= 1; инженерии сконцентриl= 8;овались и формализо = 74;ались в целостном = 082;омплексе систематизl= 0;рованных международl= 5;ых стандартов, охватывающl= 0;х и регламентиl= 8;ующих практическl= 0; все процесс = 99; жизненного = 94;икла сложных про = 75;раммных средств. Несколько десятков стандартов этого комплекса д = 86;пускают целеустремl= 3;енный отбор необходимыm= 3; процессов, в зависимостl= 0; от характерисm= 0;ик и особенносm= 0;ей конкретногl= 6; проекта, а также формированl= 0;е на их базе проблемно-о = 88;иентирован&#= 1085;ых профилей стандартов для определеннm= 9;х типов проек = 90;ов и/или предпр= 080;ятий. <o:p></o:p> Практич= ;еское применение профилей стандартов, сосредоточl= 0;вших мировой опы = 90; создания различных типов крупных комплексов программ, способствуk= 7;т значительнl= 6;му повышению производитk= 7;льности труда специ = 72;листов и качества создаваемыm= 3; программныm= 3; продуктов. Эти стандар = 90;ы определяют модификациn= 2;, мобильностn= 0; и возможнос = 90;ь повторного применения программныm= 3; компонентоk= 4; и комплексо = 74;, их расширяемоl= 9;ть и переносим = 86;сть на различны = 77; аппаратные = 80; операционнm= 9;е платформы, что непосре = 76;ственно отражается на росте эко= 085;омической эффективноl= 9;ти технологий = 80; процессов с = 86;здания различных программныm= 3; средств и систем. Для регламентиl= 8;ования процессов жизненного цикла такие профили ста = 85;дартов должны адаптироваm= 0;ься и конкретиз= ;ироваться применителn= 0;но к определеннm= 9;м классам и функциям пр = 86;ектов, процессов и компонентоk= 4; программныm= 3; средств. При этом должна сохранятьсn= 3; концептуалn= 0;ная целостностn= 0; применяемоl= 1; совокупносm= 0;и стандартов = 80; их эффектив = 85;ое, положительl= 5;ое влияние на процессы и результаты, на качество, надежность = 80; безопасносm= 0;ь программныm= 3; продуктов при реальны = 93; ограничениn= 3;х на использо = 74;ание доступных ресурсов проектов.<o:p></o:p>= <= span style=3D'mso-spacerun:yes'> В жизненном цикле комплексов программ сложно соче = 90;аются содержание, этап= ;ы и распределеl= 5;ие работ, возможен ря = 76; возвратов н = 72; более ранние технологичk= 7;ские этапы в процессе создания ко = 84;понентов ПС, они имеют не совсем опре = 76;еленные границы начала и завершения. Спеm= 4;иалисты в коллектив = 77; могут на некотором интервале в = 88;емени реша= ;ть несколько производстk= 4;енных задач и заме= 085;ять друг друга. <s= pan style=3D'letter-spacing:.15pt'>Положе&#= 1085;ие усугубляетl= 9;я трудностью поэтапного определениn= 3; качk= 7;ства компонентоk= 4; и его прогно= 079;ирования в процессе разработки, что н&#= 1077;посредстве= нно отражается на пр&#= 1086;екте в целом. Мет&#= 1086;дология программноl= 1; инженерии и стандарты р = 77;гламентиру&#= 1102;т современныk= 7; процессы управления проектами сложных систем и программныm= 3; средств. Они обеспечиваn= 2;т организациn= 2;, освоение и применение апробироваl= 5;ных, высококачеl= 9;твенных процессов проектировk= 2;ния, программирl= 6;вания, верификациl= 0;, тестированl= 0;я и сопровожд = 77;ния программныm= 3; средств и их компонентоk= 4;. Тем самым эт= 080; проекты и процессы позволяют получать ст = 72;бильные, предсказуеl= 4;ые результаты = 80; программныk= 7; продукты требуемого качества. <o:p></o:p></span= > Многообра= 079;ие классов и ви&sh= y;дов сложных комплексов программ, об= 091;словленное различными функциями и сферами применения = 89;истем, определяет формальные трудности, связанные с методами и п= 088;оцедурами д= ;оказательс= ;тва соответствl= 0;я создаваемыm= 3; и поставляе = 84;ых программныm= 3; продуктов условиям контрактов, требованияl= 4; заказчиков = 80; потребителk= 7;й. По мере расширения применения = 80; увеличения сложности систем, выделились области, в которых дефекты, нед= 086;статочное качество комплексов программ ил = 80; данных могу = 90; наносить катастрофиm= 5;еский ущерб, значительнl= 6; превышающиl= 1; положительl= 5;ый эффект от их использоваl= 5;ия. В таких криm= 0;ических системах (например, управления = 72;томными электростаl= 5;циями, крупными ба = 85;ками или системами вооружения) недопустимm= 9; проявления катастрофиm= 5;еских рисков функционирl= 6;вания программныm= 3; продуктов при любых ис= 082;ажениях исходных данных, сбоях, части= 095;ных отказах апп= ;аратуры, ошибках пользоватеl= 3;ей и других нештатных ситуациях. Подобные риски компл = 77;ксов программ мо = 75;ут определять безопасносm= 0;ь функционирl= 6;вания объектов, предприятиl= 1; и даже стран= 099;. Вследствие этого резко повысилась = 86;тветственн&#= 1086;сть специалистl= 6;в за качество результатоk= 4; их труда и создаваемыm= 3; программныm= 3; продуктов. Это требует непрерывноk= 5;о совершенстk= 4;ования, обучения и повышения квалификацl= 0;и заказчиков, разработчиl= 2;ов и пользоватеl= 3;ей в области программноl= 1; инженерии, освоения им = 80; современныm= 3; методов, процессов и международl= 5;ых стандартов, = 072; также высокой корпоративl= 5;ой культуры коллективоk= 4; специалистl= 6;в, обеспечиваn= 2;щих жизненный цикл критическиm= 3; программныm= 3; продуктов.<o:p></o:p>= В курсе лекци = 81; предполагаk= 7;тся, что проекти = 88;ование, разработка, сопровождеl= 5;ие и документирl= 6;вание программныm= 3; продуктов ведется пре = 80;мущественн&#= 1086; с использоваl= 5;ием регламентиl= 8;ованных процессов н = 72; основе профилей стандартов ISO в = соответстk= 4;ии с формализо = 74;анными требованияl= 4;и определеннm= 9;ми заказчиком. Тем самым не отражено со = 79;дание и применени = 77; открытого кода в прогр= 072;ммных продуктах, при котором = 085;евозможна их сертификацl= 0;я на соответс = 90;вие международl= 5;ым стандартам, вследствие неоднозначl= 5;ости версий ПС, изменяемых = 85;е синхронно р = 72;зличными пользоватеl= 3;ями и различным = 80; предприятиn= 3;ми. <o:p></o:p> Зна&#= 1095;ительное внимание в курсе метод = 86;логии программноl= 1; инженерии у = 76;елено фрагментам = 80; компонентаl= 4; профилей стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'>, целесообраk= 9;ным для обеспечениn= 3; высокого качества и безопасносm= 0;и применения = 87;рограммных продуктов в = 080;х жизненном цикле. Менеджмент = 88;ассматрива&#= 1077;мых проектов ориентировk= 2;н преимущестk= 4;енно на базовые стандарты серии ISO 9000:2000. Стандарты = де-факто менеджментk= 2; CMM / </span= >CMMI= изложеl= 5;ы как возможная альтернатиk= 4;а стандартам </sp= an>ISO<= span style=3D'font-size:14.0pt'> при упр = 72;влении проектировk= 2;нием ПС, однако, он&= #1080; не покрываю = 90; все процесс = 99; жизненного цикла сложных ком = 87;лексов программ. Наиболее ра = 89;пространен&#= 1085;ая сертификацl= 0;я предприятиl= 1;, производящl= 0;х программныk= 7; продукты на соответствl= 0;е стандартам CMM / CMMI существеннl= 6; проще, чем се&#= 1088;тификация на соответствl= 0;е полному про = 92;илю стандартов = 74;сего жизненного цикла ISO= . При пр= ;именении моделей CMM / CMMI учитыва= ;ется преи&= #1084;ущественно качество менеджментk= 2; проектов, однако не стандартизl= 0;руются и не контрол= 080;руются некоторые в = 72;жные компоненты = 87;роцессов ЖЦ: регламен= 090;ированные характерисm= 0;ики качества ПС; интерфейсы = 54;ткрытых систем; функ= 094;иональная и информациоl= 5;ная безопасносm= 0;ь; комплекс те = 93;нологическ&#= 1086;й и эксплуатацl= 0;онной документацl= 0;и. Это может быть оправдано для предприятиl= 1;, создающих программныk= 7; продукты средней или = 086;тносительн&= #1086; не высокой сложности, и вряд ли допус= ;тимо для разрабо = 90;чиков крупных, осо= 073;о сложных, кри= 090;ических ПС. Ак = 94;ент методологиl= 0; программно&#= 1081; инженерии н = 72; крупные про = 77;кты предполагаk= 7;т сохранение = 80; возможностn= 0; применения её базовых методов, процессов и стандартов при обеспечениl= 0; жизненного цикла относ = 80;тельно небольших проектов. Для эm= 0;ого должна быть = 087;редусмотре&= #1085;а и использовk= 2;ться адаптация с = 90;андартов, технологий = 80; инструментk= 2;рия для различн = 99;х по сложност = 80; и размеру пр= 086;ектов.<o:p></o:p> В публикацияm= 3; в области программноl= 1; инженерии широко расп = 88;остранено изобретениk= 7; многочислеl= 5;ных аббревиатуl= 8; на основе английских, = 080;ногда полужарk= 5;онных слов, которы= 077; выдаются за принципиалn= 0;ные достижения авторами публикаций. = 042; тексте лекций для облегчения восприятия учащимися, из&= #1073;егается прим&= #1077;нение аббревиатуl= 8;, за исключениеl= 4; небольшого = 80;х числа, на основе част = 86; используемm= 9;х словосочетk= 2;ний русских сло = 74;. В официальныm= 3; документах = 74; имени стандартов </sp= an>ISO<= span lang=3DEN-US style=3D'font-size:14.0pt'> часто присутствуn= 2;т через слеш имя IEC (Междунk= 2;родная электротехl= 5;ическая комиссия). Для сокращения = 80; упрощения текста лекций имя <sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-ansi-language:EN-US'>IEC<= span style=3D'font-size:14.0pt'> всюду опускается, однако его следует учитывать при использ = 86;вании и формированl= 0;и официальныm= 3; документов. <o:= p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'>Предл = 72;гаемый курс основ методологиl= 0; программноl= 1; инженерии предназначk= 7;н для заказчи = 82;ов, менеджеров крупных проектов, для аналитиков = 80; ведущих специалистl= 6;в, обеспечиваn= 2;щих все этапы жизненного цикла крупных про = 75;раммных средств и систем. Лекции реко = 84;ендуется испо&= #1083;ьзовать при обучk= 7;нии по специаль = 85;ости информатикk= 2;, студентов старших курсов, аспирантов = 80; менеджеров проектов, созданию сложных ком = 87;лексов программ на всем их жизненном цикле. Курс полезен исполнителn= 3;м научных проектов и опытно-конс = 90;рукторских работ, к которым пре = 76;ъявляются высокие требования = 82; качеству функционирl= 6;вания и ограничен = 99; доступные ресурсы разработки программныm= 3; продуктов. Материалы л = 77;кций могут служить базой при подготовке = 80; внедрении систем каче = 89;тва предприятиl= 1;, создающих сложные кон = 82;урентоспос&#= 1086;бные программныk= 7; продукты, дл= 103; их сертификацl= 0;и на соответствl= 0;е международl= 5;ым стандартам. <o:= p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'><o:p> </o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'><o:p> </o:p> <h1> <a name=3D"_Toc508102445"></a><a name=3D"_Toc508102218">Лекция 1. Программнаn= 3; инженерия в жизненном цикле программныm= 3; средств</a></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'><o:p> </o:p>= <h1><a name=3D"_Toc508102446"></a><a name=3D"_Toc508102219">1.1. Основы жизненного цикла программныm= 3; средств</a></h1> <o:p>&nbs= p;</o:p> Термином жl= 0;зненный цикл (ЖЦ) принято отражать совокупносm= 0;ь процессов и этапов развития организмов живой природы, техническиm= 3; систем, прод= 091;ктов производстk= 4;а от моментов зарождения или появлен = 80;я потребностl= 0; их создания = 080; использоваl= 5;ия до прекраще = 85;ия функционирl= 6;вания или примене = 85;ия. Это соответствm= 1;ет всеобщему з = 72;кону развития любых изделий, событий или процессов м = 77;жду их началом и концом, которые определяют цикл их создания, су= 097;ествования и применени= 03;. Программы для вычислителn= 0;ных машин обычн = 86; являются кl= 6;мпонентами жизненного цикла техническиm= 3; систем, но по своей при= 088;оде значительнl= 6; отличаются от аппаратурнm= 9;х, техническиm= 3; изделий, поэтому их жизненный цикл имеет характерныk= 7; особенностl= 0;, по сравнени= 02; с другими техническиl= 4;и объектами. Программы и данные в сис= 090;емах и вычислителn= 0;ных машинах являются наиболее гl= 0;бкими компонентаl= 4;и программноl= 1; инженерии и подвержены изменениям</spa= n> в течение всего их ЖЦ. <o:p></o= :p> <sp= an style=3D'mso-bidi-font-size:14.0pt;mso-bidi-font-weight:bold;mso-bidi-font-= style: italic'> Типовая модель процессов жизненного цикла сложной сис = 90;емы начинается = 89; концепции идеи систем = 99; или потребн = 86;сти в ней, охватывает проектировk= 2;ние, разработку, применениk= 7; и сопровожд = 77;ние системы, и за&#= 1082;анчивается снятием системы с эксплуатацl= 0;и. Программныk= 7; средства сл = 91;жат для выполнения определеннm= 9;х функций сис = 90;ем на компьюте = 88;ах. Модель жизненного цикла системы обычно разд = 77;ляют на последов = 72;тельные периоды реализации </sp= an>= - стади= 080; или этапы. Каждый подобный период вклю = 95;ает основные реализуемыk= 7; в нем процессы, работы и задачи, при з&#= 1072;вершении которых может потребоватn= 0;ся переход к следующему периоду реа = 83;изации. Общую модел= 00; жизненного цикла сложн = 86;й системы обычно разд = 77;ляют на следующи = 77; основные этапы с последующеl= 1; адаптацией каждого из них в модели <s= pan style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>жl= 0;зненного цикла конкретной = 89;истемы:<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>опред = 77;ление потребностk= 7;й;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>иссле = 76;ование и описание основных концепций;<o:p></o:p>= <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>проек = 90;ирование и разработк = 72;;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>испыт = 72;ния системы;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>созда = 85;ие и производстk= 4;о;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>распр = 86;странение и продажа;<o:p></o:p></span= > <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>экспл = 91;атация;<o:p></o:p> <p class=3DMsoBodyText style=3D'margin-left:0cm;text-align:justify;text-ind= ent: 35.45pt;mso-pagination:none;mso-list:l41 level1 lfo6;tab-stops:list 18.0pt = left 41.3pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- <![endif= ]>сопро = 74;ождение и мониторин = 75;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>с = 85;ятие с эксплуатацl= 0;и (утилизация).<o= :p></o:p> По особеннос = 90;ям и свойствам жизненного цикла программ их целесообраk= 9;но делить на ря= 076; классов и категорий, и= 079; которых наиболее различающиl= 4;ися являются дв = 72; крупных класса – малые и большие. <o:p></o:p></span= > = 55;ервый класс составляют относительl= 5;о небольшие программы, создаваемыk= 7; одиночками или небольш = 80;ми коллективаl= 4;и (3 –5) специалис= ;тов, которые:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здаются преимущестk= 4;енно для получен = 80;я конкретных = 88;езультатов автоматизаm= 4;ии научных исследованl= 0;й или для анал= 080;за относительl= 5;о простых процессов самими разработчиl= 2;ами программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>н = 77; предназначk= 7;ны для массового тиражироваl= 5;ия и распростр = 72;нения как пl= 8;ограммного продукта на рынке, их оценивают качественнl= 6; и интуитивн = 86; преимущестk= 4;енно как “художестk= 4;енные произведенl= 0;я”; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77; имеют конкретногl= 6; независимоk= 5;о заказчика-п = 86;требителя, определяющk= 7;го требования = 82; программам = 80; их финансир = 86;вание;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77; ограничиваn= 2;тся заказчиком допустимой стоимостью, трудоемкосm= 0;ью и сроками их создания, требованиn= 3;ми заданного качества и документирl= 6;вания;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77; подлежат независимоl= 4;у тестированl= 0;ю, гарантировk= 2;нию качества и/или сертиф= 080;кации. <o:p></o:p> Для таких, а также для многих друг = 80;х видов относительl= 5;о не сложных п= 088;ограмм, нет необходимоl= 9;ти в регламентиl= 8;овании их жизненно = 75;о цикла, в длительном применении и сопровождk= 7;нии множества в = 77;рсий, в формализацl= 0;и и применени = 80; профилей ст = 72;ндартов и сертификацl= 0;и качества программ. Их разработчиl= 2;и не знают и не применяют регламентиl= 8;ующих, нормативнm= 9;х документов, вследствие чего жизненный цикл таких изде = 83;ий имеет не предсказуеl= 4;ый характер по структуре, содержанию, качеству и стоимости основных процессов “творчествk= 2;”. <o:p></o:p></spa= n> </spa= n>Вm= 0;орой класс составляют крупномасшm= 0;абные комплексы п = 88;ограмм для сложных систем управления = 80; обработки информации, оформляемыk= 7; в виде програl= 4;мных продуктов = 89; гарантировk= 2;нным качеством, и отличаются следующими особенностn= 3;ми и свойствам = 80; их жизненного цикла:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>б = 86;льшая размерностn= 0;, высокая трудоемкосm= 0;ь и стоимость = 089;оздания таких компл = 77;ксов программ определяют необходимоl= 9;ть тщательноk= 5;о анализа экономичесl= 2;ой эффективноl= 9;ти всего их жизненного цикла и возм= 086;жной конкурентоl= 9;пособности на рынке;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 90; заказчика, финансируюm= 7;его проект прог = 88;аммного средства и/или базы да&#= 1085;ных, разработчиl= 2;ам необходимо получать квалифицирl= 6;ванные конкретные требования = 82; функциям и характерисm= 0;икам проекта и пр= 086;дукта, соответствm= 1;ющие выделенномm= 1; финансировk= 2;нию и квалификацl= 0;и исполнителk= 7;й проекта; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>д = 83;я организациl= 0; и координациl= 0; деятельносm= 0;и специалистl= 6;в-разра-ботчиков при наличии единой, крупной целевой задачи, созд= 072;ния и совершенстk= 4;ования программноk= 5;о продукта, необходимы квалифицирl= 6;ванные менеджеры проектов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>в проектах таких сложных программныm= 3; средств и ба= 079; данных= с множеством различных, функционалn= 0;ных компонентоk= 4;, участвуют с = 87;ециалисты разной квалификацl= 0;и и специализаm= 4;ии, от которых требуется высокая ответственl= 5;ость за качество результатоk= 4; деяте= ;льности каждого из них; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 90; разработчиl= 2;ов проектов требуются гарантии высокого ка = 95;ества, надежности функционирl= 6;вания и безопасносm= 0;и применения компонентоk= 4; и поставляе = 84;ых программныm= 3; продуктов, в<sp= an style=3D'mso-spacerun:yes'> которые не допустимо прямое вмешательсm= 0;во заказчика и пользоватеl= 3;ей для изменений, н= 077; предусмотрk= 7;нных эксплуатацl= 0;онной документацl= 0;ей разработчиl= 2;ов;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77;обходимо применять индустриаl= 3;ьные, регламентиl= 8;ованные стандартаl= 4;и процессы, этапы и документы, а также метод = 99;, методики и комплексы средства автоматизаm= 4;ии, технологии обеспечениn= 3; жизненного цикла компл = 77;ксов программ. <o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Такие крупномасшm= 0;абные комплексы программ являютl= 9;я компонентаl= 4;и систем, реализующиl= 4;и обычно их основные, функционалn= 0;ные свойства, у= 074;еличивающи&= #1084;и сложность и создающими предпосылкl= 0; для последу= 02;щих изменений и = 93; жизненного цикла. Реализациn= 3; ЖЦ, методоло= 075;ии управления = 80; изменения П = 57; зависит от многих факторов, от персонала, техническиm= 3;, организациl= 6;нных и договорны = 93; требований = 80; сложности проекта. Множество текущих состояний и модификациl= 1; компоненm= 0;ов сложных ПС менеджерам необходимо упорядочивk= 2;ть, контролироk= 4;ать их развитие = 080; применение участникам= и проекта. Орг= 072;низованное, контролируk= 7;мое и методично = 77; отслеживан= ие динамики изменений в жизненном ц = 80;кле программ и д= 072;нных, их слаженна= 03; разработка при строгом = 091;чете и контроле каждого изменения, является основой эффективноk= 5;о, поступателn= 0;ного развития ка = 78;дой крупной системы методами программноl= 1; инженерии. <o:p= ></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Существуеm= 0; мl= 5;ожество моделей процессов жизненного = 94;икла систем и про= 075;раммных средств, но три из них в международl= 5;ых стандартах</spa= n> обычно квал = 80;фицируются как фундаментаl= 3;ьные: каскадна= ;я; инкрементнk= 2;я; эволюционнk= 2;я. Каждая из указанных м = 86;делей может быть и= 089;пользована самостоятеl= 3;ьно или скомбин = 80;рована с другими дл= 103; создания гибридной модели жизненного цикла конкретногl= 6; проекта. При этом конкре = 90;ную модель жизненного цикла системы или ПС следует выбирать та = 82;, чтобы процессы и задачи были связаны между собой, и определен = 99; их взаимосвязl= 0; с предшествуn= 2;щими процессами, видами деят = 77;льности и задачами. <o:p></o:= p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Каскадная модель жизненного цикла наиб = 86;лее известна и п= 088;именяется достаточно широко. Она по существу реализует принцип одн = 86;кратного выполнения каждого из базовых процес= сов и этапов в их естественнm= 9;х границах. На рис. 1.1 представлеl= 5; пример этапов каскадной м = 86;дели ЖЦ ПС, которая в последующиm= 3; лекциях используетl= 9;я как ориенти = 88; при изложении процессов п = 88;ограммной инженерии. При этом в лекциях акцентируеm= 0;ся внимание на методах обеспечениn= 3; качества программныm= 3; продуктов и = 085;е отражено программирl= 6;вание модулей и ко= 084;понентов, которое остается за границами программноl= 1; инженерии. Связь между этапами показана то = 83;ько сверху вниз, тогда как в реальных пр = 86;цессах жизненного цикла следует учи = 90;ывать возможностn= 0; возврата на предшествуn= 2;щие этапы, снизу ввер = 93; для их уточн= 077;ния и корректироk= 4;ки результатоk= 4;.<o:p></o:p> При применении этой модели = 076;ля создания каждого программноk= 5;о компонента, соответствm= 1;ющие работы и зад= 072;чи п= ;роцесса жизненного цикла обычно выполняют последоватk= 7;льно. Однако они могут быть ч= 072;стично выполнены параллельнl= 6; в случаях пе= 088;екрытия последоватk= 7;льных работ. Когда несколько компонентоk= 4; разрабатывk= 2;ют одновременl= 5;о, для них работы и задачи процесса разработки могут быть выполнены параллельнl= 6;. Процессы заказа и поставки, а также вспомогатеl= 3;ьные и организац = 80;онные процессы выполняютсn= 3; параллельнl= 6; с процессам = 80; разработки. Процессы сопровождеl= 5;ия и эксплуатацl= 0;и обычно реализуютсn= 3; после проце = 89;са разработки. <o:= p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Модель процессов жизненного цикла системы и степень её практическl= 6;го применения = 74; качестве обязательнl= 6;го или рекомендуеl= 4;ого документа зависит от роли конкре = 90;ного программноk= 5;о продукта в системе. Должна быт= 00; определена соответствm= 1;ющая модель жизн = 77;нного цикла систе = 84;ы, в которой программныl= 1; продукт становится её частью. Установленl= 0;е этого поможеm= 0; определить</spa= n>, можно ли использоваm= 0;ь конкретную = 84;одель для разработки, эксплуатацl= 0;и или сопрово = 78;дения программноk= 5;о средства. Программныk= 7; средства могут быть постоянно (резидентно) размещены в компьютераm= 3;, встроены ка = 82; часть прогр = 72;ммно-аппара&= #1090;ных средств или = 080;нтегрирова&= #1085;ы в объект техническиm= 3; средств. В лю&#= 1073;ом случае зака = 79;, поставку, разработку, эксплуатацl= 0;ю или сопровождеl= 5;ие программныm= 3; средств необходимо координироk= 4;ать и гармонизи = 88;овать с аналогичн = 99;ми процессами для всей исходной системы.<o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> Для проект = 72; системы должен быть проведен выбор одной или нескольких = 89;оответству&#= 1102;щих моделей жизненного цикла. Необх= 086;димо установить, = 103;вляется ли модель жизненного цикла прогр = 72;ммного средства сl= 6;ставной частью модели жизненного цикла систе = 84;ы либо полной моделью жизненного цикла ПС. Каждая модель жизн = 77;нного цикла содер = 78;ит некоторые процессы, которые могут быть выполнены последоватk= 7;льно, повторно ил = 80; комбинировk= 2;нно. Процессы должны быть отображены = 74; выбранной модели жизн = 77;нного цикла, с точки зрени= 03; создания модифицируk= 7;мого, развивающеk= 5;ося, структурирl= 6;ванного и планируем = 86;го продукта, ре= 079;ультаты одного процесса из модели жизн = 77;нного цикла должн = 99; быть переда = 85;ы следующему. = 042; этом случае соответствm= 1;ющие документы должны быть созданы к ок= 086;нчанию определеннl= 6;го процесса, до начала след = 91;ющей работы.<o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> = Должны быт= 00; оl= 7;ределены стороны (специалист = 99;, предприятиn= 3;), участвующиk= 7; в проекте системы, и их <= span style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>оm= 0;ветственно= 089;ть за конкретн = 99;е процессы и р= 077;зультаты в ЖЦ. Следуе&#= 1090; учесть все работы и задачи, связ= 072;нные с взаимодейсm= 0;виями (интерфейса = 84;и) между этими сторонами. Для большог = 86; проекта, в ко&#= 1090;орый вовлечено много лиц, необходим р = 72;звитой администраm= 0;ивный надзор и контроль, проведение внутренних = 80; независимыm= 3; оценок, анализов, аудиторскиm= 3; проверок, инспекций и подготовка отчетов, являющихся главным инструментk= 2;рием для большог = 86; проекта. <o:p></o:p> Современнm= 9;е предприятиn= 3; шl= 0;роко используют модели проц = 77;ссов жизненного цикла в качестве составной части деятельносm= 0;и по определе = 85;ию и усовершен = 89;твованию процессов, связанных с = 087;рограммным&= #1080; средствами. <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>Пl= 8;именение стандартов жизненного цикла позволяет ориентировk= 2;ться специалистk= 2;м на построен = 80;е систем и комплексов программ из крупных функционалn= 0;ных узлов, отвеч= 072;ющих требованияl= 4; стандартов, применять отработаннm= 9;е и проверенныk= 7; проектные решения. Они определяют унифицировk= 2;нные интерфейсы взаимодейсm= 0;вия компонентоk= 4; таким образом, что разработчиl= 2;у системы, как правило, не требуется в = 76;аваться в детали внутреннегl= 6; устройства = 01;тих компонентоk= 4;. Стандарты, относящиесn= 3; к программныl= 4; комплексам (функционал= 00;ным частям) систем, обле= 075;чают повторное использоваl= 5;ие в новых сист= 077;мах готовых и апробироваl= 5;ных программныm= 3; продуктов. Для унифика= ;ции и регламентиl= 8;ования процессов Ж = 62; ПС такие совокупносm= 0;и - профили стандартов должны адап = 90;ироваться и конкретиз= ;ироваться применителn= 0;но к определен = 85;ым классам проектов, процессов и компонентоk= 4; ПС. Таким образом, разработка программноk= 5;о продукта, в знаm= 5;ительной степени, может сводиться к интеграции = 80; комплексирl= 6;ванию из стандарт = 80;зированных компонентоk= 4;. <o:p></o:p> Методы l= 0; процессы стандартизk= 2;ции жизненного цикла ПС играют стабил= изирующую и организующm= 1;ю роль во все= 084; жизненном цикле многи = 93; сложных сис = 90;ем. Они оk= 3;еспечивают:<o= :p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 72;сширение и совершенстk= 4;ование функций сис = 90;ем и компонентl= 6;в с сохранени = 77;м их целостностl= 0; и первичных = 079;атрат;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 80;стематичес&#= 1082;ое повышение качества фу = 85;кционирова&#= 1085;ия комплексов программ и баз данных для решения = 079;адач пользоватеl= 3;ей в различной внешней среде;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 83;учшение технико-эко = 85;омических характерисm= 0;ик применения систем и про= 075;раммных продуктов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;вершенство&#= 1074;ание технологий обеспечениn= 3; жизненного цикла сложн = 99;х систем и комплексов программ.<o:p></o:p>= Для этого при создании и сопровождеl= 5;ии сложных, рас= 087;ределенных<= span style=3D'mso-spacerun:yes'> систем, форми= ;ровании их архитектурm= 9;, при выборе стандартов для програм = 84;ных компонентоk= 4; и их связей, целесообраk= 9;но учитывать рn= 3;д совре= ;менных концептуаl= 3;ьных требований программноl= 1; инженерии и формированl= 0;я их жизненного цикла:<o:p></o:p><= /span> <![if !supportList= s]>-&nb= sp; = <![endif]>арх= итектура комплекса п = 88;ограмм должна соответстk= 4;овать текущим и персп= ;ективным целям и стратегичеl= 9;ким, функционалn= 0;ным задачам, создаваемоl= 1; системы, быть достаточнl= 6; гибкой и допускать относительl= 5;о простое, без коренных структурныm= 3; изменений, развитие и наращиваниk= 7; функций и ре= 089;урсов системы в соответствl= 0;и с расширени = 77;м сфер и задач её применен = 80;я;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>в структуре и компонентаm= 3; ПС и системы следует предусматрl= 0;вать обеспечениk= 7; максимальнl= 6; возможной сохранностl= 0; инвестиций = 74; аппаратные и программныk= 7; средства, а также в базы данных при длительном развитии, сопровождk= 7;нии и модернизацl= 0;и системы;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>нео= бходимо обеспечиваm= 0;ь эффективнl= 6;е использовk= 2;ние ресур= ;сов в ЖЦ системы и минимизироk= 4;ать интегральнm= 9;е затра= ;ты на обработк = 91; данных= в типовых режимах её ф= 091;нкциониров&= #1072;ния с учетом эксплуатацl= 0;онных затрат и капитальныm= 3; вложений в создание системы и пр= 086;граммного продукта;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>дол= жны быть обеспечены безопасносm= 0;ь функционирl= 6;вания системы и надежная защита данных от ошибок, от разрушения или потери информации, а также авторизациn= 3; пользоватеl= 3;ей, управление рабочей заг = 88;узкой, резервировk= 2;нием и оперативныl= 4; восстановлk= 7;нием функционирl= 6;вания системы и программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>для обеспечениn= 3; перспективm= 9; развития жи = 79;ненного цикла систе = 84;ы и комплекса программ целесообраk= 9;но предусматрl= 0;вать возможностn= 0; интеграции гетерогеннm= 9;х вычислителn= 0;ных компонентоk= 4; и возможностn= 0; переноса ПС = 080; БД на различные аппаратные = 80; операционнm= 9;е платформы н = 72; основе концепции и стандартоk= 4; открытых си = 89;тем;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>сле= дует обеспечить комфортное обучение и максимальнl= 6; упрощенный доступ= конечных п = 86;льзователе&#= 1081; к управлени= 02; и результат = 72;м функционирl= 6;вания системы и п= 088;ограммного продукта на основе совр = 77;менных графическиm= 3; средств и наглядных п = 86;льзователь&#= 1089;ких интерфейсоk= 4;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Наиболее актуальна стандарти = 79;ация процессов жизненного цикла комплексов программ пр = 80; коллективнl= 6;й разработке = 80; сопровождеl= 5;ии крупных критическ = 80;х систем управления = 74; реальном времени, к<s= pan style=3D'mso-spacerun:yes'> котор= ;ым предъявляn= 2;тся высокие тр = 77;бования к качеству. В этих случая = 93; особенно необходимо = 95;еткое планированl= 0;е и управлени = 77; технологичk= 7;скими процессами их жизненного цикла. Созданы или разрабатывk= 2;ются комплексы м = 77;ждународны&#= 1093; стандартов, в той или иной степени регламентиl= 8;ующие проце= ;ссы проектироk= 4;ания, разработки, эксплуатацl= 0;и и сопровожд = 77;ния в ЖЦ програм= 084; и баз данных. Они обычно ориентировk= 2;ны на ПС, выполн&#= 1103;ющие важные функции в системах управ= ;ления объектами, технологиm= 5;ескими процессами или при обработке ответственl= 5;ой информации. При&= #1084;енение таких стандартов полностью при создани = 80; и использовk= 2;нии простых про = 75;рамм, узкого или эксперименm= 0;ального назначения (первого кла= 089;са см. выше) не всегда може = 90; быть оправдано. О= 076;нако они определяют </sp= an>современн = 91;ю культуру программноl= 1; инженерии и стандартизk= 2;ции жизненного цикла комплексов программ высокого ка = 95;ества. <o:p></o:p> <o:p> </o:p> <h1> = <a name=3D"_Toc508102447"></a><a name=3D"_Toc508102220">1.2. Роль системотехl= 5;ики в программноl= 1; инженерии</a><= /h1> <o:p> </o:p> С&= #1080;стема <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > это совокупносm= 0;ь взаимодейсm= 0;вующих компонентоk= 4;, работающих совместно для достижения определеннm= 9;х целей. Определяющ= 080;м признаком системы является то, что свойств = 72; и поведение системных компонентоk= 4; влияют друг на друг= 072; сложным обр = 72;зом. Корректное функционирl= 6;вание каждого системного компонента зависит от функционирl= 6;вания многих других компонентоk= 4;. Системы час = 90;о имеют иерархичесl= 2;ую структуру, т.е. в качеств&= #1077; компонентоk= 4; содержат другие системы (подсистем = 99;). Определяюm= 7;ее свойство подсистем з = 72;ключается в том, что они могут функционирl= 6;вать самостоятеl= 3;ьно, независимо от тех систе= 084;, в состав которых входят. Вместе с тем их поведени = 77; в составе ко= 085;кретной системы зависит от взаимодейсm= 0;вия с другими подсистемаl= 4;и.<o:p></o:p> &n= bsp; Сложность взаимодейсm= 0;вия между систе = 84;ными компонентаl= 4;и означает, чт= 086; система не сводится просто к сумме её составных ч = 72;стей. Она имеет определеннm= 9;е свойства, ко= 090;орые присущи ей именно как ц= 077;лостной системе. Такие интеграцио&= #1085;ные свойства н = 77; могут быть свойствами отдельной части системы. Они проявляютсn= 3; тогда, когда система рас = 89;матриваетс&#= 1103; как единое целое. Некоторые и = 79; этих свойст = 74; можно вывести из аналогичныm= 3; свойств отдельных подсистем, н= 086; чаще они являются ко = 84;плексным результатоl= 4; взаимодейсm= 0;вия подсистем и их невозможно оценить, исходя из анализа отдельных системных компонентоk= 4;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Системотеm= 3;ника <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Courier New";mso-hansi-font-family:"Courier New";color:windowtext;mso-char= -type: symbol;mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > </s= pan>как технология создания систем охватывает все аспекты = 089;оздания и модернизацl= 0;и сложных вычислителn= 0;ных комплексов, где програм = 84;ные продукты играют ведущую рол= 00;. Сюда можно отнести технологию = 88;азработки аппаратных средств, внутренних вычислителn= 0;ных процессов и связей всей системы, а также техно = 83;огию создания ПС. Инженеры системотехl= 5;ики на основе спецификацl= 0;и требований = 89;истемы определяют её архитектурm= 1; и затем, собр&#= 1072;в воедино её отдельные части, созда= 102;т законченнуn= 2; систему.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;color:windowtext'> Пl= 6; мере увеличения = 74; системах роли програ = 84;мных компонентоk= 4; методы прог = 88;аммной инженерии все шире исполь = 79;уются в процессе с= 086;здания разнообразl= 5;ых систем. Системотехl= 5;ика, как техноло = 75;ия создания систем, охватывает процессы со = 79;дания спецификацl= 0;й, проектировk= 2;ния, разработки, тестированl= 0;я, внедрения и сопровождеl= 5;ия систем как единог= 086; целого. = 057;истемотехн&= #1080;к, занимающиl= 1;ся разработкоl= 1; вычислителn= 0;ных систем, не может быть сосредоточk= 7;н только на программноl= 4; комплексе, о= 085; должен удел= 03;ть равное внимание программноl= 4;у средству, аппаратным средствам и средствам взаимодейl= 9;твия с пользоватеl= 3;ями и системным окружением. Специалист по созданию программноk= 5;о продукта должен пони = 84;ать задачи и методы системотехl= 5;ики, поскольку возникающиk= 7; проблемы ча = 89;то являются результатоl= 4; решений, при= 085;ятых системоm= 0;ехниками.<o:p></o:= p> Прог= раммный менеджер и/или системный инженер должен быть знаком с несколькимl= 0; способами проектировk= 2;ния, знать, как пе&#= 1088;евести расплывчатm= 9;е требования = 80; пожелания заказчика в четкое техническоk= 7; задание, и уметь разговаривk= 2;ть с пользоват = 77;лем системы на языке предм = 77;тной области, а не на професси = 86;нальном программисm= 0;ском жаргоне. Такие способностl= 0; требуют, в свою очеред= 00;, гибкости и открытости, = 095;тобы ухватить су = 97;ность предметной области раз = 83;ичных приложений = 80; стать в ней специалистl= 6;м. Программныl= 1; инженер должен обладать возможностn= 0;ю переходить от одного уровня абстракции = 82; другому на р= 072;зных стадиях про = 77;кта: от особых процедур и требований приложения = 82; абстракцияl= 4; программноl= 1; системы, к специфике дизайна системы и, наконец, к уровню дета = 83;ьного кодированиn= 3; программ. <o:p></o:p> Неформальl= 5;ый подход, применяющиl= 1;ся к построени= 02; некоторых программ, не= 076;остаточен для разработки больших систем. Стоимость аппаратных средств постепенно снижается, тогда, как стоимо = 89;ть программныm= 3; продуктов стремительl= 5;о возрастает. Возникла необходимоl= 9;ть в новых технологияm= 3; и методах управления комплексныl= 4;и проектами разработки больших программныm= 3; систем. Таки= 077; методы составили программнуn= 2; инженерию. Возрастает как объем пр= 086;изводства программноk= 5;о продукта, та= 082; и его сложно= 089;ть. Кроме того, сближение вычислителn= 0;ной и коммуника = 94;ионной техники ставит новы = 77; требования перед специалистk= 2;ми. Это также является одной из причин возн = 80;кновения проблем при разработке программныm= 3; систем, как и то, что многие= компании, занимающиеl= 9;я производстk= 4;ом ПС, не уделяют должного внимания эф = 92;ективному применению = 89;овременных методов и стандартов, разработанl= 5;ых в программноl= 1; инжен= ;ерии. <o:p></o:p> Программнk= 2;я инженерия -</span= > как часть системотехl= 5;ики охватывает все аспекты жизненного цикла ПС от начальной стадии разр = 72;ботки системных требований до завершения использоваl= 5;ия программноk= 5;о продукта. Пр= 080; этом специалистm= 9; выполняют практическm= 1;ю, инженерную работу. Они применяют теоретичесl= 2;ие построения, методы и средства та = 84;, где это необ= 093;одимо, но делают эт= 086; выборочно и всегда пытаются найти практическl= 6;е решение задачи, даже если не суще= 089;твует подходящей теории или м= 077;тодов решения. Инж= 077;неры всегда должны понимать, чт= 086; они работаю = 90; в организац = 80;онных и финансовы = 93; рамках заключенныm= 3; контрактов, = 080; ищут решени = 77; поставленнl= 6;й перед ними задачи с учетом условий контракта. П= 088;ограммная инженерия не рассматривk= 2;ет техн = 80;ческие аспекты де = 90;ального создания компонентоk= 4; = - в её ведение входят таки = 77; задачи, как управление проектами П = 57; и разработк = 72; средств, мет= 086;дов и теорий, необходимыm= 3; для обеспечениn= 3; жизненного цикла комплексов программ. Программирl= 6;вание компонентоk= 4; = - это дел = 86;, главным образом, индивидуалn= 0;ное, а программн = 72;я инженерия систем -</span= > всегда коллективнk= 2;я работа.<o:p></o:p> Программнm= 9;е средства вс = 77; больше встраиваютl= 9;я в различные системы. Раб= 086;та с такими проектами требует от программноk= 5;о инженера широкого взгляда на общие задач = 80; проектировk= 2;ния систем. Программноl= 4;у инженеру необходимо участвоватn= 0; в выработке требований для всей сис= 090;емы, а также пыта= 090;ься понять прикладную область ПС еще до начал= 072; обдумываниn= 3; абстрактныm= 3; интерфейсоk= 4;, требованияl= 4; которых должен буде = 90; отвечать программныl= 1; продукт. Рас= 089;матривая программнуn= 2; инженерию как часть системотехl= 5;ики, обнаруживаk= 7;тся важность компромиссk= 2; как отличит = 77;льного признака лю = 73;ой инженерной дисциплины. Существуют принципиалn= 0;ные трудности изменения масштаба пр = 80; попытке привнести приемы написания малых программ в проектировk= 2;ние больших про = 75;раммных комплексов. <o:= p></o:p> = Разработчl= 0;ки проекта сис = 90;емы вынуждены тратить время на общение дру = 75; с другом, вместо того, чтобы писат= 00; программы. Иногда люди покидают проект, и это влияет не только на работу выполняемуn= 2; непосредстk= 4;енно ими, но и на работу тех, кто от них зависит. Замена разработчиl= 2;а в проекте может требо = 74;ать обучения и серьезнейшk= 7;й подготовки = 85;ового специалистk= 2; для освоени= 03; им техничес = 82;их условий проекта и текущего со = 89;тояния системы. Любое изменение первоначалn= 0;ных требований = 82; системе влияет на мн= 086;гие составные части проекта, выливаясь в дальнейшем = 74; задержку по = 89;тавки готового пр = 86;дукта. Как в любой инженерной отрасли, программныl= 1; инженер должен развивать умения, позв= 086;ляющие построить набор моделей и оценить эти модели, управляя выбором ком = 87;ромиссов. Такие модел = 80; используютl= 9;я на этапе определениn= 3; требований = 82; проектируеl= 4;ой системе, в разработке архитектурm= 9; программно&#= 1075;о средства и н= 072; стадии реализации проекта. Программныl= 1; инженер = - это чле = 85; команды, поэтому должен обладать навыками общения и межличностl= 5;ых отношений, а также уметь планироватn= 0; не только свою работу, &#= 1085;о и координир = 86;вать её с работой других. <o:p></o:p> Специалисm= 0; по программноl= 1; инженерии должен знат= 00; системотехl= 5;ику вычислителn= 0;ных систем, поскольку здесь программныl= 1; компонент играет опре = 76;еляющую роль. Таким образом, технологии программнl= 6;й инженерии часто являются критическиl= 4; фактором пр = 80; разработке сложных вычислителn= 0;ных систем. Интеграциоl= 5;ные свойства систем проя = 74;ляются только тогд = 72;, когда система рас = 89;матриваетс&#= 1103; как единое целое. В этом состоит сложность прогнозироk= 4;ания и оценки её с&#= 1074;ойств, поскольку иногда можн = 86; измерить характерисm= 0;ики только подс = 80;стем, из которых с= 086;стоит комплекснаn= 3; система. Вm= 9;сокие темпы роста основных ресурсов аппар= ;атных средств (приблизит = 77;льно на порядок каждые пять лет), и сохран&= #1103;ющаяся потребностn= 0; в увеличени = 80; их использо = 74;ания со стороны р= 072;зличных пользоватеl= 3;ей и сфер применения, приводят к необходимоl= 9;ти адекватногl= 6; совершенстk= 4;ования технологий создания пр = 86;граммных средств и ба= 079; данных. <o:p></o:p> <s= pan style=3D'mso-bidi-font-size:14.0pt'><o:p> </o:p> <h1><a name=3D"_Toc508102448"></a><a name=3D"_Toc508102221">1.3. Системные основы современныm= 3; технологий = &nb= sp; программнl= 6;й инженерии</a> = </h1> <o:p> </o:p> = Основная цель современныm= 3; технологий</spa= n> программноl= 1; инженерии состоит в обеспечениl= 0; эффективноl= 9;ти всего жизненного цикла компл = 77;ксов программ дл= 03; ЭВМ в различных проблемно-о = 88;иентирован&#= 1085;ых областях. В понятие современноl= 1; технологии = 74;ключается совокупносm= 0;ь методов и инструментk= 2;льных средств автоматизаm= 4;ии, а также технологичk= 7;ские процессы, обеспечиваn= 2;щие жизненный цикл сложны = 93; ПС с заданны= 084;и функционалn= 0;ными и конструктиk= 4;ными характерисm= 0;иками качества. Для этогl= 6; рекомендуеm= 0;ся использоваm= 0;ь наиболее эффективныk= 7; и совершенныk= 7; методы прое = 82;тирования и проводить комплекснуn= 2; автоматизаm= 4;ию ЖЦ ПС (см. рис. 1.1).= Целеустре = 84;ленная деятельносm= 0;ь разработчиl= 2;ов-поставщи&#= 1082;ов должна быт= 00; направлена на удовлетворk= 7;ние требований = 79;аказчиков и пользоват = 77;лей программныm= 3; продуктов при их применении по прямому н= 072;значению. <o:p></o:p> = Эта деятельносm= 0;ь регламентиl= 8;уется рядом методов и стандартов, которые явл= 03;ются компонентаl= 4;и технологичk= 7;ского обеспечениn= 3; сложных ПС в течение их жизненного цикла. Их применение предполагаk= 7;т высокую дисциплину коллектива специалистl= 6;в, использоваl= 5;ие им методик, стандартов, типовых нор = 84;ативных документов = 80; средств автоматизаm= 4;ии разработки, которые регламент= ;ируют порядок организациl= 0; и проведени= 03; работ по выполнению технологичk= 7;ских операций, направленнm= 9;х на получени = 77;, в имеющихся = 086;рганизацио&= #1085;но-техничеl= 9;ких условиях, готового программноk= 5;о продукта с заданными функциями и качеством.<o:p></o:p>= Методиче= ской основой технологии, регламентиl= 8;ующей деятельносm= 0;ь специалистl= 6;в, является типовой тех = 85;ологически&#= 1081; процесс. Он отражается набором этапов и операций в п= 086;следовател&= #1100;ности их выполнения = 80; взаимосвязl= 0;, обеспечиваn= 2;щих ведения работ на все= 093; стадиях от инициироваl= 5;ия проекта и подготовки техническоk= 5;о задания до завершения = 80;спытаний или применения версии ПС. <s= pan style=3D'font-size:14.0pt'>В современныm= 3; технологияm= 3; объединяютl= 9;я методы непо = 89;редственно&#= 1081; разработки программ и данных с методами обеспечениn= 3; качества и о= 088;ганизации управления их создание = 84; с учетом технологичk= 7;ских и человеческl= 0;х факторов. <o:p></o:p></span= > Индустр= ;иализация технологий программноl= 1; инженерии базир= ;уется на стандартизk= 2;ции процессов разработки программ, их структурноk= 5;о построения = 80; интерфейсоk= 4; с операцион = 85;ой и внешней средой. Для этого с само= 075;о начала разработки должны определятьl= 9;я состав и этапы работ, необходимыk= 7; для достижения конечной цели, а также требуемые для их выпол= 085;ения ресурсы. Техническиk= 7; и управленч = 77;ские проверки, анализ каче = 89;тва результатоk= 4; промежуточl= 5;ых работ и компонентоk= 4;, а также корректносm= 0;и их взаимосвязk= 7;й должны обеспечиваm= 0;ь руководитеl= 3;ям и всем разра= 073;отчикам уверенностn= 0; достижения требуемого конечного результата проекта.<o:p></o:p> Дос&#= 1090;ижение высоких значений качества ко = 84;плексов программ существеннl= 6; зависит от качества технологии = 80; инструментk= 2;льных средств, используемm= 9;х разработчиl= 2;ами для обеспечениn= 3; ЖЦ ПС. Уровень автоматизаm= 4;ии, качество технологии = 80; средств, при= 084;еняемых для поддержки процессов жизненного цикла ПС, обычно сильно коррелировk= 2;н с качеством создаваемm= 9;х комплексов программ, а также с качеством средств авт = 86;матизации для их оценивания. Оценивание = 76;остоинств технологичk= 7;ской базы ЖЦ позволяет прогнозироk= 4;ать возможное качество ПС и ориk= 7;нтировать заказчика и пользоватеl= 3;ей при выборе разработчиl= 2;а и поставщика для оl= 7;ределенног= 086; проекта с требуемыми характерисm= 0;иками. Поэтому определениk= 7; уровня техн = 86;логической поддержки п = 88;оцессов жизненного цикла, организациl= 6;нного и инструмен = 90;ального обеспеченl= 0;я ПС, непосред= 089;твенно связано с оц= 077;ниванием реальных ил = 80; возможных характерисm= 0;ик качества ко = 85;кретного комплекса п = 88;ограмм.<o:p></o:p></sp= an> Значител= ;ьные достижения = 74; развитии и применении современныm= 3; методов и технологии обеспечениn= 3; крупномасшm= 0;абных проектов ПС = 089;осредоточе&= #1085;ы в методолог = 80;и СММ (Capab= ility Maturity <= span class=3DIieoeiue>Model – система и модель для оценки зрелости) ко= 084;плекса технологичk= 7;ских процессов ж = 80;зненного цикла ПС, а также в её последующеl= 4; развитии в </s= pan>CMMI:2003 (см. лекцию 3). Она основана на формализацl= 0;и и использов = 72;нии пяти уровне = 81; зрелости технологий поддержки Ж = 62; ПС, которые также определяют = 87;отенциальн&#= 1086; возможное к = 72;чество создаваемыm= 3; на предприятиl= 0; комплексов программ. Че= 084; выше уровен= 00; зрелости, те= 084; выше статус предприятиn= 3; среди поставщикоk= 4;, доверие к ег= 086; продукции, е= 075;о конкурентоl= 9;пособность, а также возможное качество программныm= 3; продуктов. Тем самым пр= 080; выборе значений характерисm= 0;ик качества ПС можно в соответствm= 1;ющей степени доверять по = 89;тавщику и предприят = 80;ю разработчиl= 2;а, что они смогут полностью р = 77;ализовать требования заказчика. Эти уровни зрелости характеризm= 1;ются степенью формализацl= 0;и, адекватносm= 0;ью измерения и документирl= 6;вания процессов и продуктов в ЖЦ ПС, полнот&#= 1086;й применения стандартов = 80; инструментk= 2;льных средств автоматизаm= 4;ии работ, наличием и г= 083;убиной реализации функций системой качества технологичk= 7;ских процессов и их результа = 90;ов. <o:p></o:p> Методоло= ;гия обеспечениn= 3; качества ПС = 074; программноl= 1; инженерии поддержана = 88;ядом методическl= 0;х документов = 80; инструментk= 2;льных средств, а также форма = 83;изована комплексом международl= 5;ых стандартов (см. Приложен&#= 1080;е 1). Внедрение комплекса требует больших усилий и затрат, что ограничило его массово = 77; использоваl= 5;ие для относит = 77;льно простых и ср= 077;дней сложности проектов. <sp= an style=3D'font-size:14.0pt'> Конце= птуальные и организац = 80;онные основы адми = 85;истративно&#= 1075;о управления жизненным циклом и качеством П = 57; в системе СММ, а также CMMI:2003,= определ= ;ены в восьми базовых принципах, к= 086;торые декларировk= 2;ны в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9000:2000 и ISO 15504:1-9. <o:p></o:p></= span> Принцип 1 = - Ориентация = 87;редприятия-&= #1088;азработчик= ;а на потребит = 77;ля-заказчик&= #1072; . “Предприятl= 0;я зависят от своих потребителk= 7;й и, таким образом, дол= 078;ны понимать текущие и будущие потребностl= 0; потребителk= 7;й-заказчико&#= 1074;, удовлетворn= 3;ть их требован = 80;я и стремитьс= 03; превзойти и = 93; ожидания”. <o:p></o:p= > При&#= 1085;цип 2 - Лидерство-р = 91;ководство. “Лидеры обеспечиваn= 2;т единство назначения = 80; направлениn= 3; деятельносm= 0;и предприятиn= 3;. Они должны создавать и поддерживаm= 0;ь внутреннюю = 86;кружающую среду, в которой специалистm= 9; могут в полной мере участвоватn= 0; в достижени = 80; стратегичеl= 9;ких целей предп = 88;иятия”.<o:p></o:p> = Принцип 3 = - Вовлечение персонала. “Люди составляют = 89;ущность предприятиn= 3; на всех уровнях, и их полноценноk= 7; участие в деятельносm= 0;и способствуk= 7;т применению их способностk= 7;й на благо цел= 077;й предприятиn= 3;”.<o:p></o:p> = Принцип 4 = - Процессный подход. “Желаемый результат д = 86;стигается более эффек = 90;ивно, когда требуемые ресурсы и деятельносm= 0;ь специалистl= 6;в предприятиn= 3; управляютсn= 3; как единый связанный п = 88;оцесс”.<o:p></o:p> П= 088;инцип 5 - Системный подход к администраm= 0;ивному управлению. “Выявление = 80; понимание задач и администраm= 0;ивное управление системой вз = 72;имосвязанн&#= 1099;х процессов для заданно = 81; стратегичеl= 9;кой цели, повыша= 077;т эффективноl= 9;ть и результатиk= 4;ность предприятиn= 3;”.<o:p></o:p> П= 088;инцип 6 - Постоянное усовершенсm= 0;вование. “Непрерывнl= 6;е усовершенсm= 0;вование процессов и = 087;овышение качества продукции должно быть постоянной стратегичеl= 9;кой целью предприятиn= 3; и его специа= 083;истов”.<o:p></o:p> = Принцип 7 -</span= > Подх= ;од к принятию решений основанный на фактах. “Эффе= ;ктивные решения должны базироватьl= 9;я на анализе только реальных да = 85;ных и достоверн = 86;й информации̶= 1;.<o:p></o:p> П= 088;инцип 8 - Взаимовыгоk= 6;ные отношения с поставщикаl= 4;и. “Предприятl= 0;е-пользоват&#= 1077;ль и его поставщики- = 88;азработчик&#= 1080; взаимозавиl= 9;имы, и взаимовыг = 86;дные отношения между ними повышают способностn= 0; обоих производитn= 0; качественнm= 1;ю продукцию”.<o:p= ></o:p> В стандарте ISO 15504 каждый из пр= 080;веденных принципов прокомментl= 0;рован комплексом действий, необходимыm= 3; для их реали= 079;ации в проектах. Выполнение этих принци = 87;ов способствуk= 7;т повышению управленчеl= 9;кой культуры, применению системы адмl= 0;нистративн= 086;го управления качеством в = 86; всех видах деятельносm= 0;и предприятиl= 1; и, как следствие, обеспечениn= 2; высокого качества и конкурентоl= 9;пособности создаваемоl= 1; проду= ;кции, проектов и систем. Эти принципы рекомендуеm= 0;ся применять при:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>ф = 86;рмулировке политики и стратегии обеспеченl= 0;я всего ЖЦ ПС;<o:p></o:= p> <![if !supportLists]>- &nb= sp; <![endif]>выборе целей проекта, требований = 80; характерисm= 0;ик качества ПС, непосредстk= 4;енно связанных с потребностn= 3;ми и ожиданиям = 80; заказчиков = 80; потребителk= 7;й;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>управлени= 080; операциями = 74; процессе реализации проекта и дл= 103; удовлетворk= 7;ния требований заказчика и потре= ;бителей;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>управлени= 080; людскими ресурсами предприятиn= 3; для обеспеч = 77;ния ЖЦ ПС и его качества.<o:p></o:p>= Оп= ;исание процессов ЖЦ ПС в СММ сфокус= 080;ровано на поэтапно = 84; определениl= 0; реально достигаемыm= 3; результатоk= 4; и на оценивании качества их выполнения. Качество п = 88;оцессов зависит от технологичk= 7;ской среды, в которой они выполняютсn= 3;. Зрелость процессов = - это степень их управляемоl= 9;ти, возможностn= 0; поэтапной количествеl= 5;ной оценки каче = 89;тва, контр= ;олируемост= 00; и эффективноl= 9;ть результатоk= 4;. Модель зрелости предприятиn= 3; представляk= 7;т собой методическl= 0;й нормативныl= 1; документ, определяющl= 0;й правила соз = 76;ания и функциони = 88;ования системы управления жизненным ц = 80;клом ПС, методы постепенноk= 5;о повышения культуры и качества производстk= 4;а. Рост зрелости обеспечиваk= 7;т потенциальl= 5;ую возможностn= 0; возрастаниn= 3; эффективноl= 9;ти и согласованl= 5;ости использоваl= 5;ия процессов создания, сопровождеl= 5;ия и оценивани= 03; качества ко = 84;понентов и ПС в целом. Реальное и = 89;пользовани&#= 1077; регламентиl= 8;ованных процессов предполагаk= 7;т их документирl= 6;вание и поэтапный контроль характерисm= 0;ик качества ПС. На предприятиn= 3;х, достигших высокого уровня зрелости, формализовk= 2;нные процессы ЖЦ ПС должны принимать статус стандарта, ф= 080;ксироватьс&= #1103; в организациl= 6;нных структурах = 80; определять производстk= 4;енную тактику и ст= 088;атегию корпоративl= 5;ой культуры производстk= 4;а и системы обеспечениn= 3; качества программноk= 5;о продукта. <o:p></o:p></span= > = В современныm= 3; автоматизиl= 8;ованных технологияm= 3; программноl= 1; инженерии, создания и <sp= an class=3DGramE>совершенl= 9;твования сложных ПС, с позиции обеспечениn= 3; их качества можно выделить методы и средства, позволяющиk= 7;:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здавать программныk= 7; модули и функционалn= 0;ные компоненты высокого, га= 088;антированн&= #1086;го качества;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>п = 88;едотвращат&#= 1100; дефекты проектировk= 2;ния за счет систем обес = 87;ечения качества, эффективныm= 3; технологий = 80; инструментk= 2;льных средств автоматизаm= 4;ии всего жизненного цикла компл = 77;ксов программ и баз данных;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>о = 73;наруживать и устранять различные дефекты и ошибки прое = 82;тирования, разработки = 80; сопровождеl= 5;ия программ путем вериф = 80;кации и системати = 95;еского тестированl= 0;я на всех этапах жизненного цикла ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 76;остоверять достигнутыk= 7; значения качества функциониl= 8;ования программныm= 3; продуктов в процессе их = 080;спытаний и сертификацl= 0;и перед передачей в = 088;егулярную эксплуатацl= 0;ю пользоватеl= 3;ям.<o:p></o:p> = Комплекснl= 6;е, скоординирl= 6;ванное применение этих методо = 74; и средстk= 4; в процессе создания, развития и применения ПС позволяе = 90; исключать многие виды дефектов ил = 80; значительнl= 6; ослаблять и = 93; влияние. Тем самым уровень дос = 90;игаемого качества пр = 86;граммных продуктов становится предсказуеl= 4;ым и управляем = 99;м, непосредстk= 4;енно зависящим о = 90; ресурсов, выделяемых на его достижение, = 072; главное, от системы качества и эффективноl= 9;ти технологии, используемm= 9;х на всех этапах жизн = 77;нного цикла ПС. Эти ресурсы требуются н = 72; технологичk= 7;ские средства в Ж= 062; ПС:<o:p></o:p> <![= if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>нпри&= #1086;бретение</span= > или создани = 77; технологии = 80; инструментk= 2;льных средств, при= 084;еняемых для обеспеч = 77;ния требуемого качества всего жизненного цикла ПС;<o:p></o:p></span= > <![= if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>на эксплуатацl= 0;ю и непосредстk= 4;енное применение технологии = 74; процессе обеспечениn= 3; ЖЦ ПС;<o:p></o:p> <![= if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>на создание технологии = 80; инструментk= 2;льных средств для испытаний и оценивания характериl= 9;тик качества программноk= 5;о средства;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>на выполнение измерений достигнутыm= 3; значений характерисm= 0;ик качества ПС.</s= pan><o:p></o:p> Улучшен= ;ие технико-эко = 85;омических показателеl= 1; создания ПС, а также предотвращk= 7;ние ошибок и дефектов обеспечиваk= 7;тся применениеl= 4; современны&#= 1093; технологий программноl= 1; инженерии и систем автоматизиl= 8;ованного проектировk= 2;ния. Они представляn= 2;т собой высокопроиk= 9;водительны= 077;, ресурсосбеl= 8;егающие технологии создания комплексов программ вы = 89;окого качества и надежности, имеют целью = 089;окращение общих затра = 90; на проектир = 86;вание, реализацию, сопровождеl= 5;ие и совершенстk= 4;ование ПС. Для этого, прежде всег = 86;, необходимо применять методы и средства си = 89;темного анализа и проектировk= 2;ния, обеспечиваn= 2;щие конкретизаm= 4;ию и максимальнl= 6; точное представлеl= 5;ие целей, назначения = 80; функций с начала ЖЦ ПС и предотвращk= 2;ющие распростраl= 5;ение возможных системных д = 77;фектов на последую = 97;ие этапы разработки. Такие технологии программноl= 1; инженерии позволяют исключать или значительнl= 6; снижать уровень сис = 90;емных, алгоритмичk= 7;ских и программныm= 3; ошибок в программныm= 3; продуктах, передаваемm= 9;х на эксплуатацl= 0;ю. Кроме того, они эффективны при модификациl= 0; и сопровожд = 77;нии ПС, а также при изменении конфигурацl= 0;и внешней среды. <o:p></o:p> Для обнаружениn= 3;, устранения = 86;шибок и дефектов все этапы ра= 079;работки и сопровожд = 77;ния ПС должны быть поддержаны методами и средствами верификациl= 0;, а также сист= 077;матическог&= #1086;, автоматизиl= 8;ованного тестированl= 0;я корректносm= 0;и реализованl= 5;ых решений. На этапах разработки ПС целесооб = 88;азно применять различные методы, эталоны и виды тестир = 86;вания, каждый из которых ориентировk= 2;н на обнаруже = 85;ие, локализациn= 2; или диагностикm= 1; определеннm= 9;х типов дефектов. Непредсказm= 1;емость конкретных дефектов и ошибок в про= 075;раммах приводит к целесообраk= 9;ности последоватk= 7;льного, методичногl= 6; анализа возможностl= 0; проявления любого типа = 086;шибок и их исключе= 085;ия на наиболее ранних этапах разработки при минимал= 00;ных затратах. Дл= 103; тестированl= 0;я необходимы достаточно полные эталоны, такие как совокупносm= 0;ь требований техническоk= 5;о задания и по= 101;тапная их декомпозицl= 0;я в спецификацl= 0;ях. Существеннk= 2;я особенностn= 0; тестированl= 0;я сложных ПС с= 086;стоит в потребностl= 0; их проверки при огранич = 77;нной длительносm= 0;и испытаний. Для этого це= 083;есообразно тщательное планированl= 0;е тестированl= 0;я с учетом все= 093; результатоk= 4;, полученных на этапах жизненного цикла. При планированl= 0;и основная задача состоит в достижении максимальнl= 6;й достоверноl= 9;ти испытаний и определениn= 3; качества ПС при огранич = 77;нии допустимых затрат ресурсов.<o:p></o:p>= Пр = 80; применении импортных компонентоk= 4; системное проектировk= 2;ние и обеспечениk= 7; качества программныm= 3; продуктов следу = 77;т учитывать, что, в принципе, в них возможн = 99; как злоумышленl= 5;ые, так и случай= 085;ые, непредумышl= 3;енные дефекты вычислителn= 0;ного процесса, пр= 086;грамм и данных, отражающиеl= 9;я на качестве = 080;х функционирl= 6;вания. Зл= оумышленныk= 7; вирусы= и/или “закладки”, хотя l= 0; маловероятl= 5;ы, в серийных, широк= ;о тиражируемm= 9;х в мире программныm= 3; продуктах, однако треб = 91;ются особые методы и средства дл= 03; целенаправl= 3;енного их обнаружениn= 3; и устранени= 03;. Зарубежным специалистk= 2;м свойственнl= 6; ошибаться, так же, как и отечественl= 5;ым, однако боле = 77; высокое кач = 77;ство используемm= 9;х технологий разработки = 80; современнаn= 3; проектировl= 6;чная культура позволяют значительнl= 6; снижать уровень случайных дефектов в программныm= 3; продуктах, поступающиm= 3; на рынок. Однак= 086; в любых сложных импортных П = 57; всегда не гарантировk= 2;но полное, абсо= 083;ютное отсутствие случайных ошибок и дефектов, которые могут быть в= 072;жнейшими дестабилизl= 0;рующими факторами проектов. Их применение = 74; критически&= #1093; отечественl= 5;ых системах тр = 77;бует соответствm= 1;ющего дополнителn= 0;ного контроля качества и специальныm= 3; работ по обе= 089;печению надежности = 80; безопасносm= 0;и при проектировk= 2;нии и эксплуата = 94;ии.<o:p></o:p> Комплек= ;сирование готовых импортных П = 57; и компонент = 86;в при проекти = 88;овании конкретной отечественl= 5;ой системы создает усл = 86;вия их функцион = 80;рования не всегда адекватные предусмотрk= 7;нным разработчиl= 2;ами и проверенныl= 4; при испытан = 80;ях, хотя, может быть, и не выходящие з = 72; пределы требований эксплуатацl= 0;онной документацl= 0;и. Это способствуk= 7;т проявлению ранее скрытых дефектов и ошибок, и выз&#= 1099;вает необходимоl= 9;ть их устранен = 80;я. Для этого ответственl= 5;ые и квалифици = 88;ованные поставщики зарубежных программныm= 3; продуктов имеют служб = 99; сопровождеl= 5;ия, регистрациl= 0; и накоплени= 03; претензий пользоватеl= 3;ей и быстрого реагированl= 0;я для устране = 85;ия реальных дефектов функционирl= 6;вания. Легальная закупка и использоваl= 5;ие лицензионнl= 6; чистых программныm= 3; продуктов, о= 073;еспеченных сопровождеl= 5;ием фирмы-поста = 74;щика, позволяет в значительнl= 6;й степени сни = 78;ать влияние на качество функционирl= 6;вания ПС дефектов, не предотвращk= 7;нных в процессе и= 093; создания.<o:p></o:p>= Состояние экономики и промышленнl= 6;сти страны все больше зави = 89;ит от качества сложных информациоl= 5;ных систем и их важнейшей, интеллектуk= 2;льной части – программныm= 3; продуктов, применяемыm= 3; для управле = 85;ия в экономике, социальной сфере, системах вооружения = 80; других областях. В связи с этим стратегичеl= 9;кой задачей стало обеспечениk= 7; высокого ка = 95;ества отечественl= 5;ых программныm= 3; продуктов при их массовой разработке = 80; поставке дл= 03; различных сфер примен = 77;ния в стране и на мировом рынке. Для конкурентоl= 9;пособности в мире сложных программныm= 3; продуктов и возl= 4;ожности их успешног = 86; экспорта он = 80; должны быть = 089;ертифициро&= #1074;аны и соответствl= 6;вать требованияl= 4; международl= 5;ых стандартов. <o:= p></o:p> Для удостовереl= 5;ия качества, надежности = 80; безопаснос&= #1090;и применения сложных, кри= 090;ических систем, используемm= 9;е в них програ= 084;мные продукты, следует подвергать сертификацl= 0;и аттестованl= 5;ыми, проблемно-о = 88;иентирован&#= 1085;ыми испытательl= 5;ыми центрами (см. лекцию 18). Такие испыт = 72;ния необходимо проводить, когда прогр = 72;ммы управляют сложными процессами или обрабатываn= 2;т столь важну= 02; информацию, что дефекты = 074; них или недо= 089;таточное качество могут нанести зна = 95;ительный ущерб. Серти= 092;икационные испытания должны устанавливk= 2;ть соответствl= 0;е комплексов программ документацl= 0;и и допускать их к эксплуатацl= 0;и в пределах и= 079;менения параметров внешней среды, иссле= 076;ованных при проведе = 85;ных проверках. Эти виды исп= 099;таний характеризm= 1;ются наибольшей строгостью = 80; глубиной проверок и должны проводитьсn= 3; специалистk= 2;ми, независимыl= 4;и от разработ = 95;иков и от заказчиков (пользовате = 83;ей). <o:p></o:p> Основой сертификацl= 0;и должны быть детальные и эффективныk= 7; Программы и методики испытаний комплексов программ на соответствl= 0;е требованияl= 4; заказчиков, специально разработанl= 5;ые тестовые задачи и ген= 077;раторы для их формированl= 0;я, а также высо= 082;ая квалификац= ия и авторитет испытателеl= 1;. Применение на предприя = 90;иях-разрабо&= #1090;чиках программныm= 3; продуктов, сертифицирl= 6;ванных систем качества и профилей международl= 5;ых стандартов на базе требований </sp= an>IS= O 9001:2000 и/или= ; CM= MI:2003, гарантируеm= 0; высокое, устойчивое управление качеством процессов и продуктов и = 93; жизненного цикла, а также позво = 83;яет во многих случаях обл = 77;гчать сертификацl= 0;ю конечного программноk= 5;о продукта. Поэтому зак = 72;зчики сложных программныm= 3; проектов должны выбирать подрядчикоk= 4;-исполнител&#= 1077;й, имеющих сертификатm= 9;, удостоверяn= 2;щие применение ими систем гарантировk= 2;ния качества на основе адаптироваl= 5;ных профилей международl= 5;ых стандартов. <o:= p></o:p> Пробелы в обучении методам про = 75;раммной инженерии оставляют широкое пол = 77; для произвола специалистl= 6;в при оценивании = 82;ачества их труда, а та&= #1082;же для появления многочислеl= 5;ных дефектов и ошибок в про= 077;ктах ПС. Возрастанl= 0;е сложности = 80; ответственl= 5;ости современныm= 3; задач, решаемых программамl= 0;, а также возможного ущерба от недостаточl= 5;ого качества их результатоk= 4;, значительнl= 6; повысило актуальносm= 0;ь освоения ме = 90;одов полного, стандартизl= 0;рованного описания требований = 82; характерисm= 0;икам качества и способов из = 84;ерения их реальных значений на различных э = 90;апах ЖЦ ПС. Резко возросла необх= ;одимость знаний специалистk= 2;ми понятий, определениl= 1; и способов оценивания = 93;арактерист&#= 1080;к качества пр = 86;граммных продуктов.<o:p></o:p>= Многие отечественl= 5;ые специалистm= 9; в области программныm= 3; средств привыкли видеть в стандартах рутину, сковывающуn= 2; их “творчес = 90;во”. Быстрое усложнение = 80; рост размеров ко = 84;плексов программ приводит к созданию крупных программисm= 0;ских коллективоk= 4; с профессионk= 2;льным разделениеl= 4; труда, в кото&#= 1088;ых необходимо регламентиl= 8;ование координироk= 4;анной деятельносm= 0;и групп специ = 72;листов над единым проектом. Обещания разработчиl= 2;ов в контракта = 93; с заказчика = 84;и создать высококачеl= 9;твенные программы в = 089;огласованн&= #1099;е сроки во многих случаях не в= 099;полняются, как вследствие различий в понимании ими требуем = 86;го качества, та= 082; и вследстви = 77; неумения оц = 77;нить ресурсы, необходимыm= 3; для достижения = 74;ысокого качества программ. В результате = 82;ачество программноl= 1; продукции зачастую ос = 90;ается низким, неподдающиl= 4;ся достоверноl= 1; оценке и не конкурентоl= 9;пособным на международl= 5;ом рынке. Поэтому важнейшей п = 88;облемой развития и применения современныm= 3; систем, является обучение и воспитание специалистl= 6;в в области пр= 086;граммной инженерии, и= 089;пользовани&= #1102; международl= 5;ых стандартов, = 089;пособствую&= #1097;их высокому ка = 95;еству ПС и достове= 088;ному его оцениванию. Необходимо их обучение умению формализовk= 2;ть требования = 80; достигать конкретные значения ха = 88;актеристик качества функционирl= 6;вания и применени= 03; сложных комплексов программ, с учетом тех ресурсов, которые нуж = 85;ы и доступны для обеспечениn= 3; и совершенстk= 4;ования этого качес = 90;ва. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102449"></a><a name=3D"_Toc508102222">Л&= #1077;кция 2. Профили стандартов = 78;изненного цикла систе = 84; и пр&= #1086;граммных сре</a>дств в программной инженерии</spa= n><o:p></o:p></h1> <o:p> </o:p> <h1><a name=3D"_Toc508102450"></a><a name=3D"_Toc508102223">2.1. Назначение профилей стандартов жизненного цикла в прогр= аммной инженерии</spa= n></a> <o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n><o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При создании и сопровождеl= 5;ии сложных, распределеl= 5;ных, тиражируемm= 9;х ПС требуетс= 03; гибкое формированl= 0;е и применени = 77; гармонизирl= 6;ванных совокупносm= 0;ей базовых стандартов и нор= мативных документов разного уровня, выделение в них требова = 85;ий и рекоменда = 94;ий, необх= ;одимых для эффективноl= 1; реализации конкретных функций систем. Для унификациl= 0; и регламентиl= 8;ования реализации этих функци = 81;, совокупносm= 0;и базовых стандартов должны адаптироваm= 0;ься и конкретизиl= 8;оваться в программн = 86;й инженерии п = 88;именительн&#= 1086; к определеннm= 9;м классам про = 77;ктов, их функций, процессов и компонентоk= 4;. В связи с эти&#= 1084; выделилось = 80; сформироваl= 3;ось понятие "профиля стандартов"= ;, как основного инструментk= 2; функционалn= 0;ной стандартизk= 2;ции.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> <sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal;mso-bidi-font-styl= e: italic'>Профиль стандартов</spa= n> <span style=3D'font-size:14.0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font= -family: "MS Mincho";mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"T= imes New Roman"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > это совокупносm= 0;ь нескольких (или подмнож= 077;ство одного) базовых станд= ;артов (и других нормативныm= 3; документов) = 089; четко определеннm= 9;ми и гармонизи = 88;ованными подмножесm= 0;вами обязательl= 5;ых и факультатиk= 4;ных возможностk= 7;й, предназнаm= 5;енная для реализа = 94;ии заданной функции или группы функ = 94;ий. Функционаl= 3;ьная характерисm= 0;ика (заданный набор функций) объекта стандартизk= 2;ции является ис = 93;одной для формированl= 0;я и применени= 03; профиля этого объекта или процесса. В профиле выд = 77;ляются и устанавливk= 2;ются допустимые факультатиk= 4;ные возможностl= 0; и значения парам= ;етров каждого ба = 79;ового стандарта и/или нормативнl= 6;го докум= ;ента, входящего = 74; профиль. Профиль не может противоречl= 0;ть использоваl= 5;ным в нем базовым стандартаl= 4; и нормативн = 99;м документам. Он должен использоваm= 0;ь факул= ;ьтативные возможносm= 0;и и значения параметроk= 4; в пределах допустимых, выбранные и = 79; альтернатиk= 4;ных вариантов. На базе одной и той же совокупносm= 0;и базовых станд= ;артов могут= ; формироваm= 0;ься и утверждатьl= 9;я различные профили для разных проектов и сфер применения. Эти огранич = 77;ния базовых документов профиля и их гармонизацl= 0;я, проведеннаn= 3; разработчиl= 2;ами профиля, дол= 078;ны обеспечиваm= 0;ь качество, совме= ;стимость и корректно = 77; взаимодейсm= 0;вие компонентоk= 4; системы, соответстk= 4;ующих профилю, в заданной области его применения.<o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Основными целями= применениn= 3; профилей стандартов</spa= n> при создании и применении ПС являются:<o:= p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>сни= жение трудоемкосm= 0;и, длительносm= 0;и, стоимости = 80; улучшение других техн = 80;ко-экономич&= #1077;ских показателеl= 1; проектов си = 89;тем и комплексо = 74; программ;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>пов= ышение качества разрабатывk= 2;емых или применя = 77;мых покупных компонентоk= 4; и ПС в целом, при их разра= 073;отке, приобретеl= 5;ии, экспл= ;уатации и сопровождеl= 5;ии;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>обе= спечение расширяемоl= 9;ти ПС по набору прикладных функций и масштабируk= 7;мости в зависимостl= 0; от размерностl= 0; решаемых за = 76;ач;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>под= держка функционалn= 0;ной интеграциl= 0; в системах задач, ранее реша = 74;шихся раздельно;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>обе= спечение переносимоl= 9;ти программ и д= 072;нных между разны = 84;и аппаратно-п = 88;ограммными платформамl= 0;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Состояние и развитие стандартизk= 2;ции в области пр= 086;граммной инженерии х = 72;рактеризуе&#= 1090;ся следующими особенност= ;ями, которые нео = 73;ходимо учитывать при формир= 086;вании и применени = 80; профилей: <o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>нес= колько сотен разработанl= 5;ых международl= 5;ых и национальl= 5;ых стандартов не полностью = 80; неравномерl= 5;о покрывают п = 86;требности в стандарти = 79;ации объектов и п= 088;оцессов создания и применения сложн= ;ых систем, программныm= 3; средств и их компонентоk= 4;;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>бол= ьшая длительносm= 0;ь разработки, согласованl= 0;я и утвержден = 80;я международl= 5;ых и национальнm= 9;х стандартов (3-5 лет) приводи= 090; к их консерватиk= 9;му, а также к хрон= 080;ческому отставанию требованиl= 1; и рекl= 6;мендаций этих документов от современноk= 5;о состояния техники и от текущих потребностk= 7;й практики и технологии создания сложных си = 89;тем;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>ста= ндарты современныm= 3; ПС должн= ;ы: учитывать необходимl= 6;сть их построен = 80;я как открыты = 93; систем; обеспечиваm= 0;ь расширяемоl= 9;ть при наращив = 72;нии или изменении выполняемыm= 3; функций; переносимоl= 9;ть программныm= 3; средств и данных сист = 77;м между разны = 84;и аппаратно-п = 88;ограммными платформамl= 0;; возможностn= 0; взаимодейсm= 0;вия с другими информациl= 6;нными системами той жk= 7; проблемно-о = 88;иентирован&#= 1085;ой сферы;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>наи= более сложные и творческие процессы создания и р= 072;звития крупных рас = 87;ределенных ПС (системный анализ и проектироk= 4;ание, интеграция компонентl= 6;в и систем, испытания = 80; сертификацl= 0;я) почти не поддержаны требованияl= 4;и и рекоменда = 94;иями стандартов, вследствие трудности и = 93; формализацl= 0;и, унификации = 80; разнообразl= 0;я содержания;<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>чем сложнее объекты ил = 80; процессы, подлежащиk= 7; стандартизk= 2;ции, тем больше необходимо использоваm= 0;ь и формулиро = 74;ать предваритеl= 3;ьных услов= ;ий, учитываемm= 9;х в требо= ;ваниях и рекомендацl= 0;ях стандарта, которые следует адаптироваm= 0;ь и конкретиз = 80;ровать для корректногl= 6; их применен = 80;я в определен = 85;ом проекте;<o:p></o:p> <![if !supportList= s]>-<![endif]>- пробелы и задержки в подготовке = 80; издании стандартов высокого ранга и текущая по= 090;ребность унификации = 80; регламентиl= 8;ования современныm= 3; объектов и процессов в области программноl= 1; инженерии приводят к созда= ;нию и практическl= 6;му применению многочислеl= 5;ных нормативныm= 3; и методическl= 0;х документов отраслевогl= 6;, ведомственl= 5;ого или фирменн = 86;го уровня.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При практическl= 6;м форми= ;ровании и применениl= 0; профилей ПС = 074; ряде случае = 74;, возможно, испол= ;ьзовать национальl= 5;ые стандарты, станд= ;арты де-факто и ведомственl= 5;ые нормативныk= 7; документы. Это может быть обусловленl= 6; отставаниеl= 4; в разработк = 77; некоторых задач в междунаро = 76;ных стандартах или необходимоl= 9;тью учета конкр = 77;тных особенностk= 7;й систем. При применении стандартов = 80; профилей могут быть выявлены пробелы в положениях некоторых стандартов = 80; необходимоl= 9;ть модификациl= 0; или дополнения требований, определенl= 5;ых в них. Некоторые функции, не формализовk= 2;нные стандартамl= 0;, но важные дл= 103; унификации = 87;остроения или взаимодейсm= 0;вия компонентl= 6;в могут= определятn= 0;ся норма= ;тивными документаl= 4;и ведомства и = 83;и предприятиn= 3;, обязательнm= 9;ми для конкрет = 85;ого профиля и проекта.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Применениk= 7; стандартизl= 0;рованных профилей позволяет заказчику системы освободитn= 0;ся от заk= 4;исимости от одного поставщика программныm= 3; или аппарат = 85;ых средств за счет выбора этих средств из числа доступных н = 72; рынке и соответствm= 1;ющих стандартам, = 085;ормативным требованияl= 4; и рекомендацl= 0;ям профи= ;ля. Применение профи= ;лей, относящихсn= 3; к программныl= 4; комплексам (функционал= 00;ным частям систем), облег= ;чает повторное использоваl= 5;ие в проектируk= 7;мой системе уже разработанl= 5;ых и проверенн = 99;х программныm= 3; компонентоk= 4;. Профили ПС у= 085;ифицируют и регламент = 80;руют только част= 00; требований = 80; характерисm= 0;ик объектов и п= 088;оцессов, выделенных = 80; формализовk= 2;нных на базе стандартоk= 4; и норма= ;тивных документов. Другая часть функционалn= 0;ных и техническиm= 3; характерисm= 0;ик систем определяетl= 9;я заказчикамl= 0; и разработчl= 0;ками творчески, без учета положений нормативныm= 3; документов.<o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = Профиль стандартов ЖЦ ПС (функционал= 00;ных частей сист = 77;мы) должен= определятn= 0; архит= ;ектуру программнl= 6;го комплекса (м= 086;дели функций, логич= ;еские модели данных, внешние интерфейсm= 9;) и их стl= 8;уктуру (разбиение системы на подсистемы = 80; систем на мо= 076;ули, определениk= 7; унифициров&#= 1072;нных интерфейсоk= 4; взаимодейсm= 0;вия между компл = 77;ксами программ и и= 093; компонентаl= 4;и). Жизненный цикл програ = 84;мных средств отр = 72;жается в профиле стандартов набором: проце= ;ссов, этапов, частных работ и операций в п= 086;следовател&= #1100;ности их выполнения = 80; взаимосвязl= 0;, регламентl= 0;рующим ведение разработки, = 089;опровожден&= #1080;е и эксплуатацl= 0;ю, от анk= 2;лиза и подготовк = 80; требований до завершения испытаний ряда версий программноk= 5;о продукта и п= 088;екращения их использоваl= 5;ия. Жизне= ;нный цикл вкл</spa= n>ючает описания исходной информации, = 089;пособов и методов выполнения операций и работ, устанавливk= 2;ет требования = 82; результатаl= 4; и правилам их ко= нтроля, а также= ; опред= ;еляет содержание технологичk= 7;ских и эксплуата = 94;ионных документов. Он определяет = 86;рганизацио&#= 1085;ную структуру к = 86;ллектива специалистl= 6;в, регла= ментирует распределеl= 5;ие и планирова = 85;ие работ, а также = 82;онтроль за ходом разработки. = 055;овышение эффективноl= 9;ти разработки, качества программноk= 5;о продукта и производитk= 7;льности труда специалистl= 6;в дост = 80;гается за счет: <o:p></o:p>= <![if !supp= ortLists]>-&nb= sp; <![endif]>рег= ламентации организацl= 0;и и порядка проведениn= 3; работ;<o:p></o:p> <![if !supp= ortLists]>-&nb= sp; <![endif]>авт= оматизации этапов и операций;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>рац= ионального разделения труда между специалистk= 2;ми разной ква = 83;ификации и проблемно = 81; ориентации. <o:= p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Профиль ЖЦ ПС конкретной системы должен учитывать е= 05; функционалn= 0;ную ориентацию. Он должен содержать ссылки на стандартиk= 9;ированные интерфейсm= 9; между комплексоl= 4; программ и внешней сре = 76;ой, которые описываютсn= 3; в профилях среды систе = 84;ы. Каждый профиль и его параметры для примене = 85;ия в конкретно = 84; проекте системы необходимо = ;поэтапно адаптироваm= 0;ь и детализир = 86;вать в соответствl= 0;и с этапом про= 077;кта. Особенностl= 0; организациl= 6;нных структур, различия в размерах и сложности проектов, в требованияm= 3; к системам и применяемыl= 4; методам их разработки, необходимl= 6;сть преемственl= 5;ости с системами, находящимиl= 9;я в эксплуатацl= 0;и, влияют на организациn= 2; разра= ;ботки, приобретенl= 0;я, применениn= 3; и сопровожд = 77;ния программныm= 3; средств. Каждый из вы= 076;еленных профилей должен для последующеk= 5;о длительногl= 6; использоваl= 5;ия пройти стад = 80;ю формированl= 0;я, адаптации и параметризk= 2;ции применителn= 0;но к характери = 89;тикам стандартизl= 0;руемых объектов ил = 80; процессов.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Для корректногl= 6; применения<s= pan style=3D'mso-spacerun:yes'> &#= 1086;писания профилей стандартов должны соде = 88;жать:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>опр= еделение целей, которые предполагаk= 7;тся достичь применениеl= 4; данного профиля стандартов;<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>пер= ечисление функций продукта ил = 80; процесса стандартизk= 2;ции, определяемl= 6;го данным профилем;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>фор= мализованнm= 9;е сценарии применения базовых станд= ;артов и спеm= 4;ификаций, включенных = 74; данный профиль;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>сво= дку требований = 82; системе или&nbs= p; к её компонентk= 2;м, опред= ;еляющих их соответстk= 4;ие профилю и требований = 82; методам тес = 90;ирования соответствl= 0;я;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>ссы= лки на конкретный набор станд = 72;ртов и других нормативныm= 3; документов, составляющl= 0;х профиль, с то&#= 1095;ным указанием используемm= 9;х положений, редакций и ограничениl= 1;, способных оказать влияние на достижение = 82;орректного взаимодейсm= 0;вия объектов стандартизk= 2;ции при использ = 86;вании данного профиля;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>инф= ормационныk= 7; ссылки на спецификацl= 0;и тестов проверки соответствl= 0;я профилю.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> В зависимостl= 0; от области р= 072;спростране&= #1085;ия профилей он = 80; могут иметь = 088;азные статусm= 9; утверждениn= 3;:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>про= фили конкретной системы, определяюm= 7;ие стандартиk= 9;ированные проектные решения в пределах данного проекта и яв= 083;яющиеся частью прое = 82;тной документацl= 0;и;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>про= фили, предназнаm= 5;енные для решения некоторого класса прикладных = 79;адач, которые распростраl= 5;яются на все системы и П= 057; данно= ;го класса в пределах пр = 77;дприятия или отрасли = 080; утверждаютl= 9;я как стандар = 90;ы предприятиl= 1;, ведомствеl= 5;ные или государ = 89;твенные стандарты.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Особенносm= 0;и организациl= 6;нных структур, различия в размерах и сложности п = 88;оектов, требо= ;ваниях к системам и применяемыl= 4; методам их разработки, необходимl= 6;сть преемственl= 5;ости с системами, находящимиl= 9;я в эксплуатацl= 0;и, влияют на о= 088;ганизацию разработкl= 0;, приобретенl= 0;я, приме= ;нения и сопровождеl= 5;ия аппаратных = 80; программныm= 3; средств. Для эффективн = 86;го применения конкретногl= 6; профиля необходимо</spa= n>:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>выд= елить объединеннm= 9;е единой логическоl= 1; связью пробл= ;емно-ориент= 080;рованные области функционирl= 6;вания систем, где м&#= 1086;гут использоваm= 0;ься стандарты, общие для од= 085;ой организациl= 0; или группы предприятиl= 1;;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>иде= нтифицировk= 2;ть стандарты и нормативныk= 7; документы, варианты их применения = 80; параметры, которые необходимо включить в п= 088;офиль стандартов;<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>док= ументально зафиксировk= 2;ть участ= ;ки конкретноk= 5;о профи= ;ля, где требуется создание новых станд = 72;ртов или нормативныm= 3; документов, = 080; идентифициl= 8;овать характерисm= 0;ики, которые могут оказаться важными для разработки недостающиm= 3; стандартов = 80; нормативныm= 3; документов этого профиля;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>фор= мализовать профиль в соотв= ;етствии с его катег= ;орией, включая стандарты, различные варианты нормативныm= 3; документов и допl= 6;лнительные параметры, которые непосредстk= 4;енно связаны с профилем;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>опу= бликовать профиль и/или продв= ;игать его по фоl= 8;мальным инстанциям для дальнейшегl= 6; распростраl= 5;ения на предприятиl= 0; или в отрасл= 080;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> <o:p></o:p></spa= n> <h1><a name=3D"_Toc508102451"></a><a name=3D"_Toc508102224">2.2. Жизненный цикл профилей ст = 72;ндартов систем и = &nb= sp; = программнm= 9;х средств</a> <o:p></o:p></h1> </spa= n><o:p></o:p> </spa= n>Пр = 86;филь стандартов конкретной системы не является статичным, он развиваетсn= 3; и конкретизиl= 8;уется (возможно, во<s= pan style=3D'mso-spacerun:yes'> взаим= ;одействии с заказчико = 84;) в процессе жизненного цикла и оформляетсn= 3; в составе до= 082;ументации системы. Разработкk= 2; и применение профилей стандартов являются орган= 080;ческой частью процессов жизненного цикла, разработки = 80; развития систем. Проектировk= 2;нию системы предшествуk= 7;т обследованl= 0;е объекта автоматизаm= 4;ии, результатl= 6;м которой являются ег = 86; функционалn= 0;ная и информациl= 6;нная модели, определениk= 7; целей создания системы и состава ее функций. Стандарты, важные с точки зрени= 03; заказчика, должны= задаватьсn= 3; в спецификацl= 0;и требований на проектир = 86;вание системы и составлять её пе= 088;вичный профиль. То, чт = 86; не задано в требованияm= 3; заказчика, остается первоначалn= 0;но на усмотрение = 88;азработчик&#= 1072; системы, который, руководствm= 1;ясь требованияl= 4;и спецификацl= 0;й, может допол = 85;ять и развивать профили, которые согласуютсn= 3; с заказчико = 84;. В профиль ко= 085;кретной системы включаются специ= ;фикации стандартиk= 9;ации компонентоk= 4;, разра= ;ботанных в составе данно= ;го проекта, и спецификацl= 0;и использоваl= 5;ных готовых программныm= 3; и аппаратны = 93; средств, если эти средств = 72; не специфиц = 80;рованы соответствm= 1;ющими стандартамl= 0;. После завершения проектировk= 2;ния и испытаний системы, в ходе которы = 93; проверяетсn= 3; ее соответс = 90;вие профилю, профиль применяетl= 9;я как основно = 81; инстр= 091;мент сопровождеl= 5;ия системы при эксплуатацl= 0;и, модернизацl= 0;и и управлени = 80; конфигурацl= 0;ей.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Целесообрk= 2;зно рассматривk= 2;ть &#= 1076;ве группы профилей систем (рис. 2.1):<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>функциl= 6;нальные профили, регламентиl= 8;ующие архитектурm= 1; и структуру объектов системы и ее компонентоk= 4;; функции, интер= ;фейсы и протоколы взаимодейсm= 0;вия, форматы данных;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>технолl= 6;гические профили, регламен= ;тирующие процессы п = 88;оектирован&#= 1080;я, разработкl= 0;, применения, сопровождеl= 5;ия и развития систем и их компонентоk= 4;. <o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Н= 072; этапах жизненного цикла систе = 84;ы выбираются = 80; затем приме = 85;яются общесистемl= 5;ые функционалn= 0;ные профили:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>про= филь жизненногl= 6; цикла информациоl= 5;ной системы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>про= филь аппаратной = 80; операционнl= 6;й среды систе = 84;ы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>про= филь внешней и пользоватеl= 3;ьской среды функционирl= 6;вания ПС;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>про= филь обеспечениn= 3; безопасносm= 0;и функционирl= 6;вания и защиты инф= 086;рмации в системе;<o:p></o:p></span= > <![if !sup= portLists]>-&nb= sp; <![endif]>про= филь инструментk= 2;льных средств, подде= ;рживающих весь жизнен = 85;ый цикл системы.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При применении функционалn= 0;ных профилей системы следует иметь в виду согласоваl= 5;ие (гармонизац = 80;ю) этих профилей ме = 78;ду собой. Необходимl= 6;сть такого согласоваl= 5;ия возникает, в частности, при примене = 85;ии стандартизl= 0;рованных интерфейсоk= 4;, в том числе, и&= #1085;терфейсов ПС и БД со средой их фу= 085;кционирова&= #1085;ия, интерфейсоk= 4; со средствами = 79;ащиты информации. При согласованl= 0;и функционалn= 0;ных профилей возможны также уточн = 77;ния профиля внешней среды системы и профиля инструментk= 2;льных средств соз = 76;ания, сопровождk= 7;ния и развития программныm= 3; средств.<o:p></o:p> Детализацl= 0;я общесисте= 084;ных профилей стандартов</spa= n> производитl= 9;я по мере деко= 084;позиции структуры системы на составляющl= 0;е её компонен = 90;ы. Выбор и применение этих профилей является ор = 75;анической частью процессов проектировk= 2;ния, разработкl= 0;, сопровождеl= 5;ия и развития сложных систем. Их применение включает процессы: <o:p>= </o:p> <![if !supportLis= ts]>- = <![endif]>выб= ор аппаратной = 80; операционнl= 6;й среды систе = 84;ы определеннl= 6;го класса;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>опр= еделение внешней и пользоватеl= 3;ьской среды функционирl= 6;вания и применени= 03; системы;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>под= готовку администраm= 0;ивного управления системой ка = 95;ества;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>выб= ор готовых программныm= 3; и аппаратны = 93; средств, соответстk= 4;ующих функц= ;иям и профилям системы;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>про= ектированиk= 7; и разработк = 72; программныm= 3; средств и ба= 079; данных (функционал= 00;ных частей системы) в соответствl= 0;и с выбранным = 80; профилями, в частности в соответствl= 0;и со стандартамl= 0; на интерфейсm= 9;;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>раз= работка требований = 82; методам тести= ;рования компо= ;нентов системы на соответствl= 0;е функционалn= 0;ным профилям, выбор или разработка тестов соот = 74;етствия;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>тес= тирование компонентоk= 4; системы на соответствl= 0;е профилям ил = 80; проверка сертификатl= 6;в соответствl= 0;я для применяемыm= 3; готовых про = 75;раммных и аппаратны = 93; средств;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ком= плексироваl= 5;ие компонентоk= 4; в создаваем = 86;й системе на основ= ;е последоватk= 7;льного применения профилей и и= 093; квалификацl= 0;онного тестированl= 0;я.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Применениk= 7; функционалn= 0;ных профилей должны поддерживаm= 0;ь основные, &#= 1090;ехнологиче= ские профили (см. рис. 2.1): <o:p>= </o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>жиз= ненного цикла программныm= 3; средств и ба= 079; данных;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>обе= спечения качества программныm= 3; средств и информации баз дk= 2;нных;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>вер= ификации, тестированl= 0;я и сертификацl= 0;и ПС и БД;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>соп= ровождения и управлени= 03; конфигурацl= 0;ей ПС и информа= 094;ией БД;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; = <![endif]>док= ументироваl= 5;ия программныm= 3; средств и ин= 092;ормации баз данных.<o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> <sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>Быстро оснащающиk= 7;ся разли= ;чными методами и средствами = 72;втоматизац&#= 1080;и этапы системного анализа, моделироваl= 5;ия и предваритk= 7;льного проектироk= 4;ания не позволяю = 90; стабилизирl= 6;вать основу этих процессов, достаточнуn= 2; для их полно= 081; формализацl= 0;и для любых систем на уровне международl= 5;ых стандартоk= 4;. Поэтому для этих этапо = 74; могут созда = 74;аться и применятьсn= 3; профили ЖЦ П= 057; как проблем = 85;о-ориентиро&= #1074;анные совокупносm= 0;и нормативныm= 3; документов = 80; методическl= 0;х руководств, отражающиk= 7; как наиболе = 77; современныk= 7; методы, так и фрагм= ;енты действующl= 0;х стандартов, в том числе станд = 72;ртов "де-факто". <o:p></o:p>= Отдельные внутренние этапы жизне = 85;ного цикла компонентоk= 4; и комплексо = 74; программ обеспечиваn= 2;тся группами сm= 0;андартов на локальны = 77; процессы, определяющl= 0;е:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>языки и процессы программирl= 6;вания программныm= 3; компонентоk= 4;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>визуализа= ;цию информации для пользоватеl= 3;ей и обеспечениn= 3; управления жизненным циклом ПС;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>защиту информациоl= 5;ных ресурсов от несанкционl= 0;рованных вмешательсm= 0;в и криптографl= 0;и;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>телекомму= ;никацию и взаимодейсm= 0;вие с внешней средой. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Эта группа стандартов непосредстk= 4;енно определяет инструментk= 2;льные средства решения соответствm= 1;ющих задач и в процессах жизненного цикла ПС обычно стабильны, н= 077; изменяются = 80; не раскрыва= 02;тся ниже в профи= 083;ях ЖЦ.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Учитывая динамику формированl= 0;я и применени= 03; профилей жизненного цикла ПС, по мере детали = 79;ации структуры системы и ее<sp= an style=3D'mso-spacerun:yes'> возмо= ;жного развития, образуется </sp= an>жизненный цикл профилей стандартов</spa= n>. Жизненный цикл профилей ПС целесообраk= 9;но рассматривk= 2;ть в составе технологичk= 7;ских работ проекта отд = 77;льно от этапов и работ непос = 88;едственной разработки = 80; эксплуатацl= 0;и самих программныm= 3; средств и ба= 079; данных. Соз = 76;ание и применени = 77; профилей жизненного цикла ПС можно разделить н = 72; два крупны= 093; процесса (рис. 2.2):<o:p></o:p></sp= an> <![if !sup= portLists]>-&nb= sp; <![endif]>разрабl= 6;тка, формироваl= 5;ие и адаптация</sp= an> профилей стандартов ЖЦ ПС для использоваl= 5;ия в конкретно = 84; проекте системы;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>неп= осредственl= 5;ое применk= 7;ние требований = 80; рекомендацl= 0;й каждог&#= 1086; адаптироваl= 5;ного профиля стандартов для регламентиl= 8;ования этапов, работ и документо = 74; проекта ПС.<o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При создании ПС профили стандартов развиваютсn= 3; и детализир = 91;ются параллельнl= 6; с конкретиз = 72;цией проекта. Они должны обеспечиваm= 0;ь соответствm= 1;ющую часть &#= 1090;ехнологиче= ской поддержки разработки комплекса программ нормативныl= 4;и документамl= 0;. Таким образом, жизненный цикл профилей, в некоторой степени, подобен жизненному циклу самих программныm= 3; средств и баз данных. Завершение разработки профилей ст = 72;ндартов системы и оформление результатоk= 4; должно опережать, обеспечиваm= 0;ь и подготавл = 80;вать выполнение соответствm= 1;ющих этапов и работ основ = 85;ого жизненного цикла комплекса п = 88;ограмм. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Процессы жизненного цикла, развития системы и её программныm= 3; компонентоk= 4; должны быть поддержаны </sp= an>этапами развития и приме- нения комп = 83;екта профилей, ко= 090;орые включают:<o:p></o:p>= <![if !supportLis= ts]>- = <![endif]>сис= темный анализ объекта информатизk= 2;ции и создания к= 086;нцепции системы, ког= 076;а производитl= 9;я первичный выбор исходного компл= ;екта стандартов</spa= n>, которым должна соответствl= 6;вать система; выявляется необходимоl= 9;ть разработки = 80; состав дополнителn= 0;ных норма= ;тивных докум= ;ентов; оформляетсn= 3; содержание = 80; параметры комплектов документов предполагаk= 7;мых профилей;<o:p></o:p>= <![if !sup= portLists]>- = <![endif]>про= ектированиk= 7; системы, когда= ; определяюm= 0;ся требования = 82; её архитектуl= 8;е и структуре = 080; соответствk= 7;нно уточн= ;яются положения, параметры и адаптируютl= 9;я стандарты комплекта профилей; &#= 1086;формляются проекты документов</spa= n> и методичесl= 2;их руков= ;одств по применению = 88;абочей версии каждого про = 92;иля стандартов;<o:p= ></o:p> <![if !sup= portLists]>- = <![endif]>раз= работку или приобретеl= 5;ие готовых компонентоk= 4; системы, при этом утk= 4;ерждаются и применяютсn= 3; все положен = 80;я профиля; производиm= 0;ся контроль, тестированl= 0;е и испытания компонентоk= 4; на соответс = 90;вие требованияl= 4; и документа = 84; конкретногl= 6; профиля стандартов;<o:p= ></o:p> <![if !sup= portLists]>- = <![endif]>соп= ровождение, актуализацl= 0;ю и развитие с= 080;стемы, когда анализируюm= 0;ся положения, параметры = 80; результаты адаптации п = 88;именяемой версии= каждого профиля; &#= 1074;ыявляются и устраняютсn= 3; дефекты про = 92;илей;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>модернl= 0;зацию профиля, с &= #1091;четом появления более совершенныm= 3; техническl= 0;х и программныm= 3; средств, а также новых стандартов; при необходимоl= 9;ти осуществляk= 7;тся формированl= 0;е, документирl= 6;вание и внеk= 6;рение новой модифицироk= 4;анной и уточненно = 81; версии соответствm= 1;ющего профиля. <o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> В общем случае= созданию п = 88;офилей жизненного цикла систе = 84;ы, должно предшествl= 6;вать обсле= ;дование объекта информатизk= 2;ции, для которого предполагаk= 7;тся создавать систему. Результатаl= 4;и работ на этом этапе явля= 02;тся функционалn= 0;ная и информаци = 86;нная модели, а также специ = 92;икации требованиl= 1;, котор= ;ые служат в кач= 077;стве исходных данных для проектировk= 2;ния системы и ПС.<s= pan style=3D'mso-spacerun:yes'> Целесообрk= 2;зно, чтобы эти модели= и сп= ецификации требований были выполн = 77;ны с помощью формализовk= 2;нных методов их о= 087;исания, например, с использоваl= 5;ием средств описания мо = 76;елей в известных методологиn= 3;х структурноk= 5;о проек= ;тирования и языков спецификацl= 0;й. В специфl= 0;кации должны быть опреде = 83;ены требовk= 2;ния к жизненном = 91; циклу систе = 84;ы, даны ссылки на действующиk= 7; норма= ;тивные документы = 80; определен = 72; предваритеl= 3;ьная структура профиля стандартов жизненногl= 6; цикла. Следует задать требования = 82; качеству системы и, соответствk= 7;нно, первичный п = 88;офиль обеспечениn= 3; качества комплекса п = 88;ограмм и данных, функционалn= 0;ные требования = 82; системе <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- состав реша = 77;мых задач и ссыл= 082;и на нормативныk= 7; документы, которые рег = 83;аментируют правила и процедуры выполнения функций и операций. <o:p></o:p></span= > На этапе систе= 084;ного анализа при планированl= 0;и профиля тех = 85;ологическо&#= 1081; поддержки разработки ПС следует проанализиl= 8;овать набор базовых меж = 76;ународных станд= ;артов, связанных с регла= ;ментирован = 80;ем особенностk= 7;й сист= ем и программнm= 9;х средс= ;тв. Для поддержки жизненного цикла разрабатывk= 2;емых ПС необходимо из них вm= 9;брать предваритеl= 3;ьный набор стандартов, в наибольшей степени относящихсn= 3; к ПС данного класса. Этот набор стандартов может быть дополнен во = 79;можными и целесообр = 72;зными для применения стандартамl= 0; де-факто и перечнем по = 76;лежащих разработке нормативныm= 3; документов данного проекта. В результате формируетсn= 3; предв= 072;рительный перечень стандартов и нормативнm= 9;х докум= ;ентов, который должен стать основой для профилей ЖЦ ПС. Этот перечень должен быть указан в спецификацl= 0;и требований или войти в с&#= 1086;став системного проекта комплекса п = 88;ограмм.<o:p></o:p> Од= ним из преимущестk= 4; от разработки = 80; внедрения профиля ста = 85;дартов для большой организациl= 0;-пользовате&#= 1083;я является то, что он обесп= 077;чивает совершенство= вание взаимосвязk= 7;й, особенно между разными подразделеl= 5;иями, которым необходимы гарантии того, что их системы буд = 91;т корректно взаимодейсm= 0;вовать, а ключевые программныk= 7; средства и данные будут переносимы между платформамl= 0;, полученнымl= 0; от разных поставщикоk= 4;. На этапе о= ;пределения области применения профиля должны быть выявлены:<o:p></o:p>= <![if !supportLists]>-&nb= sp; <![endif]>направлени= ;я деятельносm= 0;и предприятиn= 3;, подлежащие учету при построении профиля;<o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>срок реализации профиля и контрольнаn= 3; дата, когда работа над п= 088;офилем должна быть завершена;<o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>техническl= 0;е стратегии, предположеl= 5;ия и о= граничения проекта системы и ПС;</= span><o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>опытный и энергичный лидер, который пользуется = 74; предприятиl= 0; уваж= ;ением и авторитет = 86;м, достаточныl= 4; для того, чтобы возгл = 72;вить и довести до конца работ = 91; по = созданию и утверждениn= 2; профиля ста = 85;дартов проекта системы и ПС;</= span><o:p></o:p> <![if !supportLists]>-&nb= sp; <![endif]>уровень компетентнl= 6;сти коллектива, разрабатывk= 2;ющего пр= офиль, его знания и пригодностn= 0; к экспертиз = 77; проекта и деят= ;ельности предприятиn= 3;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> На этапе проектировk= 2;ния профиля ПС уточ= ;няется жизне= ;нный цикл и основные характерисm= 0;ики проекта. Это позволяет селектир = 86;вать перечень ст = 72;ндартов и нормативн = 99;х документов, целесообраk= 9;ных для использ = 86;вания в профилях Ж = 62; данного ПС, провести и = 93; адаптацию д = 83;я применения = 89; учетом= характериl= 9;тик проекта, метод= ;ологии и технологии создания ПС, а также предполагаk= 7;мых средств автоматизаm= 4;ии разработки, = 089;опровожден&= #1080;я и управлени= 03; конфигурацl= 0;ей комплекса программ. На этом этапе описываютсn= 3; как функционалn= 0;ные, так и технич= 077;ские требования, устанавливk= 2;емые в профиле. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> В уточненном плане= ; реализациl= 0; системы должны= быть предс = 90;авлены ссылки на соста= ;в и содержани = 77; документов каждого про = 92;иля, выделены компоненты, параметры и ограничениn= 3;, сформироваl= 5;ные в процессе адаптации профиля ЖЦ данного ПС. Для разрабо = 90;чиков и заказчико = 74; на этом этап= 077; должен быть создан прое = 82;т руководствk= 2; применения профилей на последующиm= 3; этапах ЖЦ. В результате на этом этапе &= nbsp; формируетl= 9;я прое = 82;т адаптировk= 2;нного набора проф = 80;лей. Необходимо провести предваритk= 7;льное обучение ра = 79;работчиков проекта применению профилей ЖЦ ПС и основны= 084; концепциям профилей дл= 03; данной системы. Конкретизаm= 4;ия обеспечениn= 3; технологичk= 7;ской поддержки последующеl= 1; разработки ПС позволяе = 90; завер= 096;ить и утвердить адаптироваl= 5;ные профили, подде= ;рживающие ЖЦ ПС, а также руководствk= 2; по их применению. </s= pan>Результатl= 6;м этого процесса является определениk= 7; стандартов = 80; выбор интер = 92;ейсов, которые удовлетворn= 3;ют требованияl= 4;, предъявляеl= 4;ым к системе в ц&#= 1077;лом. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext; mso-bidi-font-style:italic'> &n= bsp; Этап разработки</spa= n> системы и ко= 084;плекса программ связан, преж= 076;е всего, с прог&#= 1088;аммировани= ем и тестированl= 0;ем компонентоk= 4; ПС, которые создаются заново для данной системы. Одновременl= 5;о создаются функционалn= 0;ные тесты для проверки выполнения = 82;омпонентам&#= 1080; заданных фу = 85;кций. Разработка прогр= ;аммных средств и их компонентоk= 4; произ= ;водится с помощью инстр= ;ументальны = 93; средств, отвечающих требованияl= 4; выбранного ранее профиля методологиl= 0; и технологи = 80;. Системны&= #1077;, аппаратные = 80; программныk= 7; средства необходимо проверять н = 72; соответствl= 0;е функционалn= 0;ным и эксплуатацl= 0;онным требованияl= 4; профилей. Если закупленныk= 7; продукты ил = 80; платформы уже прошли у поставщика тестированl= 0;е на соответс = 90;вие профилям, процедура тестированl= 0;я у потребите = 83;я может быть несколько сокращена п = 88;и условии, что нет проблем = 089; несоответсm= 0;вием архитектурm= 9; стандартам. </s= pan>Состав и содержани = 77; применяемыm= 3; документов профилей ЖЦ ПС должны быть тесно связа = 85;ы с планом и перечнем работ, выполняемыm= 3; на соответствm= 1;ющих этапах. В обязательнm= 9;х документах должно быть также отражено со = 76;ержание дополнителn= 0;ных нормативныm= 3; документов, согласуемыm= 3; с заказчико = 84;. <o:p></o:p> На этапе внедрения профиля стандартов</spa= n> важно иметь план по его применению. = 056;уководител&= #1080; высшего уровня должны установить приоритеты при реализа = 94;ии отдельных частей и требований профиля. Внедрение профиля в соответствl= 0;и с задачами проекта или предприятиn= 3; будет упрощ = 77;но, если ключевые цели обеспечениn= 3; функционалn= 0;ной совместимоl= 9;ти будут четко документирl= 6;ваны в профиле. План внедрения профиля дол = 78;ен быть действующиl= 4; документом = 80; постоянно актуализирl= 6;ваться по мере изменения проекта. <o:p></o:p> Для обеспечениn= 3; корректногl= 6; применения = 82;аждого профиля должна быть разработанk= 2; и утвержден = 72; методика проверки и тести= ;рования для установлеl= 5;ия степени соответствl= 0;я комплекса п = 88;ограмм утвержденнl= 6;му профилю ЖЦ П= 057; и БД. Содержаниk= 7; и рекоменда = 94;ии профилей ЖЦ должны быть освоены специалистk= 2;ми, осуществлn= 3;ющими контроль их выполнения = 80; тестированl= 0;е создаваемоk= 5;о комплекса программ. Отдельн= ;ые компоненты профиля подлежат тестированl= 0;ю, как с точки зрения соответствl= 0;я необходимыl= 4; стандартам, так и соответствl= 0;я требованияl= 4;, сформулироk= 4;анным в терминах и= 093; характерисm= 0;ик качества. Тестированl= 0;е на соответс = 90;вие не гарантируеm= 0; функционалn= 0;ной совместимоl= 9;ти, оно представляk= 7;т лишь тест на <s= pan style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>сl= 6;ответствие набору тестовых утверждениl= 1;, содержащихl= 9;я в стандарте. Поведение объекта отслеживаеm= 0;ся и сравниваетl= 9;я с ожидаемым результатоl= 4; эталонной реализации. </s= pan><o:p></o:p><= /span> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> После детального проектировk= 2;ния версии ПС все последующl= 0;е работы по со= 079;данию комплекса программ, вплоть до завершения испытаний и сертификацl= 0;и, должны проводитьсn= 3; в соответствl= 0;и с утвержден = 85;ыми профилями ЖЦ ПС</spa= n>, руководстk= 4;ами по их примен= 077;нию и проверятьсn= 3; на соответствl= 0;е профилям по утвержденl= 5;ым метод= ;икам тестированl= 0;я. Для этого должны быть созданы пла = 85;, перечень и содержание работ, в которых применяютсn= 3; конкретные фрагменты, определеннm= 9;е положения каждого профиля и ра= 079;делы методики, по которым тестируетсn= 3; соответствl= 0;е версии ПС данному профилю. Наиболее полная проверка соответствl= 0;я утвержденнl= 6;му профилю производитl= 9;я в процессе испытаний к = 86;мплекса программ. В акте по результатаl= 4; испытаний кроме всех характ = 77;ристик версии программноk= 5;о продукта до = 83;жно быть отражено соответствl= 0;е профилям стандартов = 74; той их части, которая непосредсm= 0;венно влияет на характерисm= 0;ики версии прог = 88;аммного продукта. Кроме того, должны быть обобщены и представлеl= 5;ы результаты применения утвержденнm= 9;х профилей ЖЦ ПС = 74; процессе создания данной версии комп = 83;екса программ.<o:p></o:p>= При сопровождеl= 5;ии п= ;рограммног = 86; продукта и создании ег = 86; новых верси = 81; накапливаеm= 0;ся опыт применениn= 3; каждого использовk= 2;нного профиля стандартоk= 4; ЖЦ, проявляютl= 9;я его некоторые недостатки = 80; появляются предложениn= 3; по модернизацl= 0;и. На этой стадии профиль продолжает выполнять регламентиl= 8;ующую функцию в качестве инструментk= 2; для управления конфигурацl= 0;ей системы. На этапе сопровождеl= 5;ия профиль пре = 74;ращается в документ, позволяющиl= 1; установить план текущи = 93; и долгосроч = 85;ых мероприятиl= 1; по развитию инфраструкm= 0;уры предприятиn= 3; и внедрению новых систе = 84;. Кроме того, в течен&#= 1080;е времени экспл= ;уатации созданной версии прог = 88;аммного продукта возможно появление новых стандартов де-юре и де-факто, которые целесообраk= 9;но учест= ;ь в конкретноl= 4; профиле. Сопровождk= 7;ние и смена верс= 080;й ПС может привести к необходимоl= 9;ти корректироk= 4;ки и модернизацl= 0;и конкретногl= 6; профиля ЖЦ с= 080;стемы. Такая модернизаm= 4;ия профиля может отразиться не только на вновь создаваемыm= 3; версиях ПС, но потребоватn= 0; доработок уже эксплуа = 90;ируемых версий.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Жизн&= #1077;нный цикл профил= 03; стандартов ПС при его сопровождеl= 5;ии, может в некоторой степени повторять ЖЦ системы и/или ПС, созд&= #1072;нных с его применениеl= 4;. Для этого следует разработатn= 0; или выбрать = 080; утвердить Руководст = 74;о по сопровождеl= 5;ию, разви= ;тию и модификациl= 0; профиля ЖЦ П= 057;, а также методики и плаl= 5; управления конфигурацl= 0;ями версий профиля, включающие:<o:p= ></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>пра= вила и процедуры идентификаm= 4;ии компонентl= 6;в и версий профиля ста = 85;дартов;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>мет= одики сбора, накопления = 80; обработки с = 86;общений о предлагае = 84;ых изменениях профиля;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>мет= одики корректироk= 4;ки и извещения пользоватеl= 3;ей о выполненнm= 9;х измен= ;ениях в профиле, влияющих н = 72; характерисm= 0;ики качества программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>мет= одики и руководствk= 2; по поддержк = 77; сохранностl= 0; и адекватно = 89;ти документацl= 0;и и средств, реализующl= 0;х требования = 80; рекомендацl= 0;и профиля;<o:p></o:p> <![if !supportLists]>- &nb= sp; = <![endif]>рук= оводство по вводу= очередной версии профиля стандартов ЖЦ ПС.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При примеl= 5;ении профилей следует обеспечить </sp= an>проверку к= 086;рректности их использо = 74;ания путем тестированl= 0;я, испыт= ;аний и сертифика = 94;ии для чего должна быть создана &#= 1090;ехнология контр= оля и тестированl= 0;я в процессе применения профиля специалистk= 2;ми. Она должна быть поддер = 78;ана совокупносm= 0;ью методик, инструменm= 0;альных средств, сос= 090;авом и содержаниеl= 4; оформляемыm= 3; документов на каждом этапе обеспечениn= 3; и контроля корректносm= 0;и применения соответствm= 1;ющей версии и по= 083;ожений профиля. Профи= ;ли должны опре = 76;еляться таким образом, чтобы тестированl= 0;е их реализации можно было осуществлn= 3;ть по возможно = 89;ти наиболее полно, по стандартизl= 0;рованной методике. При сертификацl= 0;и сложных систем как специальныl= 1; вид иl= 9;пытаний &#= 1094;елесообраз= но выделять сертификацl= 0;ю на соответствl= 0;е профилям: <o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>процесl= 9;ов жизненного цикла системы и основных компонентоk= 4; ПС и БД;<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>продукm= 0;ов и компонентоk= 4; системы, подготовлk= 7;нных и рекоменду = 77;мых для эксплуа = 90;ации и сопровождеl= 5;ия.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> В ряде случаев, производитl= 9;я &#= 1087;еренос разработанl= 5;ого программноk= 5;о продукта с инструментk= 2;льной платформы разработчиl= 2;а системы на реальную – целевую платформу = 87;рименения ПС. При этом проверяетсn= 3; соответствl= 0;е реальной платформы т = 88;ебованиям функционалn= 0;ных профилей си = 89;темы и функциониl= 8;ование ПС на реальн= 086;й платформе. Этап внедрения предполагаk= 7;т адаптацию и настройку программноk= 5;о продукта на реальные условия эксплуатацl= 0;и, для которых он создавался. Прием= ;очные испытания П = 57; должны проводитьсn= 3; в условиях реальной эксплуатацl= 0;и на соответствl= 0;е спецификацl= 0;ям функционалn= 0;ных требований и требованиn= 3;м полного профиля ПС, который бы = 83; сформироваl= 5; в процессе создания системы.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Последующk= 2;я деталиk= 9;ация требований и полож= ;ений профи= ;лей должна<s= pan style=3D'mso-spacerun:yes'> прово= ;диться с ориентациеl= 1; на унификац = 80;ю конкретных процессов, работ и документов версий программноk= 5;о продукта определеннl= 6;го функционалn= 0;ного назначения. Можно выделить следующие основные группы специалистl= 6;в, </sp= an>использую = 97;ие документы профилей: <o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>рук= оводители – менеджеры крупного проекта системы и е= 105; основных, функционалn= 0;ных компо= ;нентов программноk= 5;о продукта;<o:p></o:p>= <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>мен= еджеры – системные аналитики, создатели спецификацl= 0;й требований, = 087;илотных проектов компонентоk= 4; и алгоритмо = 74; решения функционалn= 0;ных задач;<o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>про= граммисты-р = 72;зработчики программныm= 3; компоненто&#= 1074;, структур и содержания данных;<o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>инт= еграторы функционалn= 0;ных программныm= 3; компонентоk= 4;, тестирующиk= 7; и отлаж= ;ивающие крупные функционалn= 0;ные компоненты, или ПС в цело&#= 1084;;<o:p></o:p> <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>спе= циалисты сопровождеl= 5;ия и управлени= 03; конфигурац&= #1080;ей версий прог = 88;аммных продуктов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; = <![endif]>исп= ытатели и сертиф = 80;каторы программныm= 3; продуктов;<o:p></o:p>= <![if !supportLists]><= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'>-&nb= sp; = <![endif]>раз= работчики технологии, инструментk= 2;льных средств, методическl= 0;х, руков= ;одящих и инструктивl= 5;ых документов, обеспечиваn= 2;щих реализацию профилей стандартов ЖЦ ПС.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Для деятельносm= 0;и перечисленl= 5;ых выше категорий специалистl= 6;в, на базе профи= ;лей должен быть создан &#= 1082;омплект документов</spa= n>, каждый из которых имеет конкретных пользоватеl= 3;ей в жизненном цикле ПС. В них = 76;олжно быть отражено:<o:p></o:p>= <![if !sup= portLists]>-&nb= sp; <![endif]>сод= ержание и описание выбранных положений = 80; разделов ст = 72;ндартов и норl= 4;ативных документов профиля с позиции его = 082;онкретного пользоватеl= 3;я;<o:p></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>пар= аметры адаптации разделов стандартов профиля и содержание = 76;ополнитель&#= 1085;ых нормативныm= 3; документов;<o:p= ></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>мет= одика и сценарии корректногl= 6; применения всех обязательнm= 9;х и рекоменду = 77;мых положений профиля стандартов;<o:p= ></o:p> <![if !sup= portLists]>-&nb= sp; <![endif]>тре= бования к содержани= 02; отчетов о результатаm= 3; контроля и тесm= 0;ирования компо= ;нентов системы на соответствl= 0;е обязательнm= 9;м положениям профиля стандартов = 74; процессе их жизненного цикла. <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102452"></a><a name=3D"_Toc508102225">2.3. Модель профиля стандартов жизне= ;нного цикла = &nb= sp; = &nb= sp; сложных пр = 86;граммных средств</a></h1> <o:p> </o:p> Комплекснl= 6;е, скоординирl= 6;ванное применение = 87;рофилей стандартов = 80; средств k= 4; процессе создания, развития и применения ПС позволяе = 90; исключать многие виды дефектов ил = 80; значительнl= 6; ослаблять и = 93; влияние. Тем самым уровень достигаемоk= 5;о качества ПС с = 90;ановится предсказуеl= 4;ым и управляемыl= 4;, непосредстk= 4;енно зависящим о = 90; ресурсов, выделяемых на его достижение, = 072; главное, от системы кач = 77;ства и эффективноl= 9;ти технологии, = 080;спользуемы&= #1093; на всех этапах жизненного цикла ПС. <o:p></o:p> </spa= n>Процесс= ;ы жизненного цикла ПС основаны на = 076;вух исходных пр = 80;нципах: моду = 83;ьности и ответственl= 5;ости. Процессы являются модульными = 74; том смысле, что они: строго связаны и вз= 072;имоувязаны; свободно соединены. Число интерфейсоk= 4; между проце = 89;сами сведено к ми= 085;имуму. В принципе каждый процесс предназначk= 7;н для реализа = 94;ии уникальной функции в жизненном цикле и може= 090; привлекать другой процесс для = 074;ыполнения специализиl= 8;ованной функции. Для обозначениn= 3;, определениn= 3; области применения = 80; структурирl= 6;вания процессов используютl= 9;я правила:<o:p></o:p> <![if !supportLists= ]>- &nb= sp; = <![endif]>п = 88;оцесс должен быть модульным, т. е. один процесс должен выполнять о = 76;ну и только одн= 091; функцию в жизненном цикле, а интерфейсы между двумя любыми проц = 77;ссами должны быть минимизироk= 4;аны;<o:p></o:p> <![if !supportLists= ]>- &nb= sp; = <![endif]>е = 89;ли функция вызвана более чем одним проце = 89;сом, тогда функция сам = 72; становится процессом;<o:p></o:p>= <![if !supportLists= ]>- &nb= sp; = <![endif]>д = 86;лжна быть возможностn= 0; верификациl= 0; любой функции в модели жизн = 77;нного цикла ПС;<o:p></o:p> <![if !supportLists]>-&nb= sp; = &nb= sp; <![endif]>к = 72;ждый процесс должен имет= 00; внутреннюю = 89;труктуру, установленl= 5;ую в соответст = 74;ии с тем, что должно им быть выполн = 77;но.<o:p></o:p> Когда организациn= 3; в целом (или ее часть) заключает договор на программныl= 1; продукт, то она становится сm= 0;ороной. Организацl= 0;я имеет самостоятеl= 3;ьные подразделеl= 5;ия, а стороны могут быть и= 079; одной или ра= 079;ных организациl= 1;. Каждый процесс должен быть рассмотрен = 89; точки зрени= 03; оm= 0;ветственно= 089;ти (обязанност = 77;й) стороны. Организациn= 3; может выпол = 85;ять один или несколько процессов. Сторона, выполняющаn= 3; процесс, несет ответ = 89;твенность за весь данный процесс, даж= 077; если выполнение отдельных задач поручено др = 91;гим людям. Принцип ответственl= 5;ости в архитекту = 88;е и процессах жизненного цикла облег = 95;ает применение профилей стандартов для конкретногl= 6; проекта, в ко&#= 1090;орый может быть вовлечено множество л = 80;ц. <o:p></o:p> <sp= an style=3D'font-size:14.0pt'> Общая структура и состав профиля ста = 85;дартов жизненного цикла системы и крупного программноk= 5;о средства дл= 03; управления проектом представлеl= 5;ы на рис. 2.3.= На этом рисунке выделены и о= 090;ражена группа базовых стандартов управления проектами с = 80;стем и основными процессами сложных программныm= 3; средств, а также переч = 77;нь совокупносm= 0;и стандартов детализируn= 2;щих и поддерживаn= 2;щих процессы их жизненного цикла. Выделенные = 73;азовые стандарты образуют иерархичесl= 2;ую группу и тесно связа = 85;ы между собой концепциямl= 0;, требованияl= 4;и, процессам и ссылками. Основу профилей управления проектами составляют две группы: стандарты менеджментk= 2; качества процессов жизненного цикла систе = 84; –</spa= n> <= /span>CMMI= :2003 и менеджме = 85;та (администра = 90;ивного управления) системой качества (требования) </= span>–</spa= n> ISO 9= 001:2000. Так как эти стандарты имеют много общего и трудно выделить их преимущестk= 4;а, то при реальной разработке крупных проектов целесообраk= 9;но уделять приоритет о = 76;ной из групп в зависимостl= 0; от особенностk= 7;й конкретногl= 6; проекта и предшествоk= 4;авшего опыта специ = 72;листов предприятиn= 3;. <o:p></o:p> Некоторым преимущестk= 4;ом применения стандарта ISO 9001 для управления проектами П = 57;, является ег = 86; развитие и детализациn= 3; требований = 74; специальноl= 4; руководствk= 7; ISO 90003:2004 для программныm= 3; средств. В этом руководствk= 7; цитируются каждое треб = 86;вание ISO 9001, онl= 6; комментируk= 7;тся и снабжаетс= 03; особенностn= 3;ми реализации процессов управления для конкретных проектов программныm= 3; средств. Кроме того, при описани = 80; ряда процессов управления проектом дл= 03; их уточнени= 03; и конкретиз = 72;ции делаются ссылки на основные стандарты, регламентиl= 8;ующие жизненный цикл ПС: ISO 12207, ISO 15504, ISO 9126, а k= 4; приложении = 87;роводится сопоставлеl= 5;ие требований этого стандарта с = процессаl= 4; управления = 80; с рекомендацl= 0;ями стандарта ISO 12207.<= span style=3D'mso-spacerun:yes'> <o:p></o:p> Часто создание профилей стандартов крупных программныm= 3; проектов на = 95;инается с определениn= 3; жизненного цикла систе = 84;ы, процессы которого регламентиl= 8;уются стандартом ISO 15288:2002. Пол&#= 1086;жения этого стандарта коррелир = 86;ванны с рекомендацl= 0;ями стандарта ISO 12207, которые детализируn= 2;тся в стандарте ISO 15504:1-9:1998 и в послед&#= 1091;ющей большой группе стан = 76;артов (см. рис. 2.3). <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Профиль жизненного цикла= ; ПС и Б = 44; целесообраk= 9;но определять на основе подмножестk= 4;а процессов, работ и задач стандарта ISO 12207, </span= > выбир= ая их с учетом характерисm= 0;ик проекта конкретной системы. Воз= 084;ожно, что к выбранному подмножестk= 4;у потребуетсn= 3; добавление = 76;ополнитель&#= 1085;ых процессов, работ, задач и нормативн = 99;х документов, = 089;вязанных со спецификой данной системы. Это рекомендуеm= 0;ся в новых Прил= 086;жениях 1 и 2 к этому стандарту, а также в ряде руководств детализируn= 2;щих основные процессы ст = 72;ндарта ISO 12207. Ряд работ, особенно на наиболее творческиm= 3; этапах созда= ;ния прогр= ;аммного средства, не регламентиl= 8;уется стандартамl= 0;. Это не позволя= 077;т разрабатывk= 2;ть и применять профили ЖЦ ПС, основанны = 77; только на базе стандартоk= 4;. Иногда цел = 77;сообразно дополнитеl= 3;ьно регламентиl= 8;овать такие работ = 99; нормативныl= 4;и документамl= 0; и специфика = 94;иями разработчиl= 2;ов проекта систе= ;мы или ведомст = 74;енными нормативныl= 4;и документамl= 0;. <o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = 42; стандарте ISO 12207 и= Приложенияm= 3; 1 и 2 к этому стандарту, изложены основы преобразовk= 2;ния и адаптации базовой стр = 91;ктуры процессов ЖЦ для профил= 03; конкретногl= 6; проек= ;та ПС и БД. В них даны общие рекомендацl= 0;и по адаптаци = 80; процессов ЖЦ, а также конкр = 77;тные рекомендацl= 0;и по возможны = 84; изменениям ряда работ и результируn= 2;щих документов = 74; зависимостl= 0; от характерисm= 0;ик конкретногl= 6; объекта и процесса ег = 86; разработки. В связи с возрастающk= 7;й ролью качества сложных ПС, целес= ;ообразно выделять пр = 86;филь обеспечениn= 3; качества ПС и Б = 44; конкретноl= 1; системы, регламентl= 0;рующий требования = 82; качеству и меры по его обеспечениn= 2;.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Модель профиля стандартов = 78;изненного цикла сложных про = 75;раммных средств обычно формируетсn= 3; из 10 –12 базовыm= 3; стандартов. Их количество зависит от целей, сложн= 086;сти и особенностk= 7;й проекта, от назначения и области применения модели, а также от возможностk= 7;й формализацl= 0;и её компонентоk= 4;. Для последующеk= 5;о изложения п = 88;ограммной инженерии при их выбор= 077; и формированl= 0;и модели проф = 80;ля стандартов учитывалосn= 0; наличие международl= 5;ых стандартов (Приложение 1), которые мог = 91;т использоваm= 0;ься при определ = 77;нии жизненного цикла ПС и объединениl= 0; их в профиль, пригодный для последующеk= 5;о использоваl= 5;ия в технологи = 80; создания и развития кр = 91;пного проекта. Поэтому ряд не стандарт = 80;зированных – творчески = 93; процессов явно не отражен в рассматривk= 2;емой модели, однако они существеннm= 9; для реально = 75;о жизненного цикла ПС. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> Сформировk= 2;нный и используе = 84;ый далее в лекциях профиль жизненного цикла ПС состоит из трех групп стандартов R= 11; рис. 2.4:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>г = 88;уппы стандартов управления жизненным ц = 80;клом сложных проектов систем и программныm= 3; средств, возглавляеl= 4;ой стандартамl= 0; менеджмент&#= 1072; – CMMI и ISO 9000;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>группы стандартов проектировk= 2;ния, разработки, = 089;опровожден&= #1080;я и управлени= 03; конфигурацl= 0;ей, регламентиl= 8;уемой базовыми стандартамl= 0; жизненногl= 6; цикла систе = 84; и программн = 99;х средств – ISO 15288 и ISO 12207;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>групп&= #1099; стандартов оценивания = 80; обеспечениn= 3; качества, бе= 079;опасности и документи = 88;ования в жизненном цикле программныm= 3; средств, с головными стандартамl= 0; – ISO 9126 и = ISO 25000. <o= :p></o:p> Каждая выделенная группа проф = 80;ля стандартов жизненногl= 6; цикла (см. рис. 2.4) детализирl= 6;вана набором ста = 85;дартов, которые представлеl= 5;ы в Приложени = 80; 1. Эта схема далее рассматривk= 2;ется как базовая = 074; программноl= 1; инженерии, подлежащая конкретизаm= 4;ии и адаптации = 074; проектах в соответствl= 0;и с особеннос = 90;ями развития профиля жизненного цикла прогр = 72;ммного средства (см. рис. 2.2). Большинствl= 6; представлеl= 5;ных стандартов = 80;зложено достаточно детально дл= 03; практическl= 6;го применения = 74; последующиm= 3; лекциях. <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102453"></a><a name=3D"_Toc508102226">Лекция 3. Модели и процессы управления проектами программныm= 3; средств</a><= span class=3DIieoeiue><o:p><= /o:p></h1> <= span style=3D'font-size:14.0pt;font-weight:normal;mso-bidi-font-weight:bold'><o:= p> </o:p> <h1><a name=3D"_Toc508102454"></a><a name=3D"_Toc508102227">3.1. Управление проектами программнm= 9;х средств в системе </a>= – С</span= >MMI<o:p><= /o:p></h1> <o:p>&= nbsp;</o:p> Наз= начение методологиl= 0; СММ/= CMMI – системы и модели оценки зрелости – состоит в предоставлk= 7;нии необходимыm= 3; общих реком = 77;ндаций и инструкци = 81; предприятиn= 3;м, производящl= 0;м ПС, по выбору стратегии совершенстk= 4;ования качества процессов и продуктов, путем анализа степени их производсm= 0;венной зрелости и оценивания факторов, в наибольшей степени влияющих на качество ЖЦ ПС, а также посредствоl= 4; выделения п = 88;оцессов, требующих модернизацl= 0;и. Для достижения устойчивых результатоk= 4; программноl= 1; инженерии в процессе развития технологиl= 0; и организациl= 0; управления жизненным циклом ПС в стандарте ISO 15504:1-9 рек = 86;мендуется использоваm= 0;ь эволюционнm= 9;й путь, которы= 081; позволяет совершенстk= 4;овать и постепенн = 86; повышать качество процессов и продуктов, в= 089;крывать преимущесm= 0;ва и недостатк = 80; предприятиn= 3;. В методолог = 80;и СММ выделены пять уровне = 81; зрелости, раскрываеl= 4;ые в этом стандарте де-факто (рис.3= .1). Виды деятельносm= 0;и для высоких = 091;ровней зрелости в соответствl= 0;и с СММ, в стандарте делятся l= 5;а базовые и общие. Базов= 099;е виды деятельносm= 0;и являются обязательнm= 9;ми и сгруппировk= 2;ны в пять катег= 086;рий: к= ;онтрактная; инженерная; управленчk= 7;ская; вспомогатеl= 3;ьная; организациl= 6;нная. Уровни зрелости характеризm= 1;ются степенью формализацl= 0;и, адекватносm= 0;ью измерения и документирl= 6;вания процессов и продуктов Ж = 62; ПС, широтой применения стандартов = 80; инструментk= 2;льных средств автоматизаm= 4;ии работ, налич= 080;ем и полнотой реализации функций системой обеспечениn= 3; качества технологичk= 7;ских процессов и их результа = 90;ов. <o:p></o:p> Описk= 2;ние процессов ЖЦ ПС в СММ сфокус= 080;ровано на поэтапно = 84; определениl= 0;, реально достигаемыm= 3; результатоk= 4; и на оценивании качества их выполнения. Качество п = 88;оцессов зависит от технологичk= 7;ской среды, в которой они выполняютсn= 3;. Зрелость процессов = - это степень их управляемоl= 9;ти, возможностn= 0; поэтапной количествеl= 5;ной оценки каче = 89;тва, контролируk= 7;мости и эффективноl= 9;ти результатоk= 4; (см. рис. 3.1). Модель зрелости предприятиn= 3; представляk= 7;т собой метод = 80;ческий нормативныl= 1; материал, определяющl= 0;й правила создания и функционирl= 6;вания системы управления жизненным циклом ПС, методы и стандарты систематичk= 7;ского повышения культуры и качества производстk= 4;а. Рост зрелос = 90;и обеспечиваk= 7;т потенциальl= 5;ую возможностn= 0; возрастаниn= 3; эффективноl= 9;ти и согласова = 85;ности использоваl= 5;ия процессов создания, со= 087;ровождения и оценивани= 03; качества ко = 84;понентов и ПС в целом. Реальное использоваl= 5;ие регламентиl= 8;ованных процессов предполагаk= 7;т поэтапный контроль и документирl= 6;вание их характер = 80;стик качества. На предприятиn= 3;х, достигших высокого уровня зрел = 86;сти, формализовk= 2;нные процессы ЖЦ ПС должны принимать с = 90;атус стандарта, фиксироватn= 0;ся в организациl= 6;нных структурах = 80; определять производстk= 4;енную тактику и стратегию корпоративl= 5;ой культуры производстk= 4;а и системы обеспечениn= 3; качества ПС. <o= :p></o:p> У= 088;овень 1 - Начальный. Массовые разработки проектов ПС характеризm= 1;ются относительl= 5;о небольшими размерами программ в несколько т = 99;сяч строк, созда= 074;аемых несколькимl= 0; специалистk= 2;ми. Они применяют п = 88;остейшие не формализовk= 2;нные технологии = 89; использова&= #1085;ием типовых инс = 90;рументальн&#= 1099;х компонентоk= 4; операционнm= 9;х систем. Осно= 074;ные процессы ЖЦ ПС на этом уровне не регламентиl= 8;ованы, выполняютсn= 3; не совсем уп= 086;рядоченно и зависят от не координи = 88;ованных индивидуалn= 0;ных усилий и свойств отд = 77;льных специалистl= 6;в. Успех проекта, как правило, зависит от энергичносm= 0;и, таланта и опыта нескольких руководитеl= 3;ей и исполнителk= 7;й. Процессы на первом уровне характеризm= 1;ются своей непре = 76;сказуемост&#= 1100;ю по трудоемкосm= 0;и и срокам в св&#= 1103;зи с тем, что их состав, назначение = 80; последоватk= 7;льность выполнения могут менят= 00;ся случайным образом в за= 074;исимости от текущей ситуации. <o:p></o:p></span= > = Уровень 2 = - Управляемыl= 1; – базовое управление. Для сложных про = 77;ктов ПС объемом в десятки и сотни тысяч = 089;трок, в которых участвуют десятки специалистl= 6;в разной квалификацl= 0;и, необходимы организациn= 3;, регламентиl= 8;ование технологии = 80; унификация процессов деятельносm= 0;и каждого из них. Процесс= 099; на этом уровне заранее планируютсn= 3;, их выполнен = 80;е контролируk= 7;тся, чем достигаетсn= 3; предсказуеl= 4;ость результатоk= 4; и времени выполнения этапов, компонентоk= 4; и проекта в целом. Основной ос = 86;бенностью второго уровня является наличие формализовk= 2;нных и документи = 88;ованных процессов управления проектами, которые пригодны дл= 03; модернизацl= 0;и, а их результ= 072;ты, поддаются количествеl= 5;ной оценке. На этом уровне акценты упр = 72;вления сосредоточl= 0;ваются на предвари = 90;ельном упорядоченl= 0;и и регламентиl= 8;овании процессов создания, сопровождеl= 5;ия и оценивани= 03; качества программноk= 5;о средства, од= 085;ако для крупных проектов ПС = 089; гарантировk= 2;нным качеством, риск провал = 72; может оставаться еще достаточно большим.<o:p></o:p> = Уровень 3 <span style=3D'mso-bidi-font-size:14.0pt;font-family:Symbol;mso-ascii-font-family= :"Times New Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-weight:bold'>- Определеннm= 9;й – стандартизk= 2;ция процессов. При высоки = 93; требованияm= 3; заказчика и пользоватеl= 3;ей к конкретны = 84; характерисm= 0;икам качества сложного ПС = 080; к выполнени= 02; ограничениl= 1; по использо = 74;анию ресурсов, необходимо дальнейшее совершенстk= 4;ование и повышение уровня зрелости процессов Ж = 62; ПС. Процессы ЖЦ ПС на этом уровне долж = 85;ы быть стандартизl= 0;рованы, и представляm= 0;ь собой целос = 90;ную технологичk= 7;скую систему, обязательнm= 1;ю для всех подразделеl= 5;ий. На основе единой технологии поддержки и обеспечениn= 3; качества ЖЦ ПС, для каждо&#= 1075;о проекта могут разрабатывk= 2;ться дополнителn= 0;ные процессы последоватk= 7;льного оценивания качества продуктов с учетом их особенностk= 7;й. Описание каждого процесса должно включать ус = 83;овия его выполнения, входные данные, рекомендацl= 0;и стандартов = 80; процедуры выполнения, механизмы проверки качества результатоk= 4;, выходные данные, усло= 074;ия и документы завершения процессов. В описания процессов включаются сведения об = 080;нструмента&= #1083;ьных средствах, необходимыm= 3; для их выполнения, роль, ответственl= 5;ость и квалифика = 94;ия специалистl= 6;в. <o:p></o:p> = Уроk= 4;ень 4 <span style=3D'mso-bidi-font-size:14.0pt;font-family:Symbol; mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times New Ro= man"; mso-char-type:symbol;mso-symbol-font-family:Symbol;mso-bidi-font-weight:bol= d'>-</span= > Предсказуеl= 4;ый – количествеl= 5;ное управление</spa= n>. Для реализации проектов крупных, особенно сложных ПС, в жестко огра = 85;иченные сроки и с высоким гар = 72;нтированны&#= 1084; качеством, необходимы = 72;ктивные меры для предотвращk= 7;ния и выявления = 076;ефектов и ошибок на всех этапах ЖЦ ПС. Управл&#= 1077;ние должно обеспечиваm= 0;ь выполнение процессов в соответствl= 0;и с текущими требованияl= 4;и к характерисm= 0;икам качества ко = 84;понентов и ПС в целом. На этом уровне, должна прим = 77;няться система дет = 72;льного поэтапного оценивания характерисm= 0;ик качества, ка= 082; технологичk= 7;ских процессов Ж = 62;, так и самого создаваемоk= 5;о программноk= 5;о продукта и его компонентоk= 4;. Должны разрабатывk= 2;ться и применять = 89;я методики ко = 83;ичественно&#= 1081; оценки реализации процессов и их качества. Одновременl= 5;о с повышение = 84; сложности и требований = 82; качеству ПС, следует совершенстk= 4;овать управление проектами з = 72; счет сокращения текущих кор = 88;ектировок и исправлениl= 1; дефектов пр = 80; выполнении процессов. Результаты процессов становятся предсказуеl= 4;ыми по срокам и качеству в связи с тем, что они измеряются = 74; ходе их выполнения = 80; реализуютсn= 3; в рамках заданных ресурсных ограничениl= 1;. <o:p></o:p> = Уровень 5 = - Оптимизациl= 6;нный – непрерывноk= 7; совершенстk= 4;ование и улучшение. Дальнейшее последоватk= 7;льное совершенстk= 4;ование и модернизацl= 0;я технологичk= 7;ских процессов Ж = 62; ПС для повышения качества их выполнения = 80; расширение глубины l= 2;онтроля за их реализациеl= 1;. Одна из основных целей этого уровня -</span= > сокращение проявлений = 80; потерь от случайных дефектов и ошибок путе = 84; выявления сильных и слабых стор = 86;н используемm= 9;х процессов. При этом при= 086;ритетным является анализ рисков, дефектов и о= 090;клонений от заданных требований заказчика. Эти данные также используютl= 9;я для снижени= 03; себестоимоl= 9;ти ЖЦ особо сло= 078;ных ПС в результате внедрения новых техно = 83;огий и инструментk= 2;рия, а также для планированl= 0;я и осуществлеl= 5;ия модернизацl= 0;и всех видов п= 088;оцессов. Технологичk= 7;ские нововведенl= 0;я, которые мог = 91;т принести наибольшую выгоду, должны стандартизl= 0;роваться и адаптиров = 72;ться в комплексн = 91;ю технологию обеспеченl= 0;я и оценивани= 03; системы качества предприятиn= 3; и его продук= 094;ии. <o:p></o:p> В 2003 годm= 1; американскl= 0;й Институт программноl= 1; инженерии (</s= pan>SE= I) опубликовk= 2;л новую комплекснуn= 2; модель CMMI, уточняющу= 02; и совершенс = 90;вующую предшествоk= 4;авшие модели CMM, а также частично уч = 80;тывающую основные требования существующl= 0;х международl= 5;ых стандартов = 74; области менеджментk= 2; программныm= 3; средств. Внедр= ение этой модели акцентировk= 2;но на улучшени = 80; процессов управления проектами П = 57;, обеспечениl= 0; их высокого качества и конкурентоl= 9;пособности, с основной ц= 077;лью – сделать процессы проектов управляемыl= 4;и, а результат = 99; – предсказу = 77;мыми. Значительнl= 6;е внимание в <sp= an lang=3DEN-US style=3D'mso-bidi-font-size:14.0pt;mso-ansi-language:EN-US;mso= -bidi-font-weight: bold'>CMMI уделяется процессам разработки = 80; учету итераций пр = 80; изменении требований заказчиков, их прослеживаl= 5;ию к функциям, компонентаl= 4;, тестам и док= 091;ментам проекта. Кон= 094;епцию, определяющm= 1;ю функционалn= 0;ную пригодностn= 0; и качk= 7;ство продукта, рекомендуеm= 0;ся сопровождаm= 0;ь проверками возможных сценариев событий при его примене = 85;ии. <o:p></o:p> В последне = 77; время появилась информация о модернизаm= 4;ии американскl= 0;м Институтом программноl= 1; инженерии SEI<= span style=3D'font-size:14.0pt'> версии </sp= an>= CMMI-SE/SW/IPPD, V1.1 на основе накопленноk= 5;о опыта и отзывов предприятиl= 1;. Предполагаk= 7;тся выпустить в 2006 году новую, с&#= 1091;щественно модернизирl= 6;ванную, версию модели CMMI-V1.2, после чего постепенно должно прек = 88;атиться применение версии 1.1. До конца 2007 года должен проводитьсn= 3; переход пользоватеl= 3;ей на версию CMMI-V1.2, а k= 4; дальнейшем она станет обязательнl= 6;й для формали = 79;ованной оценки качества (сертификац = 80;и) технологии предприятиl= 1; в области пр= 086;граммной инженерии. При этом сро= 082; действия сертификатk= 2; будет ограничен тремя годам = 80;. К этим измен= 077;ниям следует готовиться после офици = 72;льной публикации </sp= an>Институ= ;том SEI версии 1.2.= <o:p></o:p> = Два варианта модели CMMI – 1.1&nb= sp; созданы дл= 03; обеспечениn= 3; непрерывноk= 5;о оценивания комплекса процессов в = 086;пределенно&= #1081; области создания пр = 86;граммных средств или для поэтапного оценивания = 80; совершенстk= 4;ования зрелости предприятиn= 3;, а также для организациl= 0; ЖЦ комплекс = 86;в программ в целом. Модел= 080; CMMI представляn= 2;т помощь спец = 80;алистам при организациl= 0; технологии = 80; совершенстk= 4;овании их продукто = 74;, а также для упорядоченl= 0;я и обслуживанl= 0;я процессов разработки = 80; сопровождеl= 5;ия ПС. Концепци= 103; этих моделе = 81; покрывает управление = 80; оценивание зрелости сложных систем, инжен= ;ерии программныm= 3; средств, а также проце = 89;сов c</span= >оздания<= /span> интегрировk= 2;нных программныm= 3; продуктов и совершенстk= 4;ования их разработки. Компоненты = 85;епрерывной и поэтапной <sp= an style=3D'mso-spacerun:yes'> модел= ей в значитель = 85;ой степени подобны, могут выбираться = 80; применятьсn= 3; в разном составе и последоватk= 7;льности использоваl= 5;ия в зависимостl= 0; от свойств и характерисm= 0;ик конкретных проектов. <o:p></o:p> Варl= 0;анты описания моделей построены п = 86; единой схем = 77;, которая содержит общие разделы:<o:p></o:p>= предислов= 080;е;<o:p></o:p> 1. введение;<o:p></o:p>= 2. модель компонентоk= 4;;<o:p></o:p> 3. терминологl= 0;я;<o:p></o:p> 4. содержание уровней и главные компоненты = 82;аждого варианта мо = 76;ели (разработка целей и процедур);<o:p></o:p></span= > 5 разде= 083; – структура взаимодейсm= 0;вия процессов. Аннотироваl= 5;ы четыре кате = 75;ории процессов раздела 7, их общий обзор = 080; схемы взаимодейсm= 0;вия CMMI процессов: </spa= n><o:p></o:p> * менеджмент процессов; <sp= an style=3D'font-size:14.0pt'><o:p></o:p> * менеджмент R= 11; управление проектом; <o:p></o:p> * инжиниринг (технология); <= /span><o:p></o:p> * поддержка;<o:p></o:p>= 6 раздел – использоваl= 5;ие модели CMMI – краткие рекомендацl= 0;и для пользов = 72;телей по применению модели и обучению; отмечается совмеl= 9;-тимость и соответст = 74;ие процессов модели, с регламентиl= 8;ованными процессами предыдущей модели CMM в части 2 и 3 стандарта = ISO 15504.<o:p></o:p></s= pan> Последний, седьмой раздел самы = 81; большой в каждом стан = 76;арте, он занимает около 500 страниц из полного объ = 77;ма документа, который сос = 90;авляет свыше 700 страниц. В этом раздел = 77; представлеl= 5;ы подробные р = 77;комендации для реализации каждого из перечисленl= 5;ых в нем множества процессов, которые учи = 90;ывают особенностl= 0; конкретной = 84;одели. <o:p></o:p> = Пk= 7;рвый вариант (непрерывно = 81;) модели отражает документ: Capability Maturity<sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Gothic"; mso-fareast-language:JA;mso-bidi-font-weight:bold;mso-bidi-font-style:itali= c'> Model Integration= (CMMI) for Systems Engineering / Software Engineering= / Integrated Product and Process Development, Version 1.1, Continuous Representation</sp= an> (CMMI-SE/SW/IPPD, V1.1, Continuous) – Интегрировk= 2;нная модель оценивания зрелости ин = 78;енерии систем / прог&#= 1088;аммной инженерии / интегрировk= 2;нных продуктов и процессов разработки R= 11; непрерывноk= 7; представлk= 7;ние. В этой модели= седьмой раздел сост = 72;вляют процессы:<o:p></o:p>= <![if !supportLists]>- = ; <![endif]>менеджмен = 90; процессов:<o:p></o:p> * содержание организациl= 6;нных процессов;<o:p></o:p>= * определениk= 7; организациl= 6;нных процессов; &= nbsp; &nbs= p; &= nbsp; <o:p></o:p> * организациn= 3; обучения;<o:p></o:p>= * организациn= 3; преобразовk= 2;ния (изменений) п&#= 1088;оцессов;<o:p></o:p></= p> * организациn= 3; инноваций и расширений;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>управлени = 77; проектом:<o:p></o:p> * планированl= 0;е проекта; <o:p></o:p> * мониторинг и контроль процессов проекта;<o:p></o:p> * управление соглашенияl= 4;и с поставщикаl= 4;и;<o:p></o:p> * интегрировk= 2;нное управление процессами = 80; продуктами проекта;<o:p></o:p> * управление рисками;<o:p></o:p> * интеграция команды разработчиl= 2;ов;<o:p></o:p> * интегрировk= 2;нное управление поставщикаl= 4;и;<o:p></o:p> * количестве= ;нное управление проектом;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>инженерия</sp= an> (технология= ;):<o:p></o:p> * управление требованияl= 4;и;<o:p></o:p> * разработка требований;<o:p= ></o:p> * техническиk= 7; решения;<o:p></o:p> * интеграция продукта;<o:p></o:p>= * верификациn= 3;;<o:p></o:p> * валидац= ;ия (аттестация, утверждениk= 7;);<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>поддержка</sp= an>:<o:p></o:p> *управление конфигурацl= 0;ей;<o:p></o:p> * обеспечени= ;е качества процессов и продуктов;<o:p></o:p>= * измерение l= 0; анализ процессов и продуктов;<o:p></o:p>= * анализ и принятие решений на изменения;<o:p></o:p>= * организациn= 3; окружения для интеграции;<o:p= ></o:p> * анализ причин и разрешение проблем (устранение дефектов).<o:p></o:p></span= > В пяти приложенияm= 3; приводятся:<o:p= ></o:p> А – состав использоваl= 5;ных литературнm= 9;х источников = 80; документов, = 074; котором, одн= 072;ко, не упоминаютсn= 3; стандарты ISO; <o:p></o:p> В – сокращения;<o:p= ></o:p> С – глоссарий н = 72; основе терминологl= 0;и ISO, применяемоl= 1; только в чет= 099;рех стандартаm= 3; ISO= 9000, ISO 12207, ISO 15504:1-9, ISO 15288;<o:p></o:p> = D <= span style=3D'font-size:14.0pt'>– описания</span= > треб= 086;ваний и предложениl= 1; для формированl= 0;я компонентоk= 4; модели по уровням зрелости;<o:p></o:p>= Е – список участников разработки </sp= an>= CMMI – проекта. <o:p></o:p> В этой модели внимание акцентировk= 2;но на организациl= 6;нных процессах, н= 072; планированl= 0;и, управлении = 80; контроле процессов реализации проектов пр = 86;граммных средств, на разработке = 80; управлении требованияl= 4;и к программныl= 4; продуктам. Ниже представлеl= 5;ы примеры детализациl= 0; в CMMI нек= 086;торых из них. <o:p></o:p> Планироваl= 5;ие проекта в этой, также как и во второй модели вклю = 95;ает: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 94;енку возможного размера – масштаба пр = 86;граммного продукта;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>о = 94;енку сложности функций и характерисm= 0;ик проекта ПС;<o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>о = 87;ределение модели и этапов жизненного = 94;икла комплекса программ; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>т = 77;хнико-эконо&= #1084;ическое обоснованиk= 7; проекта – определениk= 7; стоимости, т= 088;удоемкости и длительносm= 0;и ЖЦ ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>р = 72;зработка поэтапного графика работ и бюдж= 077;та проекта;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>а = 85;ализ, идентификаm= 4;ия и оценка проектных р = 80;сков;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 83;анирование и управлени = 77; документирl= 6;ванием процессов и продуктов в ЖЦ проекта ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 83;анирование и распределеl= 5;ие техническиm= 3; и людских ресурсов по этапам ЖЦ ПС;<o= :p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 83;анирование обеспечениn= 3; знаний и квалификацl= 0;и коллектива специалистl= 6;в для реализации проекта;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;общение и анализ совокупносm= 0;и планов прое = 82;та ПС; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>с = 86;гласование работ и ресурсов по этапам ЖЦ разработчиl= 2;ом с заказчико = 84; проекта ПС;<o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>д = 86;кументиров&#= 1072;ние плана работ = 080; утверждениk= 7; его менедже = 88;ом разработчиl= 2;ов проекта. <o:p></o:p> Процессы разработки требований = 82; программноl= 4;у продукту ан = 72;логичны процессам в обеих модел= 03;х и включают: <o:p></o:= p> <![if !supportLists]>- = &nb= sp; <![endif]>в = 99;явление реальных потребностk= 7;й заказчика и пользоватеl= 3;ей к функциям и характерисm= 0;икам программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>р = 72;зработку и согласованl= 0;е между заказчиком = 80; разработчиl= 2;ом исходных, ба= 079;овых требований = 82; функциям программноk= 5;о продукта;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>о = 87;ределение доступных ресурсов и ограничениl= 1; проекта ком = 87;лекса программ;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>д = 77;композицию базовых исходных требований = 82; функциям ПС = 074; набор требо = 74;аний к компонентаl= 4; и тестам комплекса п = 88;ограмм;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>ф = 86;рмализацию требований = 82; интерфейсаl= 4; между компонентаl= 4;и, с операцион = 85;ой и внешней средой;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>р = 72;зработку концепции программноk= 5;о продукта и с= 094;енариев его использ = 86;вания;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>р = 72;зработку требований = 82; обобщенным характерисm= 0;икам функционалn= 0;ной пригодностl= 0; и использоваl= 5;ию функций программноk= 5;о продукта по назначению.<o:p= ></o:p> Управлениk= 7; требованияl= 4;и в обеих моделях включает:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>д = 86;стижение однозначноk= 5;о понимания требований = 82; проекту ПС заказчиком = 80; разработчиl= 2;ами;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 86;лучение заказчиком от разработчиl= 2;ов обязательсm= 0;в выполнить все его треб= 086;вания к программноl= 4;у продукту;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>с = 86;гласованно&#= 1077; между заказчиком = 80; разработчиl= 2;ом управление изменениямl= 0; требований = 82; проекту ПС;<o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;еспечение прослеживаl= 5;ия корректносm= 0;и изменений от общих требований = 82; проекту ПС д= 086; требований = 82; компонентаl= 4; и частным процессам;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>в = 99;явление и идентификаm= 4;ия несоответсm= 0;вий между процессами разработки проекта и требованияl= 4;и заказчика.<o:p></o:p>= Второй вариант CMMI преk= 6;ставлен документом: </s= pan>Capability Maturity<sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Gothic"; mso-fareast-language:JA;mso-bidi-font-weight:bold;mso-bidi-font-style:itali= c'> Model Integration= for Systems Engineering / Software Engineering= / Integrated Product and Process Development, Version 1.1, Staged Representation</sp= an> (CMMI-SE/SW/IPPD, V1.1, Staged) – Интегрировk= 2;нная модель оцен = 80;вания зрелости инженерии сложных систем / программноl= 1; инженерии / интегрировk= 2;нных продуктов и процессов разработки R= 11; поэтапное представлеl= 5;ие. Модел= ь базируется на сохранении концепции пяти уровне = 81; зрелости CMM<= span style=3D'font-size:14.0pt'>. Состав процессов практическl= 0; повторяет приведенныl= 1; выше для первого варианта модели, в несколько иной послед = 86;вательност&#= 1080; и с относите= 083;ьно небольшими дополненияl= 4;и. Первый уровень отличается значительнl= 6;й неопределеl= 5;ностью состава и со= 076;ержания процессов в различных относительl= 5;о простых проектах, поэто= ;му он в документе н = 77; описан и не комментируk= 7;тся. Поэтому при уточнении = 80; детализациl= 0; содержания процессов в поэтапном варианте = CMMI рекомендуеm= 0;ся ограничивk= 2;ться ч= ;етырьмя (2-й – 5-й) основными уровнями:<o:p></o:p>= <![if !supportLists]= >- = &nb= sp; <![endif]>второй уровень – формализуеm= 0; базовое управление проектами: <o:p></o:p= > * управление требованияl= 4;и; <o:p></o:p> * планированl= 0;е проекта; <o:p></o:p> * мониторинг = 80; контроль проекта;<o:p></o:p> * управление соглашенияl= 4;и с поставщикаl= 4;и;<o:p></o:p> * измерение и анализ процессов и продуктов; <o:p></o:p= > * обеспечениk= 7; качества процессов и продуктов; <o:p></o:p= > * управление конфигурацl= 0;ей;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>третий уровень – содержит стандартизk= 2;цию основных процессов: <o:p></o:p> * разработка требований; <o:p></o:p> * техническиk= 7; решения;<o:p></o:p> * интеграция продукта; <o:p></o:p></span= > * верификациn= 3;; <o:p></o:p> * в = 72;лидация (аттестация); <= o:p></o:p> * содержание организациl= 6;нных процессов;<o:p></o:p>= * определениk= 7; организациl= 6;нных процессов; <o:p></o:p= > * организациn= 3; обучения; <o:p></o:p></span= > * интегрировk= 2;нное управление процессами = 80; продуктами проекта; <o:p></o:p> * управление рисками;<o:p></o:p> * интеграция команды разработчиl= 2;ов;<o:p></o:p> * интегрировk= 2;нное управление поставщикаl= 4;и; <o:p></o:p> * анализ и разрешение проблем (устрk= 2;нение дефектов);<o:p></o:p></span= > * орга = 85;изация окружения для интеграции; <o:p></o:p> <![if !supportLists]= >- = &nb= sp; <![endif]>четвер= тый уровень – определяет количествеl= 5;ное управление: <o:= p></o:p> * организациn= 3; представлеl= 5;ия качества пр = 86;цессов; <o:p></o:p> * количествеl= 5;ное управление всем проект = 86;м и ресурсами;<o:= p></o:p> - пятый уровень – оптимизациl= 6;нный, непрерывнl= 6;е совершенстk= 4;ование: = &nb= sp; = &nb= sp; * организациn= 3;, инновации, количествеl= 5;ное управление процессами = 80; обеспечениk= 7;м ресурсами;<o:p></o:p>= </spa= n>* анализ причин дефектов, со= 074;ершенствов&= #1072;ние качества и управления процессами = 80; продуктами.<o:p= ></o:p> Прило= жения во втором варианте мо = 76;ели подобны по составу, приведенныl= 4; выше прилож = 77;ниям для первой модели. Рекомендуеm= 0;ся на каждом более высоком уровне зрел = 86;сти применять вl= 9;е процессы предыдущих нижних уровней. В обоих вариантах м = 86;дели каждый, выде= 083;енный выше базовы = 81; процесс, ком= 084;ентируется подробными рекомендацl= 0;ями для его практическl= 6;й реализации, которые содержат унифиц= 080;рованные по структур = 77; описания об = 98;емом около 20 – 30 стр= аниц: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>оk= 3;щие цели процесса, которые должны быть = 076;остигнуты; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>вk= 4;одные замечания и </s= pan>общее описание функций процесса; </span= ><o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>сl= 7;ецифически= 077; цели процесса; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>мk= 7;неджмент процесса;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>р = 72;зработка требований = 82; процессу; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>в = 79;аимодейств&#= 1080;е и интерфейс = 99; с другими пр= 086;цессами; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пl= 8;актические цели – требуемые результаты действий пр = 86;цесса; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пl= 3;анирование действий в определеннl= 6;м процессе; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>а = 85;ализ и валида = 94;ия (утверждени = 77;) результатоk= 4; реализации процесса; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>м = 86;ниторинг и контроль выполнения процесса.<o:p></o:p> Эт&#= 1080; рекомендацl= 0;и по объему, содержанию = 80; полноте описаний базовых процессов подобны ряд = 91; стандартов профиля ЖЦ ПС. Упорядоч= 077;ние и оценка полноты используемm= 9;х процессов в соответствl= 0;и с уровнями зрелости, позволяет устанавливk= 2;ть производстk= 4;енный потенциал предприятиl= 1; – разработч = 80;ков программныm= 3; продуктов п = 86; прогнозируk= 7;мому качеству процессов и результатоk= 4; их деятельн = 86;сти и готовност = 80; к сертифика = 94;ии на соответствl= 0;е определеннl= 6;му уровню зрелости модели CMMI – 1.1.&n= bsp; <o:p></o:p> Особое внимание в моделях CMMI уделяется процессам м = 77;неджмента проекта ПС. Эти требования = 80; процессы моделей практическl= 0; соотв= 077;тствуют, регламентl= 0;рованным и детализироk= 4;анным рекомендацl= 0;ям в стандарта = 93; ISO<= span style=3D'color:windowtext'> 9001:2000,&nbs= p; ISO 12207 и в осн = 86;вных компонентаm= 3; профи= 083;я стандартов жизненного цикла сложных ПС. Требованияl= 4; к процессам = 074; функционалn= 0;ных разделах 4 – 8 стандартов </sp= an>ISO<= span style=3D'color:windowtext'> 9001, ISO 9004, = ISO<= span style=3D'color:windowtext'> 90003 может быть сопоставлеl= 5; адекватный по содержанию = 88;яд разделов в модел= 103;х CMMI – рис. 3.2. Общность процессов и требований состоит в по= 076;обии: состава, терминологl= 0;и, структуры, перечня осн = 86;вных рекомендуеl= 4;ых процессов управления, планированl= 0;я, учета досту = 87;ных ресурсов, реализации процессов программноl= 1; инженерии, оценивания = 80; организациl= 0; специалистl= 6;в. <o:p= ></o:p> С точки зрения поддержки и регламентиl= 8;ования полного жиз = 85;енного цикла крупных проектов программныm= 3; средств к недостаткаl= 4; моделей CMMI относительl= 5;о профиля сущ = 77;ствующих стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> можно о = 90;нести следующие:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>н = 77; все процесс = 99; предусмотрk= 7;ны в составе пр= 086;цессов моделей CMMI – 1.1, котор= ;ые развиваютсn= 3; и детально комментируn= 2;тся для их реали= 079;ации в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9004:2000 и ISO 90003:2004, а также в профиле стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'>;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>н = 77; отражены особенностl= 0; системной инженерии и международl= 5;ые стандарты, регламентl= 0;рующие процессы жизненного цикла сложн = 99;х систем ISO 15288:2002 и ISO 19760:2003; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и анализе процессов обеспечениn= 3; качества используетl= 9;я ряд традиционнm= 9;х характерисm= 0;ик систем и программныm= 3; продуктов, которые применяютсn= 3; в сложных проектах, однако не описаны и не комментируn= 2;тся базовые международl= 5;ые стандарты, систематизl= 0;рующие и регламент = 80;рующие качество программныm= 3; средств = - ISO 9126:1-4, ISO 14598:1-6,&nbs= p; ISO 15939; <= /span><o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 90;сутствуют описания характерисm= 0;ик и конкретны = 93; процессов обеспечениn= 3; информациоl= 5;ной и функционалn= 0;ной безопасносm= 0;и программныm= 3; продуктов и ссылки на мн= 086;гочисленны&= #1077; стандарты в этой област = 80;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>н = 77; отражены регламентиl= 8;ованные интерфейсы Открытых си = 89;тем на взаимоде = 81;ствие программныm= 3; компонентоk= 4;, а также с опе&#= 1088;ационной и внешней средой, в соответствl= 0;и со стандартамl= 0; = - ISO 9945:1= -4;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 86;кументиров&#= 1072;ние процессов и продуктов Ж = 62; ПС комменти = 88;уется только, по мере их реализации, = 080; не представлеl= 5;ы обоб= щенные требования к технологиm= 5;еской и эксплуата = 94;ионной документацl= 0;и на программ = 85;ый продукт в соответствl= 0;и со стандарт = 72;ми - ISO 9294, </= span>ISO<= span style=3D'font-size:14.0pt'> 15910, <= /span>ISO<= span style=3D'font-size:14.0pt'> 18019.<o:p></o:p> Для определениn= 3;, представлеl= 5;ных выше уровне = 81; зрелости пр = 86;цессов обеспечениn= 3; жизненного цикла ПС, разработаl= 5; и первонача = 83;ьно утвержден в 1998 году обширный техническиl= 1; отчет ISO= 15504 – Оценка и аттестация зрелости процессов создания и сопровождеl= 5;ия ПС и систем, состоящий из девяти ча= 089;тей и множества приложений. В нем = 80;зложена модель зрелости CMM<= span style=3D'font-size:14.0pt'> и восем= 00; базовых принципов программноl= 1; инженерии н = 72; основе стандарта ISO<= span style=3D'font-size:14.0pt'> 9000:2000 (см. лекцию 1). Затем в ISO этот документ претерпел коренную переработкm= 1;, сокращение, упрощение структуры и содержания, при пl= 6;лном сохранении целей и конц= 077;пции, и утвержден как стандар = 90; в составе пяти частей (см. Приложен&#= 1080;е 1). Ста = 85;дарт ISO 15504:1-5:2003-2006 регламентиl= 8;ует оценку и аттестацию = 79;релости процессов создания, сопровождеl= 5;ия и совершенс = 90;вования программныm= 3; средств и систем, выполняемыm= 3; предприятиn= 3;ми:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я установленl= 0;я состояния собственнm= 9;х технологичk= 7;ских процессов и их совершен = 89;твования;<o:p></o:p></sp= an> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я определениn= 3; пригодностl= 0; собственныm= 3; процессов для выполне = 85;ия определеннm= 9;х требований или классов требований заказчиков;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>с целью его пригодностl= 0; для выполнения определеннm= 9;х договоров с = 079;аказчиками ПС и систем. <o:p></o= :p> Стандарт способствуk= 7;т: самоаттk= 7;стации зрелости предприятиl= 1;, обеспечениn= 2; адекватногl= 6; управления аттестуемыl= 4;и процессами, определениn= 2; профиля рейтингов процессов и подходит к любым сфера = 84; применения = 80; размерам ПС = 080; систем. Прим= 077;нение стандарта направлено на выработк = 91; предприятиn= 3;ми и специалис = 90;ами культуры постоянногl= 6; совершенстk= 4;ования зрелости технологий обеспечениn= 3; ЖЦ ПС, отвечающих бизнес-целя = 84; проектов и оптимизациl= 0; использоваl= 5;ия доступных ресурсов. Аттестация зрелости пр = 86;цессов предприятиl= 1; обеспечиваk= 7;т возможностn= 0; их сопостав = 83;ения и выбора, предпочтитk= 7;льных для определ = 77;нных проектов:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я заказчиков, покупателеl= 1;, пользоватеl= 3;ей программныm= 3; продуктов и систем – способностn= 0; определять = 90;екущую и потенциальl= 5;ую зрелость процессов жизненного цикла у предприятиn= 3; поставщика;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я поставщикоk= 4; и разработчиl= 2;ов – способнос = 90;ь определять текущую и потенциальl= 5;ую зрелость собственныm= 3; процессов ж = 80;зненного цикла ПС и си&#= 1089;тем, области и пр= 080;оритеты усовершенсm= 0;вования процессов;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я аттестаm= 0;оров зрелости – основу для проведения = 80; совершенстk= 4;ования процессов аттестации.<o:p= ></o:p> Аттестациn= 3; в стандарте рассматривk= 2;ется в двух аспектах: дл= 103; усовершенсm= 0;вования процессов Ж = 62; ПС и систем к&#= 1086;нкретного предприятиn= 3;, и для опреде= 083;ения соответс= ;твия декларироk= 4;анной зрелости процессов обеспечениn= 3; проекта ил = 80; предприятиn= 3;, реальным ис = 87;ользуемым процессам. Это отражен = 86; в следующих пяти частях стандарта ISO<= span style=3D'font-size:14.0pt'> 15504:1-5:2003-2006. <o:p></o:p> Часть 1 – Концепция и словарь – со= 076;ержит общую инфор = 84;ацию о процессах = 072;ттестации зрелости ПС = 080; систем, и рекомендацl= 0;и по использо = 74;анию частей стандарта. И= 079;ложены общие требования = 82; аттестации, терминологl= 0;я, структура и область применения остальных ч = 72;стей стандарта.<o:p></o:p>= Часть= 2 – Выполнение (производст = 74;о) аттестации R= 11; включает де = 90;альные требования = 82; проведению процессов аттестации, = 082;ак основы для совершенсm= 0;вования и определен = 80;я уровня зрелости технологичk= 7;ских процессов обеспечениn= 3; ЖЦ ПС и систем. Докум= ;ент определяет процессы вы = 87;олнения аттестации, модели рекомендуеl= 4;ых процессов аттестации = 80; верификациl= 0; процессов, с тем, чтобы они были объ= 077;ктивными, содержателn= 0;ными и репрезентаm= 0;ивными. <o:p></o:p> Часть 3 – Руководствl= 6; по производ = 89;тву аттестации R= 11; содержит об = 79;ор технологии выполнения процессов аттестации зрелости, и интерпретаm= 4;ии реализации требований. = 042; нем отражен = 86;: исполнение аттестации; = 080;змерительн&= #1099;е средства дл= 03; определениn= 3; процессов зрелости; выбор и прим= 077;нение средств аттестации; оценка комп = 77;тентности аттестаm= 0;оров; вериф= ;икация соответствl= 0;я аттестации декларировk= 2;нным требованияl= 4;. Средс= ;тва аттестации могут использоваm= 0;ься предприятиn= 3;ми при планированl= 0;и, менеджментk= 7;, мониторингk= 7;, контроле и усовершенсm= 0;вовании программныm= 3; продуктов и систем, при их приобретенl= 0;и, разработке, применении = 80; сопровождеl= 5;ии.<o:p></o:p> Часть 4 – Руководствl= 6; пользоватеl= 3;ей для процессов усовершенсm= 0;вования и определениn= 3; зрелости процессов п = 86; этим двум аспекта. Рек= 086;мендуется ряд шагов, которые включают: пр= 080;менение результатоk= 4; процессов аттестации; постановка целей аттестации зрелости; определениk= 7; исходных данных для аттестации; оценка возможного снижения ре = 79;ультирующи&#= 1093; рисков; шаги по усовершенсm= 0;вованию процессов; шаги по опре= 076;елению уровня зрелости; сравнение = 88;езультатов анализа аттестации = 89; требованияl= 4;и.<o:p></o:p> Часть 5 – Образец модели процессов аттестации на соответствl= 0;е требованияl= 4;, представлеl= 5;ным в части 2. Обширный до = 82;умент (162 стр.) содержит пр = 80;меры практическl= 6;го применения предыдущих частей стан = 76;арта для организациl= 0;, оценивания = 80; совершенстk= 4;ования аттестации зрелости процессов жизненного цикла для ра= 079;личных областей ис = 87;ользования, проектов программныm= 3; средств и предприятиl= 1;. <o:p></o:p> При практичесl= 2;ой реализации проектов и обеспечениl= 0; жизне= 085;ного цикла сложн = 99;х ПС разработчиl= 2;ам и поставщикаl= 4; может быть трудно определить, = 080; выделить дл= 03; применения преимущестk= 4;а моделей CMMI. В завис= 080;мости от традиций предприятиn= 3; и особеннос = 90;ей крупного проекта ПС зачастую целесообрk= 2;зно использоваm= 0;ь как основно = 81; полный профиль стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'>, а для оценивания заказчикамl= 0; уровня зрел = 86;сти менеджментk= 2;, организациl= 6;нного и технологи = 95;еского обеспечениn= 3; проектов ПС применять к = 86;нкретные рекомендацl= 0;и CMMI. Эти рекомендацl= 0;и могут эффек = 90;ивно использоваm= 0;ься при с= 077;ртификации<= span style=3D'mso-spacerun:yes'> качества процессов на предприя = 90;иях, обеспечиваn= 2;щих ЖЦ ПС, как альтернатиk= 4;а или наряду с сертификацl= 0;ей по комплекс = 91; стандартов менеджментk= 2; ISO<= span style=3D'font-size:14.0pt'> 9000, в завиl= 9;имости от особенностk= 7;й проекта и требований заявителя н = 72; сертификацl= 0;ю программноk= 5;о продукта ил = 80; технологии обеспечениn= 3; его жизненн = 86;го цикла.<o:p></o:p> <o:p> </o:p> <h1> <= /span><a name=3D"_Toc508102455"></a><a name=3D"_Toc508102228">3.2. Стандарты менеджментk= 2; (администра = 90;ивного управления) = 082;ачеством систем</a> </h1> <o:p= ></o:p> Серия стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> 9000:2000 разработанk= 2;, чтобы помоч= 00; предприятиn= 3;м всех типов и размеров внедрить и использоваm= 0;ь эффективныk= 7; системы мен = 77;джмента (администра = 90;ивного управления) качества. Совместно они образую = 90; комплект согласованl= 5;ых стандартоk= 4; управления системами качества и могm= 1;т применятьсn= 3; как основа процессов управления = 74; программноl= 1; инженерии:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>ISO 9000:2000 – представляk= 7;т введение в системы упр = 72;вления качеством продукции и услуг и слов= 072;рь качества;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>ISO 9001:2000 – устанавливk= 2;ет детальные требования для систем управления качеством, достаточныk= 7; в случае необходимоl= 9;ти продемонстl= 8;ировать способностn= 0; предприятиn= 3;, обеспечить соответствl= 0;е качества продукции и услуг требованияl= 4; заказчика; <o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>ISO 9004:2000 – соk= 6;ержит руководстk= 4;о по внедрени= 02; и применени= 02; широко развитой системы управления качеством, чтобы дости = 95;ь постоянногl= 6; улучшения деловой дея = 90;ельности и результатоk= 4; предприятиn= 3;.<o:p></o:p> Стандарты серии ISO 9000:2000 применяют процессный подход в администраm= 0;ивном управлении системами качес= ;тва предприятиl= 1;, а также рассматривk= 2;ют способы быстрого вы= 03;вления и реализаци = 80; возможностk= 7;й для их улучшения. Процессная модель подчеркиваk= 7;т тот факт, что заказчики и другие заинтересоk= 4;анные стороны играют значительнm= 1;ю роль в проце= 089;се установленl= 0;я исходных требований. = 055;осле этого по отношению к = 86; всем процессам, н= 077;обходимым для создани= 03; необходимоl= 1; продукции, применяетсn= 3; управление процессами = 80; проводится проверка “выходов”. Измерение степени удовлетворk= 7;нности заказчика и других заинтересоk= 4;анных сторон используетl= 9;я в качестве обратной связи для оценки и признания того, что требования заказчика были выполн = 77;ны полностью.<o:p></o:p>= В стандаl= 8;те ISO 9004 детализироk= 4;аны руководящиk= 7; указания и р= 077;комендации по применению системы менеджментk= 2; качества, которые изл = 86;жены в том же порядке, как требования = 74; ISO 9001. Обk= 2; стандарта с = 89;ылаются на ISO 9000, который объясняет используемm= 1;ю терминологl= 0;ю и определениn= 3;. Структура основных требований = 80; рекомендацl= 0;й в этих станд= 072;ртах сведена к четырем объединеннm= 9;м крупным процессам (рис. 3.2): <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 73;язанности и ответственl= 5;ость администраm= 4;ии управления = 82;ачеством (раздел 5); <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 76;министрати&#= 1074;ное управление ресурсами (р= 072;здел 6);<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;оцессы жизненного цикла продукции и управления ее качество = 84; (раздел 7); <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 79;мерения, анализ и совершенстk= 4;ование продукции (раздел 8). <o:p></o:p> Стандар= ;ты серии ISO 9000:2000 рекомендуеm= 0;ся применять в = 076;еятельност&= #1080; предприятиn= 3;, начиная от идентификаm= 4;ии требований = 79;аказчика, и охватыватn= 0; все процесс = 99; системы управления качеством, вплоть до до= 089;тижения соответствl= 0;я требованияl= 4;. Применение = 89;окращенног&#= 1086;, адаптироваl= 5;ного варианта требований не освобожд = 72;ет предприятиk= 7; от ответств = 77;нности предоставлn= 3;ть продукцию, которая удовлетворn= 3;ет всем требов = 72;ниям заказчика. Система качества должна быть внедрена, поддерживаm= 0;ься в рабочем состоянии и подвергатьl= 9;я улучшениям = 89;о стороны спе = 94;иалистов предприятиn= 3;. Масштаб и глубина про = 94;едур должна опре = 76;еляться такими факторами как размер и тип предприятиn= 3;, сложность и взаимосвязn= 0; процессов, применяемыk= 7; методы, а так&#= 1078;е квалификацl= 0;я и степень подготовки персонала, участвующеk= 5;о в выполнени = 80; работ. Они дl= 6;лжны включать:<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>о = 73;щесистемны&#= 1077; процедуры, которые описывают деятельносm= 0;ь, необходимуn= 2; для внедрения и применения системы кач = 77;ства;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;оцедуры, описывающиk= 7; последоватk= 7;льность и внутренне = 77; содержание процессов, необходимыm= 3; для обеспечениn= 3; уверенност&#= 1080; в соответст = 74;ии продукции установленl= 5;ым требованияl= 4;;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>и = 85;струкции, описывающиk= 7; операционнm= 1;ю деятельносm= 0;ь и управлени = 77; процессами.<o:p= ></o:p> Для освоения и облегчения применения стандартов = 74; редакции 2000-го года, в прило&#= 1078;ении к ISO 9001:2000 приведены таблицы, отражающие взаимное соответствl= 0;е требований этого станд = 72;рта и требовани = 81; ISO<= span style=3D'font-size:14.0pt'> 9001:1994. Таблицы могут использоваm= 0;ься при необход = 80;мости подтверждеl= 5;ия в настоящее время сертификатl= 6;в качества, полученных ранее на основании применения стандартов = 74; редакции 1994-го года. Это позволяет с = 86;хранять и практическl= 0; использоваm= 0;ь всю техноло = 75;ическую документацl= 0;ю и рабочие ин= 089;трукции, базирующиеl= 9;я на стандартах качества 1994-го года, дополняя их только этим = 80; таблицами соответствl= 0;я требований.<o:p= ></o:p> Ста= ндарт ISO 9001:2000 – Система менеджменm= 0;а (администра = 90;ивного управления) качества. Требования – является базой для Ру= 082;оводства по их реализ= 072;ции в стандарте ISO 9004:2000 и кратко изло = 78;ены ниже (см. рис. 3.2).<= span style=3D'mso-spacerun:yes'> <o:p></o:p> Общие требования = 82; системе менеджментk= 2; качества. Орган= 080;зация – разработчиl= 2; должна установить = 80; управлять процессами, необходимыl= 4;и для обеспеч = 77;ния уверенностl= 0; в том, что продукция и/или услуга соответствm= 1;ют требованияl= 4; заказчика. В качестве сп = 86;соба внедрения и демонстрацl= 0;и, установлеl= 5;ных процессов, организациn= 3; должна создать систему менеджментk= 2; качества, основываясn= 0; на требованияm= 3; настоящего международl= 5;ого стандарта. Система менеджментk= 2; качества должна быть внедрена, поддерживаm= 0;ься в рабочем состоянии и подвергатьl= 9;я улучшениям = 89;о стороны организациl= 0;. Организациn= 3; должна подготовитn= 0; процедуры системы менеджментk= 2; качества, которые описывают процессы, не= 086;бходимые для внедрения с = 80;стемы менеджментk= 2; качества. Масштаб и гл= 091;бина процедур должна определятьl= 9;я такими факторами как размер и тип организациl= 0;, сложность и взаимосвязn= 0; процессов, применяемыk= 7; методы, а так&#= 1078;е квалификацl= 0;я и степень подготовки персонала, участвующеk= 5;о в выполнени = 80; работ. <o:p></o:p> Высшее руководствl= 6; предприятиn= 3; – разработчиl= 2;а должн= о продемонстl= 8;ировать свои обязательсm= 0;ва заказчику о = 90;носительно:<= o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>создания и поддержаниn= 3; важности удовлетворk= 7;ния требований заказчика;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>разработк = 80; политики качества и целей в обла= 089;ти качества, а также плани = 88;ования качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>создания системы менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>проведения анализа деятельносm= 0;и со стороны руководствk= 2;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечени= ;я уверенностl= 0; в наличии ресурсов.<o:p></o:p>= Требованиn= 3; заказчика – высшее= руководстk= 4;о должно обес = 87;ечить, что:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>потребнос = 90;и и ожидания заказчика установленm= 9; и переведен = 99; в соответствm= 1;ющие требования заказчика;<o:p></o:p>= <![if !supportLists]>= - = &nb= sp; <![endif]>требования заказчика полностью поняты разр = 72;ботчиком и могут быть удовлетворk= 7;ны.<o:p></o:p> Выс&= #1096;ее руководствl= 6; должно разработатn= 0; пол= итику в области ка= 095;ества и обеспечить уверенностn= 0; в том, что она:= <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>соответств= ;ует потребностn= 3;м организации и её заказчиков;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>включает обязательсm= 0;ва по удовлетворk= 7;нию требований = 80; постоянномm= 1; улучшению;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>обеспечива= ;ет основу для разработки = 80; анализа целей в обла= 089;ти качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>распростра= ;нена, понята и внедрена во всей органи = 79;ации;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>анализируе= ;тся с целью постоянногl= 6; поддержаниn= 3; ее пригодно = 89;ти.<o:p></o:p> Пла= нирование – организациn= 3; должна установить = 94;ели в области ка= 095;ества для каждой соответствm= 1;ющей функции и дл= 103; каждого уровня внут = 88;и организациl= 0;. Цели в области качества должны соответствl= 6;вать политике и обязательсm= 0;вам относительl= 5;о непрерывноk= 5;о улучшения качества. Орган= ;изация должна уста = 85;овить и планироватn= 0; деятельнос&#= 1090;ь и ресурсы, необходимыk= 7; для достижения целей в обла= 089;ти качества. Такое планированl= 0;е должно отвечать другим требованияl= 4; к системе менеджментk= 2; качества, а его результаты должны быть документирl= 6;ваны. Планированl= 0;е должно охватывать:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>процессы, необходимыk= 7; в рамках системы менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>процессы создания и необходимыk= 7; ресурсы, а также устан = 86;вленные характерисm= 0;ики качества на различных стадиях, с целью дости = 78;ения планируемыm= 3; результатоk= 4;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>деятельно = 89;ть по проверке, критерии приемлемосm= 0;и и необходим = 99;е отчеты по качеству.<o:p></o:p>= Сl= 0;стема менеджментk= 2; качества – организаm= 4;ия должна создать систему менеджментk= 2; качества, ка= 082; средство реализации = 77;ё политики в о= 073;ласти качества, достижения своих целей = 074; области кач = 77;ства и обеспечениn= 3; уверенностl= 0; в том, что про&= #1076;укция и/или услуга отвечает требованияl= 4; заказчика. Роли сотрудникоk= 4; и их взаимосвязl= 0;, а также отве= 090;ственность и полномочи= 03; персонала должны быть = 091;становлены для того, чтобы спосо = 73;ствовать эффективноl= 4;у управлению качеством, и должны быть доведены до соответствm= 1;ющих уровней орг = 72;низации. Высшее руководствl= 6; должно упол = 85;омочить одного (или нескольких) лиц для:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечени= ;я уверенностl= 0; в том, что система менеджментk= 2; качества внедрена и поддерживаk= 7;тся в рабочем состоянии в соответствl= 0;и с требованияl= 4;и настоящего международl= 5;ого стандарта;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>доклада высшему руководствm= 1; о функциони = 88;овании системы менеджментk= 2; качества, включая вопросы, связанные с необходимоl= 9;тью ее улучшени= 03;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечен = 80;я уверенностl= 0; в осознании во всей организациl= 0; требований = 79;аказчика.<o:p></o:p></sp= an> Организацl= 0;я должна разработатn= 0; Руков= 086;дство по качеству</sp= an>, которое должно включать: описание элементов системы менеджментk= 2; качества и и= 093; взаимосвязk= 7;й; общесистемl= 5;ые процедуры или соответствm= 1;ющие ссылки на них. Следует установить общесистемl= 5;ые процедуры для управле = 85;ия документамl= 0;, необходимыl= 4;и для функционирl= 6;вания системы мен = 77;джмента качества, обеспечиваn= 2;щие уверенностn= 0; в том, что:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>документы проверены н = 72; адекватносm= 0;ь до их применения;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>документы анализируюm= 0;ся, при необходимоl= 9;ти уточняются = 80; переутве = 88;ждаются;<o:p></o:p></sp= an> <![if !supportLists]>- = &nb= sp; <![endif]>соответств= ;ующие выпуски документов находятся в тех местах, где осуществляk= 7;тся деятельносm= 0;ь, имеющая существеннl= 6;е значение дл= 03; эффективноl= 9;ти функционирl= 6;вания системы менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>устаревшие документы изъяты из всех мест их рассылки и применения или предпринятm= 9; другие методы управления, предотвращk= 2;ющие их не= преднамереl= 5;ное использоваl= 5;ие;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>любые устаревшие документы, оставленныk= 7; для юридическиm= 3; целей или в ц&#= 1077;лях сохранения знаний, должным образом иде = 85;тифицирова&#= 1085;ы.<o:p></o:p> Дол&= #1078;ен быть составлен специальныl= 1; перечень ил = 80; эквивалентl= 5;ая процедура управления, идентифициl= 8;ующая статус текущей вер = 89;ии документов, которая был = 72; бы легко = 76;оступна в целях предотвращk= 7;ния использоваl= 5;ия недействитk= 7;льных и/или устаревших документов.<o:p= ></o:p> Для демонстрацl= 0;и соответствl= 0;я требованияl= 4; и эффективн = 86;сти функционирl= 6;вания системы менеджментk= 2; качества должны вест = 80;сь подходящие для организ = 72;ции о&= #1090;четы о качестве. Организациn= 3; должна создать и поддерживаm= 0;ь в рабочем состоянии процедуры о = 73;щесистемно&#= 1075;о уровня по идентификаm= 4;ии, хранению, восстановлk= 7;нию, обеспечениn= 2; сохранностl= 0;, установленl= 0;ю времени и места хране = 85;ия отчетов о качестве. Анализ со стороны руководствk= 2; долже= ;н через установленl= 5;ые периоды времени про = 74;одиться для обеспечениn= 3; уверенностl= 0; в сохранени = 80; её пригодностl= 0;, адекватносm= 0;и и эффективн = 86;сти. По результа = 90;ам анализа должна проводитьсn= 3; оценка необходимоl= 9;ти внесения изменений в систему мен = 77;джмента качества организациl= 0;, включая полити= ку и цели в области кач = 77;ства. <o:p></o:p> У= ;правление ресурсами необходимо для создани= 03; и поддержаниn= 3; в рабочем состоянии системы мен = 77;джмента качества. Организациn= 3; должна пров = 86;дить анализ и назначение персонала с целью обесп = 77;чения уверенностl= 0; в том, что те, кто имеет обязанностl= 0;, определеннm= 9;е системой менеджментk= 2; качества, являются ко = 84;петентными для осуществлеl= 5;ия своей деяте = 83;ьности на основе соответствm= 1;ющего образованиn= 3;, подготовки, мастерства = 80; опыта, создать и поддерживаm= 0;ь в рабочем состоянии общесистемl= 5;ые процедуры по:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>определени= ;ю потребностk= 7;й в компетентнl= 6;м персонале и = 074; его подгото = 74;ке;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>обеспечени= ;ю подготовки персонала в соответствl= 0;и с выявленны = 84;и потребностn= 3;ми;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>оценке через установленl= 5;ый период врем = 77;ни эффективноl= 9;ти подготовки кадров;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>ведению соответствm= 1;ющих отчетов об образованиl= 0; кадров, их подготовке, уровне маст = 77;рства и опыта. <o:p></o:p> Организацl= 0;я должна создать и поддерживаm= 0;ь в рабочем состоянии процедуры, обеспечиваn= 2;щие их осознани = 77; работникамl= 0; в соответст = 74;ующих службах и на соответствm= 1;ющих уровнях:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>важности соответствl= 0;я политике в области качества и требованияl= 4; к системе менеджментk= 2; качества важности;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>влияния их деятельносm= 0;и на качество = 211; фактическоk= 7; или потенци = 72;льное;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>выгоды от улучшения работы персонала;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>своей роли = 80; ответственl= 5;ости в достижени = 80; соответствl= 0;я политике в области качества и процедурам, = 072; также требованияl= 4; к системе менеджментk= 2; качества;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>потенциаль= ;ных последствиl= 1; отклонений от установленl= 5;ых процедур.<o:p></o:p>= О= рганизация должна установить </sp= an>пер= ечень информации</spa= n>, которая необходима для управления процессами, = 072; также для обеспечениn= 3; уверенностl= 0; в соответст = 74;ии продукции и/или услуги. Общесистемl= 5;ые процедуры п = 86; управлению информациеl= 1; должны обес = 87;ечить уверенностn= 0; в доступнос = 90;и и сохранностl= 0; информации.<o:p= ></o:p> Организацl= 0;я должна определить, создать и поддерживаm= 0;ь в рабочем состоянии инф= раструктурm= 1;, необходимуn= 2; для достижения требуемого = 82;ачества продукции:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>рабочие места и соответствm= 1;ющие помещения;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>оборудован= ;ие, вспомогатеl= 3;ьные средства и инструментk= 2;льное программноk= 7; обеспечениk= 7;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пригодные способы поддержаниn= 3; работоспосl= 6;бности инфраструкm= 0;уры.<o:p></o:p> Процессы, необходимыk= 7; для выпуска требуемой продукции, их последоватk= 7;льность и взаимосвя = 79;и должны быть определены, спланироваl= 5;ы и внедрены. При определ = 77;нии таких процессов организациn= 3; должна учес = 90;ь результаты планированl= 0;я качества. До= 083;жна быть уверенностn= 0; в том, что эти процессы ос = 91;ществляютс&#= 1103; в управляемыm= 3; условиях и и= 093; результаты соответствm= 1;ют требованияl= 4; заказчика:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>установить для этих процессов соответствm= 1;ющие методы и практику выполнения, необходимыk= 7; для обеспечениn= 3; постоянной работоспосl= 6;бности процессов;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>определить и внедрить критерии и методы упра = 74;ления процессами для обеспеч = 77;ния соответствl= 0;я продукции требованияl= 4; заказчика;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>удостовери= ;ться, что процесс = 99; могут функц = 80;онировать в той мере, которая поз = 74;оляет обеспечить соответствl= 0;е продукции т = 88;ебованиям заказчика;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>обеспечить уверенностn= 0; в наличии информации = 80; данных, необ= 093;одимых для поддерж = 72;ния эффективноk= 5;о функционирl= 6;вания и мониторин = 75;а процессов;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>фиксироват= ;ь в виде отчетов качество результатоk= 4; измерений, осуществляk= 7;мых в ходе управ= 083;ения процессами, для предоставлk= 7;ния доказательl= 9;тв эффективноk= 5;о функционирl= 6;вания и мониторингk= 2; процессов.<o:p></o:p>= Орга&= #1085;изация должна создать про= цесс идентификаm= 4;ии требований заказчика:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>полноту требований заказчика к продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>требования= ;, не установленl= 5;ые заказчиком, = 085;о необходимыk= 7; для примене = 85;ия продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>обязательс= ;тва по отношени= 02; к продукции, включая регламентиl= 8;ующие и законодат = 77;льные требования;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>требования заказчика относительl= 5;о пригодностl= 0; продукции для её поста= 074;ок и сопровождеl= 5;ия.<o:p></o:p> Требованиn= 3; заказчика, включая любые предлагаемm= 9;е изменения, должны быть проанаl= 3;изированы<sp= an style=3D'font-size:14.0pt;mso-bidi-font-weight:bold'> для обеспечениn= 3; уверенностl= 0; в том, что: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>требования заказчика к продукции четко опред = 77;лены;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>в случае, когда требования заказчика н = 77; оформлены письменно, о= 085; подтвердил их до принятия их разработчиl= 2;ом;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>организаци= ;я располагаеm= 0; возможностn= 3;ми для удовлетворk= 7;ния требований = 79;аказчика к продукции.<o:= p></o:p> Организацl= 0;я должна планирова = 90;ь и управлять проектировk= 2;нием и/или разраб= 086;ткой продукции, подготавлиk= 4;ать планы проектировk= 2;ния, которые вкл= 02;чают:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>этапы процесса проектировk= 2;ния и/или разраб= 086;тки;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>требуемые действия по анализу, проверке и у= 090;верждению качества пр = 86;дукции;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>полномочи= 03; и ответственl= 5;ость за действия по проектир = 86;ванию и/или разраб= 086;тке.<o:p></o:p> </spa= n>Входные данные для проектировk= 2;ния и разработк = 80; должны включать:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>эксплуатац= ;ионные требования заказчика и = 83;и рынка;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>применяемы= ;е нормативныk= 7; и законодатеl= 3;ьные требования;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>применяемы= ;е требования по охране окружающей среды;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>любые другие требования, существеннm= 9;е для проектировk= 2;ния и разработк = 80;.<o:p></o:p> Выход= ные данные процесса проектировk= 2;ния и/или разработки</spa= n> должны быть = 079;арегистрир&= #1086;ваны в форме, дающей возможностn= 0; проверки их по отношени= 02; к входным требованияl= 4;:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>с = 86;ответствов&#= 1072;ть входным требованияl= 4; для проектировk= 2;ния и/или разраб= 086;тки;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>содержать или давать ссылку на критерий пр = 80;емки продукции и/или услуги;<o= :p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>о = 87;ределять характерисm= 0;ики продукции и/= 080;ли услуги, которые являются су = 97;ественными с точки зрения безопасносm= 0;и и правильно = 75;о использоваl= 5;ия.<o:p></o:p> На соответствm= 1;ющих этапах долж = 77;н проводитьсn= 3; систе= 084;атический анализ проекта дл= 03;: оценки возможностl= 0; выполнения требований = 82; качеству; идентификаm= 4;ии проблем – дефектов и выработки предложениl= 1; по разработке решений для = 080;х устранения. <sp= an style=3D'mso-bidi-font-style:italic'> В состав уча = 89;тников анализа проекта должны включаться представитk= 7;ли служб, связа= 085;ных с анализиру = 77;мым этапом проектировk= 2;ния. Должна быть = 089;планирован&= #1072; и выполнена проверка пр = 86;екта и/или разработки, обеспечиваn= 2;щая уверенностn= 0; в том, что выходные да = 85;ные соответствm= 1;ют входным требованияl= 4;. <o:p></o:p> Утвер= 078;дение проекта должно проводитьсn= 3; с целью подтверждеl= 5;ия того, что кон&#= 1077;чная продукция способны отвечать требованияl= 4; для конкретных условий использоваl= 5;ия заказчиком. Когда это возможно, утверждениk= 7; должно быть спланироваl= 5;о и выполнено до начала поставки ил = 80; применения продукции. Результаты утверждениn= 3; и последующиm= 3; действий должны быть зарегистриl= 8;ованы.<o:p></o:p> Изменения проекта или модификациn= 3; должны быть утверждены уполномочеl= 5;ным персоналом = 80; зарегистриl= 8;ованы до их внедре= 085;ия, следует опр = 77;делить влияние изм = 77;нений на:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>взаимодейс= ;твие между элементами проекта и/ил= 080; разработки:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>взаимодейс= ;твие между составными частями конечной продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>имеющуюся продукцию и на функцион = 80;рование ранее поста = 74;ленной продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>необходимо= ;сть проведения повторной проверки ил = 80; утверждениn= 3; для всех или части выходных данных прое = 82;тирования и/или разраб= 086;тки.<o:p></o:p> Организ= ;ация должна управл= ять процессами закупки компонентоk= 4; для обеспечениn= 3; уверенностl= 0; в соответствl= 0;и закупленноl= 1; продукции требо= ;ваниям, установленl= 5;ым заказчиком. Закупочные документы должны соде = 88;жать информацию, четко описывающуn= 2; заказанную продукцию.<o:p></o:p>= Организацl= 0;я должна спl= 3;анировать и управлять производстk= 4;енными и сервисным = 80; операциями обслуживанl= 0;я, включа= 03; те, которые предпринимk= 2;ются после первоначалn= 0;ной поставки, посредствоl= 4;: <o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>п = 88;едоставлен&#= 1080;я техническиm= 3; условий, опр= 077;деляющих характерисm= 0;ики продукции, которые должны быть достигнуты;<o:p= ></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>п = 88;едоставлен&#= 1080;я четко понимаемых производстk= 4;енных требований или инструк = 94;ий для тех видо= 074; деятельносm= 0;и, где они необ= 093;одимы для достиже = 85;ия соответствl= 0;я продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>внедрения надлежащих действий по мониторингm= 1; или проверк = 77; продукции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>подходящих методов для выпуска, поставки и/и= 083;и монтажа продукции.<o:p></o:p>= &nb= sp; Меры по утверждениn= 2; процессов д = 86;лжны быть направлены на: аттестацию процессов д = 86; их использоваl= 5;ия; аттестацию оборудованl= 0;я и/или персонала. <o:p></o:p= > Следует определить, спланироваm= 0;ь и внедрить проце= 089;сы измерений, мониторингk= 2;, анализа и улучшения = 76;ля обеспечениn= 3; уверенностl= 0; в том, что система менеджментk= 2; качества, процессы и продукция соответствm= 1;ют установленl= 5;ым требованияl= 4;. Эффективноl= 9;ть применяемыm= 3; измерений должна периодичесl= 2;и оцениватьсn= 3;. Результаты анализов данных и действий по улучшению должны служить исходными данными для процесса анализа со стороны рук = 86;водства.<o:p></o:p> <sp= an style=3D'color:windowtext;mso-bidi-font-weight:normal'>Орг= ;анизация должна определить = 80; установить </sp= an>про= цессы измерения и функциониl= 8;ования системы менеджментk= 2; качества. Удовлетворk= 7;нность заказчика должна испо = 83;ьзоваться в качестве одного из из= 084;еряемых параметров результатоk= 4; действия системы. Организ= ;ация должна прим = 77;нять методы измерения и мониторингk= 2; процессов, необходимыk= 7; для удовлет = 74;орения требований заказчика и для демонст = 88;ации постоянной способностl= 0; процессов удовлетворn= 3;ть поставленнm= 9;м целям. Результаты измерений должны использоваm= 0;ься для поддержаниn= 3; в рабочем состоянии и/или улучшения этих процессов. Данные отче = 90;ы должны указ = 99;вать уполномочеl= 5;ных лиц, ответственl= 5;ых за выпуск продукции.<o:p></o:p>= Следует обеспечить уверенностn= 0; в том, что продукция, которая не соответствm= 1;ет требованияl= 4;, находится под управлениеl= 4;, обеспечиваn= 2;щим предотвращk= 7;ние её непредна = 84;еренного использоваl= 5;ия или поставк = 80;. Механизм, обеспечиваn= 2;щий уверенностn= 0; в том, что несоответсm= 0;вующая продукция находится под управлениеl= 4;, должен быть определен в общесистемl= 5;ой процедуре. Продукция, имеющая нес = 86;ответствия, должна быть:<o:= p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>подвергну= 090;а коррекции или исправлениn= 2; с целью обес= 087;ечения соответствl= 0;я требованияl= 4;, или<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>принята<sp= an style=3D'color:windowtext'> на основании разрешения на отклонен = 80;е (с коррекцие= 081; или исправл = 77;нием или без них), или<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>перерас= ;пределена</sp= an> для разрешенноk= 5;о альтернатиk= 4;ного использоваl= 5;ия, или<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>удалена (отбракован = 72;) как неприемлемk= 2;я.<o:p></o:p> Должны быт= 00; определены ответственl= 5;ость и полномочи= 03; по проведен = 80;ю анализа и принятию решений по несоответсm= 0;виям. Там, где это определено контрактом, информация = 86; предлагаемl= 6;м использоваl= 5;ии или ремонте несоответсm= 0;вующей продукции должна напр = 72;вляться заказчику для получен = 80;я разрешения на отклонение. <o:= p></o:p> Для анализа совершенстk= 4;ования процессов должна быть установленk= 2; общесистемl= 5;ая процедура, направленнk= 2;я на определе = 85;ие эффективноl= 9;ти системы менеджментk= 2; качества и выявление мест, где могут быть сделаны улучшения. Организациn= 3; должна соби = 88;ать данные, появ= 083;яющиеся в результат = 77; действий по = 080;змерению и мониторин = 75;у, а также из лю&#= 1073;ых других прие = 84;лемых источников. <o:p></o:p> Следует постоянно улучшать систему менеджментk= 2; качества, установить общесистемl= 5;ую процедуру, которая определяет использоваl= 5;ие политики ка = 95;ества, целей, резул= 100;татов внутреннегl= 6; аудита, анализа дан = 85;ых, корректируn= 2;щих и предупреждk= 2;ющих действий и анализа со стороны руководствk= 2; в целях подд= 077;ржки постоянных улучшений. Установить процесс, направленнm= 9;й на сокращение или исключе = 85;ие причин несоответсm= 0;вий для предотвращk= 7;ния повторения несоответсm= 0;вий.<o:p></o:p> Общесистеl= 4;ная процедура для процеl= 9;са проведения корректируn= 2;щих действий должна определять требования по:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>идентифика= ;ции несоответсm= 0;вий;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>определени= ;ю причин несоответсm= 0;вий;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>р = 77;ализации всех действий, обусловленl= 5;ых необходимоl= 9;тью обеспечениn= 3; уверенностl= 0; в том, что несоответсm= 0;вия не повторят = 89;я;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>регистрац = 80;и результатоk= 4; предпринятm= 9;х действий;<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>а = 85;ализу эффективноl= 9;ти и регистрациl= 0; предпринятm= 9;х корректируn= 2;щих действий.<o:p></o:p>= Следует установить процесс, направленнm= 9;й на исключениk= 7; причин потенциальl= 5;ых несоответсm= 0;вий требованияl= 4; длn= 3; предупреждk= 7;ния их появлени= 03;. Отчеты системы мен = 77;джмента качества и результаты, полученные из анализа данных, должны использоваm= 0;ься в качестве исходных да = 85;ных для предупреждk= 2;ющих действий. <o:p></o:p> Стандарт ISO<= span style=3D'color:windowtext'> 90003:2004 – Рекомендацl= 0;и по применению стандарта ISO<= span style=3D'color:windowtext'> 9001:2000 для программныm= 3; средств – предназначk= 7;ны для регламентиl= 8;ования менеджментk= 2; при приобретенl= 0;и, поставке, разработке, = 087;рименении, сопровождеl= 5;ии слож = 85;ых программныm= 3; средств и при их обслу= 078;ивании. Стандарт н = 77; содержит ограничениl= 1; и изменений базовых требований ISO 9001:2000 и предлагаетl= 9;я при установленl= 0;и соответствl= 0;я требованияl= 4; комплексов программ:<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>к = 72;к части коммерческl= 6;го контракта с другими организациn= 3;ми;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и представлеl= 5;ии полезного продукта дл= 03; рынка;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я использоваl= 5;ия при поддержке процессов организациl= 0; проектов ПС;<o:= p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>д = 83;я учета при встраиваниl= 0; программныm= 3; средств k= 4; комплексы аппаратуры;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и организациl= 0; сервиса программныm= 3; продуктов.<o:p></o:p>= Полное или частичное применение стандарта IS= O 90003 целе = 89;ообразно в различных ситуациях, с учетом технологии, модели жизн = 77;нного цикла, проце= 089;сов разработки, последоватk= 7;льности действий и организациl= 6;нной структуры предприятиn= 3;. Его рекомен = 76;уется применять как поддерж = 82;у процессов программноl= 1; инженерии в </s= pan>IS= O 9001:2000, совме= ;стно со стандарт = 72;ми ISO 12207, <= span lang=3DEN-US style=3D'mso-bidi-font-size:14.0pt;mso-ansi-language:EN-US'>IS= O 15504, ISO 9126, ISO 14598, ISO 15939. <o:p></o= :p> Первые четыре раздела практическl= 0; повторяют содержание аналогичныm= 3; разделов в <sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-ansi-language:EN-US'>ISO<= span style=3D'font-size:14.0pt'> 9001:2000. Структура стандарта ISO<= span style=3D'font-size:14.0pt'> 90003:2004 привязана к разделам и требованияl= 4; в ISO 9001:2000, котор&= #1099;е цитируются = 74; начале кажд = 86;го раздела. Пятый разде = 83; определяет ответственl= 5;ость руководствk= 2;: общие обяза = 85;ности руководствk= 2; управления проектом; политику в области обеспечениn= 3; качества пр = 86;дукции; планированl= 0;е управления проектом; ответственl= 5;ость и полномочи= 03; специалистl= 6;в; анализ прое = 82;тирования со стороны руководствk= 2;. Формулировl= 2;и в ISO 90003 повторяют содержание основного стандарта с очень небольшими комментариn= 3;ми.<o:p></o:p> В шестом разделе – менеджмент ресурсов, более полно комментируn= 2;тся особенностl= 0; управления ресурсами в области про = 75;раммной инженерии. В= 085;имание акцентируеm= 0;ся: на проблема = 93; обеспечениn= 3; ограниченнm= 9;ми вычислителn= 0;ными ресурсами инфраструкm= 0;уры проектов; на компетентнl= 6;сти, квалификацl= 0;и и подготовк = 77; специалистl= 6;в; на управлен = 80;и производстk= 4;енной средой. При этом неоднократl= 5;ы подробные ссылки на тр= 077;бования стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> 12207, ISO 15504,= ISO<= span style=3D'font-size:14.0pt'> 9126, ISO 14598 (см. Приложен&#= 1080;е 1). <o:p></o:p> Наиболее обширным и специфичесl= 2;им, практическl= 0; полностью ориентировk= 2;нным на программныk= 7; продукты, является се = 76;ьмой раздел стандарта. В нем изложен = 86; планированl= 0;е и управлени = 77; процессами = 80; качеством жизненного цикла программныm= 3; средств l= 9; попутными ссылками на рекомендацl= 0;и перечисленl= 5;ых выше стандартов. Рекомендацl= 0;и проектировk= 2;ния и разработк = 80; имеют традиционнm= 1;ю структуру жизненного цикла ПС: входные и выходные данные проц = 77;ссов; анализ требований; = 074;ерификация и валида = 94;ия результатоk= 4;; управление изменениямl= 0; и сопровожд = 77;ние; мониторинг = 80; измерение результатоk= 4;. При этом фор= 084;улировки и цитаты раз= 076;елов ISO 9001 отходят на второй план. Небольшой восьмой раз = 76;ел посвящен измерениям, анализу и совершенстk= 4;ованию процессов и результатоk= 4; управления проектами программныm= 3; продуктов и почти не связан с тре= 073;ованиями ISO 9001.<o:p></o:p> В стандарт = 77; ISO<= span style=3D'font-size:14.0pt'> 90003 имеется два оригинальнm= 9;х приложения полностью о = 90;личающихся от приложен = 80;й в ISO 9001. Приложение А состав= 083;яет обширная таблица, в которой процессам стандарта ISO<= span style=3D'font-size:14.0pt'> 90003 сопост= ;авлены полезные детализируn= 2;щие процессы около 20 основных ст = 72;ндартов жизненного цикла сложных программныm= 3; средств. В таблице при = 83;ожения В сопоставлеl= 5;ы рекомендацl= 0;и по планированl= 0;ю программныm= 3; проектов в стандартах </sp= an>ISO<= span style=3D'font-size:14.0pt'> 90003 и ISO 12207, которые вес= 00;ма близки.<o:p></o:p> Практичесl= 2;и все перечисленl= 5;ые процессы и требования стандартов = 74; данном разделе, конкретизl= 0;рованы в очень подробных рекомендацl= 0;ях процессов (около 500 страниц – седьмой раздел) трех выделенных выше уровне = 81; модел= 080; CMMI= (см. п. 3.1). Он&= #1080; соот = 74;етствуют, регламентl= 0;рованным и детализир = 86;ванным рекомендацl= 0;ям в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9001:2000,&nbs= p; ISO 12207 и основных компонентаm= 3; профи= 083;я стандартов жизненного цикла сложных ПС (см. лекцию 2). Требованияl= 4; в функциона = 83;ьных разделах 4 – 8 стандарта ISO<= span style=3D'font-size:14.0pt'> 9001 могут быть сопоставлеl= 5;ы подобные по содержанию разделы в поэта= 087;ной модели CMMI. Общность процессов и требований состоит в подобии: терминологl= 0;и, структуры, рекомендуеl= 4;ых процессов управления, планированl= 0;я, учета доступных ресурсов, ре= 072;лизации процессов, о= 094;енивания и организациl= 0; специалистl= 6;в. Процессы, которые развиваютсn= 3; и детально комментируn= 2;тся процессами их реализац = 80;и в стандарта = 93; ISO<= span style=3D'font-size:14.0pt'> 9004:2000 и ISO 90003:2004, а также в представлеl= 5;ном выше профил = 77;, включающем около пятид = 77;сяти стандартов </sp= an>ISO<= span style=3D'font-size:14.0pt'> (см. Приложение 1), однако не всегда предусмотрk= 7;ны в рекомендацl= 0;ях и ссылках CMMI= .<o:p></o:p> При практическl= 6;й реализации проектов и о= 073;еспечении ж= ;изненного цикла сложных ПС = 088;азработчик&= #1072;м и поставщикаl= 4; может быть сложно определить = 80; выделить дл= 03; применения преимущестk= 4;а моделей CMMI или= профи= 083;я стандартов </sp= an>ISO. В зависимостl= 0; от традиций предприятиn= 3; и особеннос = 90;ей проекта ПС зачастую целес= ообразно использоваm= 0;ь как основно = 81; полный профил= ь стандартов </sp= an>ISO, а дл&#= 1103; оценивания заказчикамl= 0; уровня зрел = 86;сти менеджментk= 2;, организациl= 6;нного и технологичk= 7;ского обеспечениn= 3; проектов ПС применять конкретные рекомендацl= 0;и CMMI. Эти рекомен = 76;ации могут эффективно использоваm= 0;ься при сертифика = 94;ии качес= ;тва процессов на предприя = 90;иях, обеспечиваn= 2;щих ЖЦ ПС, как альтернатиk= 4;а или наряду с сертификацl= 0;ей по комплекс = 91; стандартов менеджментk= 2; ISO= 9000, в зависимостl= 0; от особенностk= 7;й проекта и тр= 077;бований заявителя н = 72; сертификацl= 0;ю программноk= 5;о продукта и/или технологии обеспечениn= 3; его жизненн = 86;го цикла.<o:p></o:p> При подготовке системы качества предприятиn= 3;, целесообраk= 9;но учитывать и использоваm= 0;ь совокупносm= 0;ь рекомендацl= 0;й ряда станда = 88;тов, поддерживаn= 2;щих и детализируn= 2;щих базовые ста = 85;дарты серии ISO 9000, в которую входят – ISO 10005, ISO 10006, ISO 10013, ISO 10011. <o:p></o:p>= Стандарт ISO<= span style=3D'color:windowtext'> 10006:1997 – Руководствl= 6; по качеству при управле = 85;ии проектом – содержит принципы управления качеством различных п = 86; содержанию крупных про = 77;ктов. В нем изложены рекомендацl= 0;и по админист = 88;ативному управлению качеством процесса проектировk= 2;ния сложных объектов и в том числе программныm= 3; средств. Приводятся определениn= 3; процесса, продукции и плана управления проектом, а также общие = 093;арактерист&= #1080;ки организациl= 0; и фазы проек= 090;ирования. Обеспечениk= 7; качества управления проектом представлеl= 5;о группой про = 94;ессов, для каждого из которых приводятся = 87;одробные рекомендацl= 0;и по их реализ= 072;ции и контролю качества вы = 87;олнения. <o:p></o:p></spa= n> </= span>В стандарте ISO 10013:1= 995 – Руководящиk= 7; указания по = 088;азработке руководств по качеству = 211; изложены рекомендацl= 0;и по подготовке конкретногl= 6; Руководствk= 2; по качеству, адаптироваl= 5;ного к определен = 85;ым потребностn= 3;м предприятиn= 3; и пользоватеl= 3;ей. Созданное в = 088;езультате Руководствl= 6; должно отражать до = 82;ументирова&#= 1085;ные процедуры системы кач = 77;ства конкретногl= 6; предприятиn= 3; или проекта = 074; соответствl= 0;и с общими тре= 073;ованиями стандартов серии ISO 9000. В этом документе должны быть изложены: це= 083;и конкретной = 89;истемы качества проекта или предприятиn= 3;; документирl= 6;ванные процедуры этой систем = 99;; организациn= 3; процессов утверждениn= 3;, изменения и применения данного Руководствk= 2;. В стандарте предложена = 87;одробная типовая структура и рекомендуеl= 4;ое содержание разделов такого документа. <o:p></o:p> = В стандарте ISO 10005:1995 – Администраm= 0;ивное управление качеством. <sp= an style=3D'mso-spacerun:yes'> Руководящи= 077; указания по Программе качества – представлk= 7;ны конкретныk= 7; рекомендацl= 0;и по структур = 77; и содержани= 02; разделов в П= 088;ограмме обеспечениn= 3; качества продукции, в &#= 1089;оответстви= и с базовыми т= 088;ебованиями стандарта ISO 9001,<s= pan style=3D'mso-spacerun:yes'> а также приме = 88;ы документалn= 0;ного оформления таких Программ. Для эффективноk= 5;о применения его следует = 072;даптироват&= #1100; к характерисm= 0;икам объектов и среды применения конкретногl= 6; предприятиn= 3; или проекта. Прежде всег = 86;, необходимо оставить в рабочей версии этог = 86; стандарта разделы и положения, которые целесообраk= 9;но непосредстk= 4;енно использоваm= 0;ь для обеспечениn= 3; качества ко = 85;кретных изделий. Адаптация стандарта для конкрет = 85;ых предприятиl= 1; или проекто = 74; может выполнятьсn= 3; путем сокращения = 80; конкретизаm= 4;ии некоторых положений. После этого Программа качества должна быть сформироваl= 5;а и оформлена как самостоятеl= 3;ьный регламентиl= 8;ующий документ, согласованk= 2; с заказчико = 84;, утверждена = 88;уководство&#= 1084; предприятиn= 3; и доведена д= 086; сведения всех участников проекта для практическl= 6;го применения. При сертифи = 82;ации системы качества предприятиn= 3; должно проверятьсn= 3; наличие и практическl= 6;е использоваl= 5;ие всех положе = 85;ий утвержденнl= 6;й рабочей версии Прог = 88;аммы качества.<o:p></o:p>= = Груп= па стандартоk= 4; = - ISO 10011:1-3:1990 – Руководящиk= 7; положения п = 86; проверке систем качества – определяет основные требования = 82; процессам и специалистk= 2;м по оценке систем качества предприятиn= 3; на соответс = 90;вие стандартам серии ISO 9000. В них изложены основные принципы, критерии и методики, а также руководящиk= 7; положения для разработки, планированl= 0;я и ведения документацl= 0;и при проверк = 77; систем каче = 89;тва предприятиn= 3;. Определены обязанностl= 0; и ответстве = 85;ность независимыm= 3; инспектороk= 4; по проверке системы кач = 77;ства, требования = 82; ним, порядок и критерии оценки и выбора инспектороk= 4;, их аттестац = 80;и и условия выдачи свидетельств для допуска к инспектироk= 4;анию. Для независ = 80;мой и объективн = 86;й оценки системы качества предприятиn= 3; или проекта рекомендуеm= 0;ся проводить специальныl= 1; отбор испытателеl= 1; – инспектор = 86;в по сертифик = 72;ции. В соответст = 74;ии со стандартом </sp= an>ISO<= span style=3D'font-size:14.0pt'> 10011-2 кандидаты в инсп = 77;кторы по проверке = 089;истем качества должны прод = 77;монстриров&#= 1072;ть способностn= 0; четко и быст= 088;о выражать концепции и идеи в устной и письменно = 81; форме. Они должны пройти обуч = 77;ние, дающее им знания и квалификацl= 0;ю, необходимыk= 7; для проведения испытаний и управления проверками систем каче = 89;тва. <o:p></o:p> <o:p> = ;</o:p> <h1><a name=3D"_Toc508102456"></a><a name=3D"_Toc508102229">3.3. Стандарты о = 90;крытых систем, регламентиl= 8;ующие структуру и интер= ;фейсы программнm= 9;х средств</a> <o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'><o:p> </o:p> Рядом зарубежных организациl= 1; и промышленнm= 9;х фирм под руководствl= 6;м IEEE с 1990 года ведется активная разработка последоватk= 7;льных версий стандартов = 80;нтерфейсов открытых систем POSIX (Port= able operating system<= /span> interfaces). Выполнена большая работа по пересмотру, расширению = 80; реорганизаm= 4;ии около двадцати базовых спе = 94;ификаций POSIX 1990 - 1998 года IEEE 1003. Улучшена с = 80;стематизац&#= 1080;я и структура стандартов, усовершенсm= 0;вовано удобство их применения пользоватеl= 3;ями. В результат = 77; подготовлеl= 5; комплексныl= 1; проект фундаментаl= 3;ьного международl= 5;ого стандарта и = 79; четырех крупных час = 90;ей ISO 9945:1-4:2003 (IEEE 1003.1 – 2003), объемом свыше трех т= 099;сяч страниц. Настоящий стандарт –</spa= n> совмесm= 0;ная разработка </sp= an>IEEE= и The Open <sp= an lang=3DEN-US style=3D'font-size:14.0pt;mso-ansi-language:EN-US'>Group</span= >, он явля= 077;тся одновременl= 5;о стандартом </sp= an>IEEE= , станда = 88;том ISO и стандартом </sp= an>Open= Group Technical.<o:p></o:p> = Цель документа – стандартизk= 2;ция в программноl= 1; инженерии обеспечениn= 3; переносимоl= 9;ти программ на уровне исходных те = 82;стов. В нем определены основные интерфейсы операционнm= 9;х систем и окружения, и= 085;терфейсы командного интерпретаm= 0;ора, а также прог= 088;аммы общих утилит. Три отдельных к = 88;упных тома включают: ба= 079;овые определениn= 3;; системные интерфейсm= 9;; команды управления = 80; сервисные программы (утилиты). Кроме того, имеется бол= 00;шой четвертый том общего обоснованиn= 3; выбранных решений системы POSIX. Важными свойствами = 88;азработанн&#= 1099;х программныm= 3; интерфейсоk= 4; являются целостностn= 0;, модул= ;ьность их построен = 80;я и параме = 90;ризуемость</= span>. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Стандарты открытых систем – POSIX регламентиl= 8;уют совокупносm= 0;ь базовых, системных сервисов дл= 03; обеспечениn= 3; унифицировk= 2;нных интерфейсоk= 4; прикладных программ, специфицирl= 6;ванных для языка С, командно= 075;о языка и совокупносm= 0;и служебных п = 88;ограмм. Основная цель </spa= n>– <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>сделат= 100; программы переносимыl= 4;и на уровне различных и = 89;ходных языков. У каждого интерфейса программ существует вызывающая = 80; вызываемая = 89;торона, стандарты POSIX ориентировk= 2;ны преимущестk= 4;енно на формализ = 72;цию вызывающей стороны. Мобильностn= 0; приложений должна обеспечиваm= 0;ься благодаря применению большого чи = 89;ла стандартизl= 0;рованных системных интерфейснm= 9;х сервисов и возможностl= 0; динамическl= 6;го выяснения характерисm= 0;ик целевой платформы и подстройки под них инте= 088;фейсов приложений.<o:p= ></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> При формированl= 0;и концепm= 4;ии стандартов POSI= X </span= >были поставl= 3;ены следующие задачи:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>сод= ействовать облегчению = 80; автоматизаm= 4;ии переноса кода готовы = 93; прикладных программ на иные платфо = 88;мы;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>спо= собствоватn= 0; определениn= 2; и унификациl= 0; интерфейсоk= 4; программныm= 3; компонентоk= 4; заранее при проектировk= 2;нии программныm= 3; средств, а не только в процессе их = 088;еализации;<o:p></= o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>сох= ранять по возможностl= 0; и учитывать все главные, созданные ранее, унасл= 077;дованные и используемm= 9;е программнm= 9;е средства и компоненты;<o:p= ></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>опр= еделять необходимыl= 1; минимум интерфейсоk= 4; компонентоk= 4; и комплексо = 74; программ, дл= 103; ускорения создания и расширения программныm= 3; продуктов, а также для анализа, одобрения и утверждениn= 3; документов;<o:p= ></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>раз= вивать стандарты в направлениl= 0; обеспечениn= 3; коммуникацl= 0;онных сетей, распределk= 7;нной обработки данных и защиты= информациl= 0;;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>рек= омендовать ограничиваm= 0;ь использоваl= 5;ие объектного кода для про= 075;рамм в простых системах.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Разработчl= 0;ки новых версий стандартов группы POSIX тщаm= 0;ельно учитывали и = 93; предысториn= 2; и наличие множества унаследоваl= 5;ных, созданных и развиваемыm= 3; компонентоk= 4; и комплексо = 74; программ, удовлетворn= 3;ющих более ранни = 84; версиям эти = 93; стандартов. = 042; процессе развития стандартов соблюдался принцип обратной совместимоl= 9;ти – новые инте= 088;фейсы добавлялисn= 0; так, чтобы они не конфл= 080;ктовали со старыl= 4;и. Однако полностью это не удалось реа = 83;изовать, и некоторые интерфейсы = 74; повторно применяемыm= 3; программаm= 3; необходимо корректироk= 4;ать при их испол= 100;зовании в новых прог= 088;аммных средствах. <o:p></o:p= > Цель данно = 81; версии стандарта состоит в том, чтобы минимизироk= 4;ать дополнителn= 0;ную работу для разработчиl= 2;ов прикладных программ. Те= 084; не менее, поскольку к = 72;ждая историческk= 2;я реализация стандарта н = 77;избежно подвергаетl= 9;я изменению, пусть даже н= 077;значительн&= #1086;му, прикладным программам также неизб = 77;жно предстоит изменяться, чтобы прийт = 80; в соответст = 74;ие. Концептуалn= 0;но, этот стандарт описывает набор фундаментаl= 3;ьных услуг, необходимыm= 3; для эффективноl= 1; разработки прикладныm= 3; программ. Доступ к эти= 084; услугам обеспечиваl= 3;ся определениk= 7;м интерфейса, = 089; использоваl= 5;ием языка программирl= 6;вания Cи, процессора командного языка, и стандартныm= 3; сервисных программ (утилит), кото&= #1088;ые устанавливk= 2;ют стандартнуn= 2; семантику и синтаксис интерфейсоk= 4;. Этот станда = 88;т предназначk= 7;н для всех, кто по роду свое= 081; деятельносm= 0;и связан с операционнm= 9;ми системами, базирующl= 0;мся на UNIX. <o:p></o:p> Цель состояла также в том, чтобы продвинуть мобильностn= 0; прикладных программ по всей област = 80; применения операционнl= 6;й системы UNIX, развивая ясный, после= 076;овательный, и однозначныl= 1; стандарт дл= 03; спецификацl= 0;и интерфейса переносимоl= 1; операционнl= 6;й системы, основанной на документ = 72;ции системы UNIX. Этот стандарт систематизl= 0;рует все существующl= 0;е типовые формулировl= 2;и операционнl= 6;й системы UNIX. Стандарт бы = 83; разработан для того, чтобы прогр = 72;мма, написанная = 80; транслировk= 2;нная для исполне = 85;ия в одной конкретной версии ОС, могла быть также транс = 83;ирована для другой версии ОС. Однако этот стандарт не = 075;арантирует, что используемm= 9;й код (объектн= 099;й) даст соотве = 90;ствующий результат при другой ОС, нежели той, для которой программа была трансл = 80;рована, даже при идентичном аппаратном обеспечениl= 0;.<o:p></o:p> Разработчl= 0;ки данного стандарта стремились добиться возможностl= 0; наиболее широкого применения данного стандарта к = 86; всему диапа = 79;ону уже существ = 91;ющих и потенциал= 00;ных операционнm= 9;х систем. Однако существоваl= 3;о согласованl= 5;ое мнение по поводу того, какой набор функций, типов, определениl= 1; (дефиниций) и концепций предназначk= 7;н для формиро = 74;ания того интерфейса, который является об = 97;им для большинствk= 2; историческl= 0; сложившихсn= 3; типов реали = 79;ации ПС. Предыдущие стандарты и их модифика = 94;ии выявили множество несогласовk= 2;нных областей, чт= 086; в основном устранено = 74; данном вари = 72;нте. Пересмотреl= 5;ное издание стандарта стремится минимизироk= 4;ать количество изменений, касающихся реализаций, которые соответствm= 1;ют более ранни = 84; версиям одобренных стандартов, необходимыm= 3; для приведения их в соответ= 089;твие с настоящим стандартом. <o:= p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Новую версию международl= 5;ых стандартов POSIX составляют аннотироваl= 5;ные ниже четыре части стандартов </sp= an>ISO 9945:1-4:2003 – ИТ. Интерфейсы = 87;ереносимых операционнm= 9;х систем. Ч.1. Базовые определениn= 3;. Ч.2. Системные интерфейсы. Ч.3. Команды управления = 80; сервисные программы. Ч 4. Обоснованиk= 7;.<o:p></o:p> Стандарт ISO 9945-1:= 2003 <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- содержит основные концептуалn= 0;ные определениn= 3; и подробные пояснения м = 77;тодов реализации интерфейсоk= 4; для обеспеч = 77;ния мобильностl= 0; компонентоk= 4; и комплексо = 74; программ, общее для всех томов оглавление стандарта, в том числе сервисные соглашения = 80; определениn= 3; заголовков языка Си. В большом разделе <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- концепция изложены: базовые директории; файловая иерархия; сетевое взаимодейсm= 0;вие; измерение времени и синхронизаm= 4;ия; процессы повторного использоваl= 5;ия компонентоk= 4;; политика очередей и применение семафоров. Далее выдел = 77;ны разделы:<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>описание синтаксиса = 80; организациl= 0; данных в файлах для с= 080;стемных интерфейсоk= 4; и взаимодейсm= 0;вия с терминаламl= 0;;<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>характериl= 9;тики переносимm= 9;х компонентоk= 4;, язык кодиро = 74;ания, описание фа = 81;лов;<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>локальные переменные, определениn= 3; и грамматик = 72;;<o:p></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>описание переменных окружения, интер= ;национализ = 72;ция переменных;<o:p= ></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>контекстнl= 6;-независимы&#= 1081; синтаксис представлеl= 5;ия характерисm= 0;ик переменных компонентоk= 4;, определениn= 3; регулярных выражений, генерация требований, базис и грам= 084;атика выражений, продленные выражения; <o:p></o:p= > <![if !supportLists= ]>- = &nb= sp; <![endif]>структура директорий, файлов и устройств, т= 080;пы терминалов;<o:p= ></o:p> <![if !supportLists= ]>- = &nb= sp; <![endif]>базовые интерфейсы типов терминалов, параметры в = 86;зможных устройств;<o:p></o:p>= <![if !supportLists= ]>- = &nb= sp; <![endif]>конвенция и руководствl= 6; по синтаксису аргументов утилит;<o:p></o:p> <![if !supportLists= ]>- = <![endif]>содержаниk= 7; функций прототипов, описа= ;ние символьных констант, макросы, препроцессl= 6;ры, типы опреде = 83;ений, форматы вхо = 76;ов. <o:p></o:p> </spa= n>Сm= 0;андарт ISO 9945-2:2003 <sp= an style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- Системные интерфейсы – уто= чняет и детализир = 91;ет: концепцию переносимоl= 9;ти и принципы е= 105; обеспечениn= 3; путем унифи = 82;ации интерфейсоk= 4; прикладных программ с о= 087;ерационным&= #1080; системами, </s= pan>функции обслуживанl= 0;я, ориентировk= 2;нные на язык программирl= 6;вания Си, функционалn= 0;ные вопросы, в том числе мобильностn= 0;, обработка ошибок, и устранение ошибок.&nbs= p; Он содержи = 90; три крупных раздела:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>введение; <o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>содержани= ;е основной информации; <o:= p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>системные интерфейсы. <o:= p></o:p> Документ предназначk= 7;н для разрабо = 90;чиков приложений, = 074; которых необходимо обеспечить мобильностn= 0; программ и данных, для разработчиl= 2;ов и пользоватеl= 3;ей операционнm= 9;х систем, а также для покупателеl= 1; вычислитеl= 3;ьной техники и программныm= 3; средств. Основная цель станда = 88;та <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-fareast-font-family:"MS Mincho";mso-hansi-font-family: "Times New Roman";mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > унифицировk= 2;ть интерфейсы приложений и связи= с окружением ядра операционl= 5;ой системы путем формализацl= 0;и описаний внутренних = 80; внешних интерфейсоk= 4; на базовом языке программирl= 6;вания Си. Концептуаl= 3;ьно представлеl= 5;о описание синтаксиса = 80; семантики взаимосвязk= 7;й, испол= ;ьзуемых при проектировk= 2;нии переносимыm= 3; прикладных программ. Унификациn= 3; ориентировk= 2;на на версии UNIX, а такk= 8;е на другие операционl= 5;ые системы, совместимыk= 7; по интерфей = 89;ам с версиями UNIX. Разработчиl= 2;и стандарта стремились предусмотрk= 7;ть все потенциалn= 0;но возможные фун-кции</sp= an> взаимодейl= 9;твия прикладных программ с ядром ОС на различных аппаратных платформах, = 074; автономных, сетевых и ра= 089;пределенны&= #1093; информациоl= 5;ных системах. Для этого предс = 90;авлено содержание 1123 интерфейсоk= 4;, включающих: описание, типовую структуру, возможные ошибки, примеры и обоснованиk= 7; каждого. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Языково-ор = 80;ентированн&#= 1099;е услуги= и интерфейсы для языка Си в стандарте = 89;остоят из двух частей: ядра взаимодейсm= 0;вующего с ядром опера= ;ционной системы на языке Си и расширения для взаимодейсm= 0;вия с прикладны = 84;и программамl= 0;, реализоваl= 5;ными на различны = 93; языках. Первоначаl= 3;ьная, жесткая ори = 77;нтация стандартоk= 4; POSIX на ОС UNIX&n= bsp; в последую = 97;ем изменилась = 80; расшириласn= 0; на любые опе= 088;ационные среды, обесп= 077;чивающие реализацию концепции о = 90;крытых систем. Отмечается целесообраk= 9;ность применения для взаимод = 77;йствия с внешней средой= концепции и совокупноl= 9;ти стандартов, являющихся развитием базовой эталонной модели взаимосвяk= 9;и открытых систем (ВОС) <= span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- ISO 7498<s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>.<o:p></o:p> В третьей части стандаl= 8;та ISO 9945-3:2003 – Основные кома= нды управления = 80; сервисные программы (Shell and utilities) – изложено конкретное представлеl= 5;ие команд опер = 72;ционной системы и утилит, обесп= ;ечивающих унифицировk= 2;нное взаимодейсm= 0;вие с мобильным = 80; прикладнымl= 0; программаl= 4;и, опред= еления для стандартноk= 5;о источника кодового уровня интерфейса командного интерпретаm= 0;ора ("shell") и стандартныk= 7; утилиты для прикладных программ. С= 090;андарт содержит че = 90;ыре раздела: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>введение; <o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>описание языка управления; <o:= p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>пакет обслуживанl= 0;я окружения; <o:p></o:p= > <![if !supportLists]>- = &nb= sp; <![endif]>сервисные программы – утилиты. <o:p></o:p> Цель этой части стандарта к = 86;нкретизиро&#= 1074;ать интерфейсы прикладных программ на уровне команд, для интерпретаm= 0;ора командного языка, и полный набо = 88; сервисных п = 88;ограмм – утилит. Он специфицирm= 1;ет интерфейсы операционнm= 9;х систем на уровне прог = 88;аммных текстов и к= 086;дов. Стандартизl= 0;рованный командный язык = Shell – средство дл= 03; подготовки небольших мобильных процедур и и= 093; быстрой интерактивl= 5;ой отладки. В ра&#= 1079;витой среде, возможн= ;о объединять команды в цепочки с фильтрациеl= 1; промежуточl= 5;ых результатоk= 4;. Каждая утилита содержит: оп= 080;сание структуры; применение; операнды; вх= 086;дные файлы; окруж= 077;ние. Факультатиk= 4;ные утилиты расширяют возможностl= 0; для пользоватеl= 3;ей мобильных приложений по связи с внешним окр = 91;жением. В терминах я= 079;ыка Си (стандарт <s= pan style=3D'mso-bidi-font-weight:bold'>ISO 9899:1990) описаны языково-нез = 72;висимые услуги инте = 88;фейсов для переносимыm= 3; приложений = 80; связи с внешним окруж= ;ением при представлеl= 5;ии интерфейсоk= 4; приложений на различны = 93; языках высо = 82;ого уровня. Команды и утилиты содержат конкретные механизмы н = 72; уровне операторов для выполнения операций: сравнения, вывода на пе= 095;ать и на экран файлов, редактироk= 4;ания файлов, вычисления выражений, сортировки данных, опре= 076;еления очередностl= 0; исполнения сигналов и д= 086;ступа к информациl= 0; о среде. Можно выде = 83;ить:<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ути= литы среды взаимодейсm= 0;вия программ;<o:p></o:p>= <![if !supportLis= ts]>- = <![endif]>упр= авляющие утилиты, поддерживk= 2;ющие мобильностn= 0; программ и связь внешних пользоватеl= 3;ей с асинхронн = 99;ми терминалаl= 4;и;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ути= литы для взаимодейсm= 0;вия комплексов = 87;рограмм;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>язы= ково-незави = 89;имые системные услуг= ;и для прикладных программ на = 085;ескольких языках программирl= 6;вания высокого уровня. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> Четвертая часть стандарта ISO 9945-4:2003 – Обоснованиk= 7; – содержит группу из пя= 090;и крупных приложений:<o:p= ></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>обоснованl= 0;е базовых определениl= 1; – приложени = 77; А;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>обоснованl= 0;е системных интерфейсоk= 4; – приложени = 77; В;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>обоснованl= 0;е команд управления = 80; сервисных программ-ут = 80;лит – приложени = 77; С;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>рассмотреl= 5;ие переносимоl= 9;ти – приложени = 77; D;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>рассмотреl= 5;ие субпрофl= 0;лей – приложени = 77; Е.<o:p></o:p> В перечисленl= 5;ых приложенияm= 3; подробно разъясняютl= 9;я базовые положения с = 90;андартов POSIX, обосновываn= 2;тся формализовk= 2;нные в них решения. Простра= ;нные пояснения, которые не слишком вписывалисn= 0; в остальные части документа, содержат историческl= 0;е комментариl= 0; по тексту стандарта, разъяснениn= 3; причин, по которым те или иные сво= 081;ства, признаки и компоненты были включены в стандарт или были отвергнуты разработчиl= 2;ами.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Параллельl= 5;о с подготовкоl= 1; и внедрение = 84; новых четырех ста = 85;дартов группы POSIX, действуют = 80; применяютсn= 3;, представлеl= 5;ные ниже, утвержденнm= 9;е базовые междунаро = 76;ные стандарты, углубляющl= 0;е некоторые возможностl= 0; и облегчающиk= 7; создание мо = 73;ильных приложений.</sp= an><o:p></o:p></span= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = 42; стандарте </s= pan>ISO 14252:1996</s= pan> <span style=3D'font-size:14.0pt;font-= family: Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font-family:"MS = Mincho"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > Руководствl= 6; по POSIX окруженl= 0;ю открытых си = 89;тем (OSE) – изложена идеология и модел= ;ь создания м = 86;бильных программныm= 3; средств, которое детализируk= 7;т для пользов = 72;телей модель комплекса стандартов POSI= X, а также взаимодейсm= 0;вующих с нимl= 0; стандартов де-юре, де-фак&= #1090;о и спецификацl= 0;й, необходимыm= 3; для создани= 03; переносимыm= 3; приложений. Модель отра = 78;ает принципы построения интерфейсоk= 4; прикладных программ с платформой </sp= an><span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- операционнl= 6;й системой, через которую осуществлn= 3;ется взаимодейl= 9;твие с компонентаl= 4;и внешнего окружения. С= 095;итается, что прикладные программы н = 77;посредстве&#= 1085;но не взаимодейсm= 0;вуют с внешним окружением, а связаны с ни= 084; только чере = 79; операционнm= 1;ю систему. Разработка приложений предполагаk= 7;тся в кросс-р = 77;жиме, то есть платформа разработки R= 11; инструментk= 2;льная может не сов= 087;адать с платформо = 81; исполнения (применения) программ (объектной – целевой). Результат компиляции программы н = 72; инструментk= 2;льной платформе может быть перенесен для исполне = 85;ия на целевую платформу. <o:p></o:p= > <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Определяюm= 7;ими являются дв = 72; интерфейса между тремя = 073;азовыми компонентаl= 4;и: между прикладныl= 4;и программаl= 4;и и платформой <span style=3D'font-size:14= .0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font= -family: "MS Mincho";mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"T= imes New Roman"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > операционl= 5;ой системой (API) l= 0; между платф = 86;рмой и внешним ок= 088;ужением (EEI). Определенm= 9; общие= ; функции <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- услуги платформы для этих k= 4;заимодейст= 074;ий. Внешнее окружение включает ко = 84;поненты человеко-ма = 96;инного взаимодейсm= 0;вия с пользоватеl= 3;ями, компоненты информациоl= 5;ного взаимодейсm= 0;вия с внешними устройстваl= 4;и ЭВМ и с компонентаl= 4;и, обеспечиваn= 2;щими коммуникацl= 0;ю с внешней средой. Эти интерфейсы и услуги более детально формализовk= 2;ны соответствm= 1;ющими стандартамl= 0; POSIX.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = Стандар= ;т включает также общие принципы и руководствl= 6; по формированl= 0;ю и описанию сложных согласованl= 5;ых профилей и по обеспеченl= 0;ю непро= ;тиворечиво = 89;ти их интерфейсоk= 4; с внешним окружением.<o:p= ></o:p> <![if !supportLis= ts]>- = <![endif]>под= держивающиk= 7; непосредстk= 4;енное взаимодейl= 9;твие прикл= ;адных программ с пользоватеl= 3;ями, регламентиl= 8;ующие интерфейсы = 89; виртуальныl= 4;и терминаламl= 0; и графическ = 80;е системы;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>обеспечи&= #1074;ающие администраm= 0;ивное управление файловыми с = 80;стемами и различным = 80;, в том числе, распределеl= 5;ными базами данных;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>регламен&= #1090;ирующие телекоммуl= 5;икацию и обмk= 7;н данными на верхних уровнях эталонной модели ВОС;</s= pan><o:p></o:p> <![if !supportLis= ts]>- = <![endif]>обе= спечивающиk= 7; аттестацию и безl= 6;пасность применения = 80;нформацион&#= 1085;ых технологий, программ и данных в соответствl= 0;и со стандарт = 72;ми ВОС и криптографl= 0;и.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> Станд= 072;рт ISO 13210:1998</s= pan> <span style=3D'font-size:14.0pt;font-= family: Symbol;mso-ascii-font-family:"Times New Roman";mso-fareast-font-family:"MS = Mincho"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > Методы тестированl= 0;я для оценки соответстk= 4;ия стандартам POSI= X <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-fareast-font-family:"MS Mincho";mso-hansi-font-family:"Times New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>- со&= #1076;ержит общую методологиn= 2; тести= ;рования для проверки соответстk= 4;ия интерфейсоk= 4; прикладных программ ст = 72;ндартам POSIX. Представлk= 7;ны принципы формироваl= 5;ия наборов тесто= ;в и предлагаетl= 9;я методика развития си = 89;темы тестов для контроля со = 79;даваемых приложениl= 1; на соl= 6;тветствие ISO 9945. В методе тестированl= 0;я выделены: по= 076;готовка тестов; процедуры тестироваl= 5;ия; оформление докум= ;ентов, удостоверяn= 2;щих соответстk= 4;ие станд= ;артам. Определены и кратк= ;о представлеl= 5;ы три основны = 93; уровня сложности тестированl= 0;я: исчер= ;пывающий; достаточнl= 6; полный; оцен= 086;чный – для установленl= 0;я общих характерисm= 0;ик качества. Подчеркивk= 2;ется, что предлагаемm= 9;е методы не гарантируn= 2;т абсолютное соответствl= 0;е стандартам, так как исчерпываюm= 7;ее тестированl= 0;е невозможно по техническиl= 4; и экономиче = 89;ким причинам. Приводятся рекомендацl= 0;и по:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>кла= ссификации тестовых сценариев и утверждениl= 1;;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>под= готовке описаний детерминиl= 8;ованных тестов и тестов для проверки структурныm= 3; конструкциl= 1;;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>код= ированию и представлk= 7;нию результатl= 6;в тестироваl= 5;ия во взаимосвязl= 0; с исходными тестами;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>фор= мированию удостовереl= 5;ия о соответст = 74;ии интерфейсоk= 4; прикладных программ стандартам POSI= X.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = 42; стандартах POSIX даются ссылки на многие стандарты ISO, ANSI и де-факто. В ре&= #1079;ультате полная совокупносm= 0;ь стандартов, поддерживаn= 2;щих проектировk= 2;ние мобильl= 5;ых программ в разных классах отк = 88;ытых систем, возрастает. В конкретных прикладных разработкаm= 3; каждый раз необходима только неко = 90;орая, относителn= 0;но небольшая часть= ; из ниm= 3;, которую цел = 77;сообразно выделять в соответствm= 1;ющий проблемно-о = 88;иентирован&#= 1085;ый профиль. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n><o:p></o:p> <o= :p></o:p> <h1> <= /span><a name=3D"_Toc508102457"></a><a name=3D"_Toc508102230">Лекция 4. Системное проектировk= 2;ние программныm= 3; средств</a></h1> <o:p> </o:p> <h1> &n= bsp; <a name=3D"_Toc508102458"></a><a name=3D"_Toc508102231">4.1. Цели = 80; принципы системного проектировk= 2;ния программнm= 9;х средств</a></h1> </spa= n><o:p></o:p> Комплекс ф = 86;рмально организоваl= 5;ных мероприятиl= 1; по достижен = 80;ю единой цели создания сложной системы с требуемыми = 93;арактерист&#= 1080;ками качества при ограниченнm= 9;х ресурсах получил название = - проект. Цель управления проектом = - рациональнl= 6;е использоваl= 5;ие и предупрежk= 6;ение потер= ;и ресурсов путем сбалансироk= 4;анного распределеl= 5;ия их по частны= 084; работам на протяжении всего жизненного цикла объек = 90;а с заданным качеством. Управлениk= 7; проектом = - это особый вид деятельносm= 0;и, включающий = 87;остановку задач, подготовкm= 1; решений, плани= ;рование, организациn= 2; и стимулировk= 2;ние специалистl= 6;в, контроль хода работ и использоваl= 5;ия ресурсов пр = 80; создании сложных систем.<o:p></o:p> = Целевое управление проектами возникло из необходимоl= 9;ти разрабатывk= 2;ть и реализовывk= 2;ть сложные системы с заданными функциями в максимальнl= 6; короткие сроки при ограниченнm= 9;х ресурсах. Критическl= 0;м параметром планированl= 0;я и управлени= 03; проектами обычно является вр = 77;мя. Поэтому в лекциях по программноl= 1; инженерии большое внимание со = 89;редоточено на конкретном планированl= 0;и сложных проектов, длительносm= 0;ь разработки которых могут= ; соста= ;влять несколько месяцев или даже годы. Задачи целев= ;ого управлениn= 3; такими работами = - сводитn= 0; воедино усилия исполнителk= 7;й - сп = 77;циалистов разной квал = 80;фикации, подрядчикl= 6;в и субподряд = 95;иков, добиваясь, чтобы они выступали как команда при создани = 80; компонентоk= 4; систем, а не как разрозн = 77;нная группа функ = 94;иональных специалистl= 6;в. В результате должны обеспечиваm= 0;ься концептуаl= 3;ьная целос= ;тность системы и высокое кач = 77;ство решения главных задач при сб= 072;лансирован&= #1085;ом использоваl= 5;ии ресурсов на все функционаl= 3;ьные задачи. <o:p></o:p> Для интеграции усилий спец = 80;алистов и эффективноk= 5;о использоваl= 5;ия ресурсов проекта долже= ;н выделяться лидер -</span= > менеджер, управляющиl= 1; проектом. Он должен акти = 74;но участвоватn= 0; в планированl= 0;и, организациl= 0; и контроле основных внутренних = 80; внешних организациl= 6;нных мероприятиl= 1;, необходимm= 9;х для достиже = 85;ия основной цели проект = 72;. Все рk= 7;сурсы и исходные данные, необходимыk= 7; для эффекти = 74;ного выполнения проекта, управ= ;ляющий получает от функционалn= 0;ных подразделk= 7;ний и специалистl= 6;в. Задача= менеджера проекта наряду с прямыми воз = 76;ействиями на подчиненныm= 3; и координациk= 7;й их работ = - стимулироk= 4;ать и контролир = 86;вать активность прямых= горизонтаl= 3;ьных связей межд = 91; исполнителn= 3;ми частных работ. Для того чтобы п= 088;оцесс достижения целей был рациональнm= 9;м, лицо, принимающеk= 7; решение (управляющи = 81;) должно имет= 00; выбор среди альтернатиk= 4;ных действий, ведущих к цели. Наличи= 077; альтернатиk= 4; и сомнения п= 086; поводу того,<sp= an style=3D'mso-spacerun:yes'> какая из них лучше,<s= pan style=3D'mso-spacerun:yes'> определяюm= 0; возможностn= 0; эффективноk= 5;о решения проблем и оптимизациl= 0; путей их дос= 090;ижения.<o:p></o:p> Методологl= 0;ческой базой целев = 86;го планированl= 0;я и управлени= 03; проектами П = 57; является системный а = 85;ализ, который предполагаk= 7;т:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 73;следование объектов и среды проектировk= 2;ния, для предваритеl= 3;ьной формализацl= 0;и целей, назначения = 80; задач проекта ПС;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>и = 89;следование и сопоставлk= 7;ние альтернатl= 0;вных действий, к= 086;торые должны приводить к достижению поставленнm= 9;х целей проек = 90;ирования;<o:p></o:p></sp= an> <![if !supportLists]>- &nb= sp; <![endif]>с = 88;авнение альтернатиk= 4; по велич= ;ине достигаемоk= 5;о эффекта проекта в за= 074;исимости от затра= ;т на его достижениk= 7; (желательн = 86;, по показателn= 2; "эффективно= ;сть/<sp= an style=3D'font-size:14.0pt'>стоимос= ;ть");<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 95;ет и анализ влияния неопределk= 7;нностей характериl= 9;тик альтернатиk= 4;, определяющl= 0;х их выбор, на эффект проекта.<o:p></o:p> Чтобы найт = 80; и проанализиl= 8;овать все разумны = 77; альтернатиk= 4;ы, обычно нед = 86;статочно одного специалистk= 2;, и неоk= 3;ходимо участие в сисm= 0;емном анали= ;зе специалистl= 6;в разной квалификацl= 0;и. Не во всех систем = 72;х и задачах оказываетсn= 3; доступным точный коли = 95;ественный анализ. Во многих, чаще всего особенно сл = 86;жных случаях, приходится ограничиваm= 0;ься качественнm= 9;м анализом свойств, фак= 090;оров и их влияния<sp= an style=3D'mso-spacerun:yes'> на конеч= ;ный результат и возможный эффект прое = 82;та. Поэтому оптимизациn= 3; решений и выбора альтернатиk= 4; может ограничиваm= 0;ься оценкой логических суждений экспертов. Б= 072;зой эффективноk= 5;о управления проектом является план, в котором задачи исполнителk= 7;й частных работ должн = 99; быть согласованm= 9; с выделяемы = 84;и для них ресурсами, а также между собой по результатаl= 4; и срокам их достижения. <o:p></o:p> Основна= ;я цель системного проектировk= 2;ния в программноl= 1; инженерии = - подготl= 6;вить, обосновать = 80; согласоватn= 0; замыслы и ре= 096;ения заказчика (потребител= 03;) и разработч = 80;ка (поставщика) о необходимоl= 9;ти, направлениn= 3;х и концепции создания ил = 80; модернизацl= 0;и существующk= 7;го ПС и изменен= 080;ях его качества. Мет&= #1086;ды и средства системного проектировk= 2;ния должны подготавлиk= 4;ать эффективнуn= 2; технологичk= 7;скую базу для обеспечениn= 3; всего жизненного цикла ПС тре= 073;уемого качества. Характерисm= 0;ики комплексов = 87;рограмм должны анализировk= 2;ться и формулиро = 74;аться в начале их жизненного цикла и определять эффективноl= 9;ть всех послед = 91;ющих процессов. Результатоl= 4; этих работ должны быть = 089;истемный проект, техн= 080;ческое задание и контракт на продолжениk= 7; разработки ПС или решен= 080;е о её нецелес= 086;образности и прекращениl= 0;. <o:p></o:p> Системное проектировk= 2;ние сложных комплексов программ яв = 83;яется фундаментоl= 4; для обеспечениn= 3; функционалn= 0;ной адекватносm= 0;и требованияl= 4; всего жизненного цикла ПС. От полноты и тщательносm= 0;и системного проектировk= 2;ния зависит эффективноl= 9;ть реализации функций сис = 90;емы и степень удовлетворk= 7;ния ожиданий и требований заказчика и пользоватеl= 3;ей. В последоватk= 7;льности выработки и подготовки = 82; реализации этих требов = 72;ний далее рассматривk= 2;ются в оснl= 6;вном три крупных этапа: <o:p></o:p> <![if !support= Lists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>о = 73;следование, системный анализ существующk= 7;й системы и выяk= 4;ление её недостат = 82;ов; <o:p></o:p> <![if !support= Lists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>о = 73;общение результатоk= 4; системного анализа и создание предваритеl= 3;ьной концепции новой или модернизирl= 6;ванной системы и её программныm= 3; средств;<o:p></o:p> <![if = !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>&#= 1088;азработка системного проекта комплекса программ и базы данных, определяющk= 7;го и конкретиз = 80;рующего цель, назнач= 077;ние и методы дальнейшегl= 6; детального проектировk= 2;ния и всего жизненного цикла ПС. <o:p></o:p> На этих этапах при относительl= 5;о небольших затратах должна определятьl= 9;я экономичесl= 2;ая эффективноl= 9;ть и рентабельнl= 6;сть всех послед = 91;ющих больших затрат ресурсов в жизненном цикле системы и могут быть предотвращk= 7;ны значительнm= 9;е потери ресурсов вследствие плохого пла = 85;ирования и неопредел = 77;нностей при реализации проекта. Системное проектировk= 2;ние способно остановить = 85;ерентабель&#= 1085;ое развитие проектов систем и изб= 077;жать заказчикам = 80; разработчиl= 2;ам на них крупных затрат. В то ж = 77; время, на базе рекоме = 85;дуемых при проектировk= 2;нии методов, инс= 090;рументальн&= #1099;х средств и стандартов, может и должен быт= 100; подготовлеl= 5; и обеспечен = 076;лительный, эффективныl= 1; жизненный цикл и совер= 096;енствовани&= #1077; множества версий высо = 82;окачествен&#= 1085;ых ПС и их компонентоk= 4; при реализа = 94;ии на различны = 93; аппаратных = 80; операционнm= 9;х платформах. = 050;онечный результат с = 80;стемного проектировk= 2;ния должен такж = 77; положительl= 5;о отражаться на системах обеспечениn= 3; качества, безопасносm= 0;и и защиты, на р&= #1072;ционально организоваl= 5;ных коллективаm= 3; квалифицир&#= 1086;ванных специалистl= 6;в, способных обеспечить весь жизнен = 85;ый цикл ПС. <o:p></o:p> Тщательноk= 7; и полноценноk= 7; системное проектировk= 2;ние выгодно с позиции ускорения разработок, предотвращk= 7;ния ошибок, обеспечениn= 3; эффективноl= 9;ти всего жизне = 85;ного цикла и высокого качества сл = 86;жных проектов комплексов программ в у= 089;ловиях ограниченнm= 9;х ресурсов. = Инициа = 83;изация системного проектировk= 2;ния может осуществляm= 0;ься заказчикамl= 0;, потенциальl= 5;ыми пользоватеl= 3;ями или разрабо = 90;чиками проектов ПС, которые желают получить достаточно четкое представлеl= 5;ие о возможных функциях и будущем жизненном цикле определеннl= 6;го проблемн= ;о-ориен-ти= 088;ованного комплекса программ и б= 072;зы данных. <o:p></o:p></span= > Системное проектировk= 2;ние далее структурирl= 6;вано, и методолог = 80;я его реализа = 94;ии отражает следующие проблемы, процессы и м= 077;тоды: <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>ц = 77;ли и принципы системного проектировk= 2;ния сложных про = 75;раммных средств для обеспечениn= 3; их последующеk= 5;о жизненного цикла в информациоl= 5;ных системах;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>п = 86;дготовку к непосредстk= 4;енному детальному проектировk= 2;нию, разработке = 80; всему жизненному циклу компл = 77;кса программ и базы данных для информа = 94;ионной системы; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 89;новы предваритеl= 3;ьного структурноk= 5;о проектировk= 2;ния и совl= 8;еменных технологий системного анализа и проектировk= 2;ния сложных комплексов программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды разработки требований = 82; характерисm= 0;икам качества и распределеl= 5;ия ресурсов, необходимыm= 3; для реализации проектов сложных ПС и баз данных;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>з = 72;дачи и принципы системного проектировk= 2;ния обеспечениn= 3; безопасносm= 0;и и защиты комплексоk= 4; программ от различных у = 75;роз;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1087;ланировани= е жизненного цикла и управление качеством ПС, а также выбор инструментk= 2;льных средств для поддержки всего их ЖЦ;<o:p></o:= p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тодики системного проектировk= 2;ния сложных ПС и требований = 82; их качеству, а также структура и содержание документов, отражающих = 88;езультаты выполненныm= 3; работ;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;рганизацию и подготовк = 91; специалистl= 6;в, способных обеспечить создание де = 90;ального проекта и всего жизненного цикла ПС, с требуемым качеством. <o:p></o:p> Непреры= ;вное повышение уровня автоматизаm= 4;ии в ряде систе= 084; при подготовке = 80; принятии ответственl= 5;ых решений возлагает все большие = 092;ункции на программ = 85;ые средства с соответствm= 1;ющими базами данных. В результате проблема обеспечениn= 3; качества и б= 077;зопасности их функцион = 80;рования l= 9;двигается к лицам, разрабатывk= 2;ющим системные проекты, мет= 086;ды и программн = 99;е средства дл= 03; автоматизаm= 4;ии, подготовки = 80; реализации ответственl= 5;ых решений. Одновременl= 5;о повышаются требования к уро= вню ответственl= 5;ости и системной квалификацl= 0;и лиц, реализующиm= 3; комплексы программ, от которых зачастую зависят ошибки стра = 90;егически важных решений, так как некотор = 99;е простейшие системные и техническиk= 7; ошибки этих лиц при создании программ мо = 75;ут приводить к большому ущербу или даже катаст = 88;офам. <o:p></o:p> Непреду= ;смотренные при системном проектировk= 2;нии ситуации и возможные дефекты про = 75;рамм являются по = 90;енциальным&#= 1080; источникамl= 0; отказов и аварий= при примен = 77;нии ряда систем. Массовая практика, ко= 075;да заказчик не может сформулироk= 4;ать четкие требования = 82; функциям и б= 077;зопасности ПС, а разработчиl= 2; не понимает,<sp= an style=3D'mso-spacerun:yes'> что нужно заказчику, п= 088;иводит к длительномm= 1; процессу разработки проектов с множеством дефектов и ошибок, на устранение которых расходуютсn= 3; большие ресурсы. В результате многие системы не соответствl= 6;вали исходному назначению = 80; первоначалn= 0;ным спецификацl= 0;ям, не укладывалиl= 9;ь в графики и бюджет разр = 72;ботки. Поэтому значительнl= 6; возросла необходимоl= 9;ть освоения всех соврем = 77;нных методов и методик предупреждk= 7;ния системных дефектов, об= 077;спечения высокого качества программ с самого начала их разработки. Многие ошибки, обусловленl= 5;ые неопределk= 7;нностью или некорректl= 5;остью техническиm= 3; заданий и спецификацl= 0;й, могут и должны быть выявлены на ранних= стадиях системного проектировk= 2;ния, что способствm= 1;ет его ускорению и повышению качества. Обширной практикой доказано, чт= 086; обнаружениk= 7; и устранени = 77; ошибок и дефектов в комплексах программ на начальных этапах системного проектировk= 2;ния в десятки и сотни раз бы= 089;трее и дешевле, чем в процессе завер= ;шения разработки и испытаний. <o:= p></o:p> = В последни = 77; десятилетиn= 3; быстро возрастаеm= 0; сложность объек= ;тов и систем, создаваемm= 9;х в разли= ;чных областях индустрии. Для их разра= 073;отки привлекаютl= 9;я специалистm= 9; разной квалификацl= 0;и и большие финансовыk= 7; и материальнm= 9;е ресурсы. Использовk= 2;ние этих ресурсов должно коорд= ;инироватьс= 03; и объединятn= 0;ся комплексом мероприятl= 0;й для достижениn= 3; общей= ; цели </spa= n>= - создания соответствm= 1;ющего сложн= ;ого объек= ;та или системы с заданным качеством в условиях ог = 88;аниченных ресурсов. Современныk= 7; сложные системы и соответствk= 7;нно проекты, обеспечивk= 2;ющие их создание,<sp= an style=3D'mso-spacerun:yes'> имеют ряд в= ажных особенносm= 0;ей:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>е = 76;иную цель разработки = 80; последующеk= 5;о функционирl= 6;вания всей систем = 99; для определеннm= 9;х пользоватеl= 3;ей;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 72;личие совокупносm= 0;и нескольких, тесно взаим = 86;действующи&#= 1093;, компонентl= 6;в - подсистем, имеющих свои локальные задачи и цел= 080; функционирl= 6;вания;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 77;рархическу&#= 1102; структуру с = 74;язей и взаимодейсm= 0;вия компонентоk= 4;, обеспечивk= 2;ющую концептуалn= 0;ное единство и устойчивоl= 9;ть функц= ;ионировани= 03; всей систем = 99;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 77;рархическу&#= 1102; совокупносm= 0;ь критериев качества функционирl= 6;вания компо= ;нентов и системы в целом, обеспечивk= 2;ющих достижение главн= ;ых целей= ; создания и после= ;дующего применениn= 3; системы пользоватеl= 3;ями.<o:p></o:p> Одной из особенностk= 7;й сложных систем является трудность выбора и фор= 084;ализации единого критерия качества и оцен= ки эффективноl= 9;ти функционирl= 6;вания, адекватно отраж= ;ающего главные цели систе= ;мы. Обычно выделяетсn= 3; несколько боле= е или менее равнозначнm= 9;х характериl= 9;тик, каждая из которых може= т стать домин = 80;рующей для оценки эффективноl= 9;ти системы в зависимосm= 0;и от этапа ее проектировk= 2;ния, состояния = 80;ли некоторых внешних условий. Это обусловленl= 6; тем, что каждая сложная сис = 90;ема, зачастую, является частью системы большего ма = 89;штаба и высшего уровня, и подчинена е = 81;.<o:p></o:p> = Для управления проек= ;том системы, прежде всег = 86;, должен быть адекватно о = 87;исаны цели и объек= 090; проектировk= 2;ния. Для сложных систем формализаm= 4;ия и детализациn= 3; характерисm= 0;ик объекта разработки происходит одновременl= 5;о с процессом его проекти = 88;ования. Последоватk= 7;льно уточняются архитектурk= 2; объекта, основные функции и их характерисm= 0;ики, требующиесn= 3; показатели качества функционирl= 6;вания и методы решения за = 76;ач. Все эти данные отражаются = 74; концепции, т= 077;хническом задании, спецификацl= 0;и требований = 80; описании проекта, котор= ;ые детализирm= 1;ются и конкретизиl= 8;уются по мере развития пр = 86;екта. Это определяет принципиалn= 0;ную особенностn= 0; планироваl= 5;ия проектов сложных систе= ;м, состоящую в наличии влияния на план изменяющихl= 9;я значений и достоверноl= 9;ти знаний разработчиl= 2;ов о требуемых характерисm= 0;иках объекта разработки. С этиl= 4; связана необходимоl= 9;ть итерационнl= 6;го уточнения планов на всех этапах проектировk= 2;ния, разработки = 80; совершенстk= 4;ования систем.<o:p></o:p> План проекта должен отражать рациональнl= 6;е сочетание целей, стратегий д = 77;йствий, конкретных процедур и доступных р = 77;сурсов, необх= ;одимых для достижения = 87;оставленно&#= 1081; основной цели проект = 72; с заданным качеством. Планированl= 0;е проектов должно обеспечиваm= 0;ь компромисс = 84;ежду требующимиl= 9;я характерисm= 0;иками создаваемоl= 1; системы и ограниченнm= 9;ми ресурсами, необходимыl= 4;и на ее разраб= 086;тку и применени = 77;. По мере уточ= 085;ения исходных данных об объекте разработкl= 0;, внешней среде применения и ресурсах, в проm= 4;ессе системного анализа и проектировk= 2;ния возрастает достоверноl= 9;ть планированl= 0;я. <o:p></o:p> Первичное прогнозироk= 4;ание характерисm= 0;ик проекта и подготовка плана при си= 089;темном проектировk= 2;нии происходит при некоторых ф = 80;ксированны&#= 1093; исходных данных, не полностью учитывающиm= 3; динамику возможного исполнения плана. На этой стадии отс = 91;тствует оперативнаn= 3; обратная связь процесса ре = 72;льного выполнения плана с его первичным в = 72;риантом. Важне= ;йшая задача= при разработке такого плана -</span= > минимизироk= 4;ать число связе = 81; и сложность взаимодейсm= 0;вия между компонентаl= 4;и проекта, а также между исполнителn= 3;ми отдельных компонентоk= 4;. Уже пl= 8;и первичном прогнозироk= 4;ании развития си = 89;темного проекта оцениваютсn= 3; альтернатиk= 4;ные характерисm= 0;ики объекта и ср= 077;ды разработки и выбl= 0;раются наиболее подходящие = 74; соответствl= 0;и с поставлен = 85;ыми целями и име= 102;щимися ресурсами.<o:p></o:p>= После создания системного проекта появляетсn= 3; и дейст= ;вует динамичесl= 2;ая обратная связь на пла= 085; со стороны процесса ег = 86; исполнения. Реализация проекта зависит от результатоk= 4; выполнения частных работ и може= 090; требовать оперативноl= 1; корректироk= 4;ки плана. При реализациl= 0; плана определяющl= 0;ми являю= ;тся координацl= 0;я, стиму= ;лирование и контроль развития проекта. Для этого необходимо следить за х= 086;дом исполнения проекта на всем протяжении его жизне= ;нного цикла и сравнивать запланировk= 2;нные и фактическ = 80;е результаты работ. Контр= ;оль является орган= ;ической функцией управлениn= 3; и должен иметь средс = 90;ва регулироваl= 5;ия поведения отдельных личностей и коллектива проектировm= 7;иков в целом. Одновременl= 5;о обеспечиваk= 7;тся наблюдение за состоянием системы и ее характерисm= 0;иками качества, что позволяет устанавлиk= 4;ать частные компромиссm= 9; с используе = 84;ыми ресурсами. Объектами к = 86;нтроля при этом являются:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>т = 77;хнические характерисm= 0;ики реали= ;зованных компонентоk= 4; проекта, показателl= 0; качества процессов и результатоk= 4; выполнения отдел= ;ьных работ;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;траты ресурсов на выполнение частных раб = 86;т и реаl= 3;изацию компонентоk= 4; проекта (трудоемкос = 90;ь, стоимость, время, материальнm= 9;е ресурсы);<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>г = 88;афики работ, степень их выl= 7;олнения, наличие и причины отклонений реализации частных работ от планов, угроза нарушения сроко= ;в контракта.<o:p></o:p>= Для получения, накопления = 80; применения достоверныm= 3; данных об об= 098;ектах управлениn= 3; и альm= 0;ернативах необходима информациоl= 5;ная система обе = 89;печения проекта. Такая система пре = 76;ставляет собой комплекс формальных и неформальl= 5;ых каналов обмен= ;а информациk= 7;й между участникамl= 0; проекта, её накопления = 80; обработки. Следует учиты= ;вать, что любая групповая деятельноl= 9;ть связана со сложным ком = 87;лексом неформальнm= 9;х отношений между исполнителn= 3;ми. Степень фор = 84;ализации может варьироватn= 0;ся от утвержда = 77;мых руководитеl= 3;ями планов и подробных техническиm= 3; заданий до личных бесе = 76; между разра = 73;отчиками. Регулярный обмен информациеl= 1; позволяет осуществляm= 0;ь:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 73;ор исходных данных о состоянии, достигнутl= 6;м качестве компонентоk= 4; проекта и использоваl= 5;ных ресурсах;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>д = 80;спетчерско&#= 1077; управление ресурсами и частными исполнителn= 3;ми работ;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 88;авнение текущих результатоk= 4; частных работ с техн= 080;ческими заданиями, с= 087;ецификация&= #1084;и и планом;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;рректировк&#= 1091; техническиm= 3; резул= ;ьтатов работ= ;, сроков= и использу = 77;мых ресур= ;сов в соответствl= 0;и с изменение = 84; требований = 74; процессе развития пр = 86;екта.<o:p></o:p> Таким образом, целевое системное управление проектами п = 86;зволяет планироватn= 0;, контролирl= 6;вать и анализиро = 74;ать информацию = 86; состоянии и тенденциях изменения объекта разработки, его качестве и з= 072;траченных ресурсах. Пр= 080; этом непрерывно = 76;олжны сохранятьсn= 3; основные цели проект = 72; и главные пути ее достижения. Это позволя = 77;т рассматривk= 2;ть альтернатиk= 4;ы техническиm= 3; решений и предотвращk= 2;ет от со= средоточенl= 0;я внимания на частных задачах или вариантах решений, которые кажутся полезными и = 080;нтересными, но мало отражаются на достижен = 80;и главной цел = 80; проекта ПС. <o:p></o:= p> <o:p> </o:p> <h1><a name=3D"_Toc508102459"></a><a name=3D"_Toc508102232">4.2. Процессы системного проектировk= 2;ния программныm= 3; средств</a></h1> <o:p> </o:p> Системное проектировk= 2;ние в программноl= 1; инженерии охватывает период жизн = 77;нного цикла сложных комплексов программ, начиная от формулировk= 2;ния первичного замысла на создание ил = 80; модернизацl= 0;ю системы и до начала детального проектировk= 2;ния и разработк = 80; ПС. Результатl= 6;м этого периода работ должн = 86; быть соглас = 86;ванное и формализо = 74;анное разработчиl= 2;ом и заказчико = 84; представлеl= 5;ие о целях, назначении, функционалn= 0;ных задачах и ка= 095;естве будущего программноk= 5;о продукта, способногl= 6; удовлетворl= 0;ть надежды и запросы пользоватеl= 3;ей. В системном проекте должны быть обобщены и отражены следующие основные результаты = 74;ыполненных системных исследоваl= 5;ий и разработо = 82; (рис. 4.1): <o:p></o:p= > <![if !supp= ortLists]>- = &nb= sp; = <![endif]>обобщенный анализ проведенноk= 5;о обследованl= 0;я объекта информатизk= 2;ции, функций существующk= 7;й информациоl= 5;ной системы, кач= 077;ства ее основных программныm= 3; компонентоk= 4; и базы данных;<o:p></o:p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>совокупнос= ;ть предваритеl= 3;ьных исходных тр = 77;бований к функциям и характерисm= 0;икам комплекса программ;<o:p></o:p>= <![if !supp= ortLists]>- = &nb= sp; = <![endif]>оценки имеющихся и потенциальl= 5;о доступных р = 77;сурсов (финансовых, вычислителn= 0;ных средств, специалистl= 6;в) для обеспечениn= 3; всего жизненного цикла и треб= 091;емого качества проекта комплекса п = 88;ограмм; <o:p></o:p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>результаты= ; предваритk= 7;льного анализа возможной архитектурm= 9; комплекса программ на основе моделей и прототипов аналогичныm= 3; систем, позв= 086;ляющие наметить планы разработки = 80; всего жизне = 85;ного цикла проекта ПС; <o:p></o:= p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>цели, задач = 80; и функции предполагаk= 7;мой новой или мо= 076;ернизирова&= #1085;ной системы, обобщенные = 74; концепции создания соответствm= 1;ющего программноk= 5;о средства; <o:p></o:p></span= > <![if !supp= ortLists]>- = &nb= sp; = <![endif]>проекты планов жизненного цикла, гарантировk= 2;ния требуемого качества ПС, защиты и обеспечениn= 3; безопаснос&#= 1090;и его функцио = 85;ирования;<o:p></o:p></sp= an> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>результаты технико-эко = 85;омического обоснованиn= 3; целесообраk= 9;ности и основных направлениl= 1; продолжениn= 3; проектировk= 2;ния и всего ЖЦ ПС;<= o:p></o:p> <![if !supp= ortLists]>- = &nb= sp; = <![endif]>результаты анализа существующk= 7;й и возможной = 080;нструмента&= #1083;ьной среды разработки, = 072; также систе = 84;ы обеспечениn= 3; качества, пе= 088;спективы их развития = 080; совершенстk= 4;ования;<o:p></o:p> <![if !supportLists]>- = &nb= sp; = <![endif]>предвари&= #1090;ельный план организациl= 0; работ, требо= 074;ания к составу и квалификацl= 0;и специалистl= 6;в для выполнения проекта и всего жизненного цикла ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; = <![endif]>проект формализовk= 2;нного техническоk= 5;о задания и спецификацl= 0;и требований = 82; ПС, а также предложениn= 3; по его финан= 089;ированию и обеспечениn= 2; ресурсами; <o:p></o:p= > <![if !supp= ortLists]>- = &nb= sp; = <![endif]>системный проект, обобщающий = 87;роведенные исследованl= 0;я и разработк = 80;, позволяющиl= 1; заключить контракт между разработчиl= 2;ом и заказчико = 84; на финансировk= 2;ние и продолжениk= 7; проектировk= 2;ния и/или на весь жизненный цикл ПС. <o:p></o:p> Сl= 0;стемное проекти= рование сложных ПС начинается = 89; обследованl= 0;я объекта инф = 86;рматизации, системного анализа п= ;редметной области и выявления п = 86;требности в создании или модернизацl= 0;и комплекса п = 88;ограмм с определеннm= 9;ми функциями и качеством. При создани = 80; сложных ПС важно учитывать, что только заказчик и п= 086;тенциальны&= #1081; пользоватеl= 3;ь системы вправе и способен корректно формулировk= 2;ть требования = 80; впоследствl= 0;и судить наск = 86;лько успешно проведена разработка = 89;оответству&#= 1102;щего ПС. Аналитики-к = 86;нсультанты совместно с потенциальl= 5;ыми разработчиl= 2;ами и заказчико = 84; или пользоватеl= 3;ями должны пров = 86;дить анализ прикладной области и объекта информатизk= 2;ции, разрабатывk= 2;ть стратегию разработки = 80; технико-эко = 85;омическое обоснованиk= 7; реализуемоl= 9;ти выдвигаемыm= 3; требований. <o:= p></o:p> Разр= аботка исходных требований для техниче = 89;кого задания на проект ПС начинается = 89; анализа результатоk= 4; обследованl= 0;я объекта инф = 86;рматизации и оценки доступных ресурсов дл= 03; реализации проекта. Эта деятельносm= 0;ь требует специальноl= 1; организациl= 0; специалистl= 6;в наивысшей квалификацl= 0;и и тесной сов= 084;естной работы пред = 89;тавителей заказчика и разработчиl= 2;а. Они должны подготовитn= 0; исходные данные и документы, в которых сод = 77;ржатся предваритеl= 3;ьные требования = 80; пожелания к функционалn= 0;ным и конструкт = 80;вным характерисm= 0;икам качества программноk= 5;о комплекса. Далее ими должна проводитьсn= 3; сложная раб = 86;та по предвари = 90;ельному упорядоченl= 0;ю, селекции, обобщению и ранжированl= 0;ю приоритетоk= 4; требований для их реализации = 74; проекте. Наличие обычно ряда неформализl= 6;ванных, неструктурl= 0;рованных и противоре = 95;ивых содержателn= 0;ных требований заказчика и разработчиl= 2;а требует их совместной обработки, с= 086;гласования и корректир = 86;вки. <o:p></o:p> Функ= циональные требования заказчика к = 087;роцессам и результат = 72;м обработки информации необходимо скоординирl= 6;вать с конструкт = 80;вными требованияl= 4;и и возможностn= 3;ми их эффектив = 85;ой реализации разработчиl= 2;ами в спецификацl= 0;ях требований = 82; комплексу программ и его программныl= 4; и информаци = 86;нным компонентаl= 4;. Должна быть предусмотрk= 7;на корректироk= 4;ка, конкретизаm= 4;ия и развитие совокупносm= 0;и предваритеl= 3;ьных требований = 74; процессе системного проектировk= 2;ния и в дальнейшем по мере реализации проекта при = 090;есном взаимодейсm= 0;вии заказчика и разработчиl= 2;а. Для крупных проектов ПС целесообраk= 9;но использоваm= 0;ь специальныl= 1; инструментk= 2;рий и хранилище решений в пр= 086;цессе отработки требований, которые сле = 76;ует учесть в системном проекте и техническоl= 4; задании, а также приме = 85;ять для контрол= 03; их реализац = 80;и.<o:p></o:p> Предваритk= 7;льный анализ и мод= 077;лирование процессов обработки данных при с= 080;стемном проектировk= 2;нии должны проходить этапы от простого ус = 90;ановления базовых отн = 86;шений между понят = 80;ями, через определениk= 7; интерфейсоk= 4; доступа и атрибутов, к проекту модели сост = 86;яний и взаимодейсm= 0;вий между реаль = 85;ыми объектами и процессами ПС. Эти модел&#= 1080; должны служить базой при разработке = 89;хем потоков упр = 72;вления и данных, описывающиm= 3; процессы их = 086;бработки, а впоследствl= 0;и интегрировk= 2;ться с отработан = 85;ыми моделями процессов для комплек = 89;ного исследованl= 0;я функционирl= 6;вания прототипов </sp= an><span style=3D'font-size:14.0pt;font-family:Symbol; mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times New Ro= man"; letter-spacing:.2pt;mso-char-type:symbol;mso-symbol-font-family:Symbol; font-weight:normal;font-style:normal'>- пилотных проектов ПС = 074; целом. Ите= ративный характер построения формализовk= 2;нного описания проекта системы, предо= ;пределен изначально не только потому, что не удается с= 088;азу получить непротиворk= 7;чивое и полное описание из-за неясно= 089;тей в исходном описании, но и потому, что сложную систему можно описывать только, начи= 085;ая с основной части ее предметной области, котор= ;ая затем постепенно расширяетсn= 3; и детализир = 91;ется. <o:p></o:p> Моде&= #1083;ирование процессов обработки данных при системном проектировk= 2;нии преследует две основные цели:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 86;делировани&#= 1077; проблемно-о = 88;иентирован&#= 1085;ых процессов и конкретных функционалn= 0;ных задач с цель= 102; исследованl= 0;я принципов, методов и характерисm= 0;ик обработки и = 85;формации и принятия решений для последующеk= 5;о их использоваl= 5;ия в проектах; <o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>м = 86;делировани&#= 1077; архитектурm= 9; объектов и п= 088;оцессов, а также их взаимодейсm= 0;вия, предп= ;олагаемых для применения = 74; конкретном проекте, без акцента на особенностl= 0; функционалn= 0;ных характерисm= 0;ик компонентоk= 4;. <o:p></o:p> &#= 1055;ри построении формализовk= 2;нного описания системы, выполняемоl= 4; её разработ = 95;иком, принципиалn= 0;ными являются дв = 72; организациl= 6;нных момента: спе= 094;иалисты - заказчики или пользоватеl= 3;и создаваемоl= 1; системы должны активно участвоватn= 0; в процессе анализа и реализации её описания; каждый шаг описания должен обязательнl= 6; документирl= 6;ваться. Наглядны= ми и удобными в работе являются графическиk= 7; представлеl= 5;ия описаний проектных решений, которые поз = 74;оляют создавать прототипы П = 57;. Они обеспеч = 80;вают эффективнуn= 2; визуализацl= 0;ю и обратную связь между разработчиl= 2;ом и потенциал= 00;ным пользоватеl= 3;ем с целью оценки реализации требований, = 082;орректиров&= #1082;и функций и качества компонентоk= 4;, а также форм пользоватеl= 3;ьского интерфейса. </s= pan>Для этого разра = 73;отана целая гамма = 084;етодологий<= span style=3D'mso-spacerun:yes'> для мl= 6;делировани= 103;, структурноk= 5;о анализа и визуальногl= 6; проектировk= 2;ния. Современ= ные инструментk= 2;льные CASE-средства об= ;еспечивают широкие возможностl= 0; выбора проц = 77;ссов моделироваl= 5;ия, автоматизиl= 8;ованного анализа системных п = 88;едложений и выработки первичных требований = 82; предполагаk= 7;мому проекту ПС. Схемы поток = 86;в данных, пото= 082;ов управления, сущность-св= 03;зь и другие – составляют комплекс удобных и гибких граф = 80;ческих методов и средств описания систем, облегчающиm= 3; взаимопониl= 4;ание между разра = 73;отчиками и заказчика = 84;и на разных ур= 086;внях детализациl= 0; функций, качества и архитектурm= 9; ПС. <o:p></o:p> Конце= пция создаваемоk= 5;о комплекса программ (см. рис. 4.1) на естественнl= 6;м языке данно = 81; предметной области должна включать пр = 77;дварительн&#= 1099;е требования = 82; ПС, основные понятия и термины. Она является первым исходным документом, согласуемыl= 4; с заказчико = 84; для создани= 03; комплекса программ. На основе этог = 86; описания формируетсn= 3; предваритеl= 3;ьное техническоk= 7; задание на систему и её основные компоненты. При использоваl= 5;ии формализовk= 2;нных методов раз = 88;аботки программныm= 3; средств текстуальнl= 6;е описание системы подлежит переводу на соответствm= 1;ющий, возможно, графическиl= 1; язык. Наряду с = разработчиl= 2;ами, специалистm= 9;-заказчики или пользов = 72;тели создаваемоl= 1; концепции П = 57; должны активно участвоватn= 0; в процессе анализа и реализации её описания.<o:= p></o:p> Одни= м из наиболее эффективныm= 3; направлениl= 1; сокращения = 79;атрат и повышения качества комплексов программ является активное использоваl= 5;ие методическl= 6;го, технологичk= 7;ского, алгоритмичk= 7;ского и программн = 86;го задела из предшествуn= 2;щих проектов, которое может быть названо = прототипирl= 6;ванием= в широком смысле слов = 72;. Математичеl= 9;кие модели и прототипы различных компонентоk= 4; и функций систем= обеспечивk= 2;ют возможностn= 0; применять готовые апробироваl= 5;ные решения, а та&#= 1082;же выделять и исследоватn= 0; принципиалn= 0;но новые метод = 99; и процессы для реализации их в ПС. = Прототипирl= 6;вание позволяет наглядно пр = 77;дставить заказчику и пользоватеl= 3;ю функции системы, вид= 099; и динамику применения экранов, меню, отчето= 074; и форм запросов, а также откорректиl= 8;овать их для развития ПС на всех этапах ЖЦ. Методами математичеl= 9;кого моделироваl= 5;ия должны создаватьсn= 3; варианты, фрагменты и компоненты прототипа П = 57; и выделятьс= 03; возможные методы реализации предполагаk= 7;мых функций и обеспечениn= 3; их качества. </= span>Для этого следу = 77;т анализировk= 2;ть и выбирать прототипы к = 86;мплексов программ, характерисm= 0;ики которых наиболее близки к создаваемоl= 1; версии ПС и которые позволили б = 99; получить в результате объекты с необходимыl= 4;и характерисm= 0;иками. На их основе,<s= pan style=3D'mso-spacerun:yes'> во= зможно прогнозироk= 4;ать процессы разработки = 80; достигаемыk= 7; показатели качества вн = 86;вь создаваемоk= 5;о ПС. Этим же целям способствуk= 7;т предваритеl= 3;ьное распределеl= 5;ие ресурсов, доступных для создани= 03; проекта.<o:p></o:p></s= pan> Страт&#= 1077;гическое планированl= 0;е проекта дол = 78;но содержать долгосрочнm= 9;е цели развит = 80;я ЖЦ ПС определеннl= 6;го функционалn= 0;ного назначения. Планы должн = 99; отражать пр = 77;дварительн&#= 1099;е проекты всего будущ = 77;го жизненного цикла ПС, обеспечениn= 3; их качества, защиты и без= 086;пасности функционирl= 6;вания, верификациl= 0; и тестирова = 85;ия, управления конфигурацl= 0;ей и сопровождеl= 5;ия. На базе требований = 82; ПС и первичн= 099;х планов появляется возможностn= 0; оценить объем подле = 78;ащих разработке компонентоk= 4; программ и б= 072;з данных, а также некоторые дополнителn= 0;ные характерисm= 0;ики возможного объекта и ср= 077;ды разработки. На этом этап= 077; инструментk= 2;льные средства должны обеспечить наглядное представлеl= 5;ие каждого плана, оценк= 091; возможной трудоемкосm= 0;и и длительно = 89;ти разработки, необходимоk= 5;о числа специалистl= 6;в и других ресурсов дл= 03; их реализации. </s= pan> По этим данным руководитеl= 3;ем разработки = 80; заказчиком принимаетсn= 3; решение о целесообраk= 9;ности продолжениn= 3; проектировk= 2;ния и осуществляk= 7;тся стратегичеl= 9;кое планированl= 0;е проекта, которое фор = 84;ализуется в системном проекте и в техническоl= 4; задании на ПС.<o:p></o:p> &nbs= p; Такое постепенноk= 7; повышение д = 86;стоверност&#= 1080; прогнозов приводит к целесообраk= 9;ности оценки достигаемыm= 3; значений ка = 95;ества по этапам и к возможностl= 0; разработки укрупненноk= 5;о, поэтапного плана выполнения всего комплекса работ в ЖЦ ПС. Эти данные позволяют принимать р = 77;шения по корректироk= 4;ке требований = 82; ПС, по измене&#= 1085;ию среды разработки или состава коллектива специалистl= 6;в. Таким образом, пос= 083;едовательн&= #1086;е прогнозироk= 4;ание, планированl= 0;е и системное управление проектом обеспечиваn= 2;т рациональнl= 6;е использоваl= 5;ие ресурсов в процессе со = 79;дания сложных ПС гарантировk= 2;нного качества. <o:p></o:p></span= > Прог= нозы и анализ вариантов технологичk= 7;ских процессов проектировk= 2;ния ПС, их технико-эко = 85;омических показателеl= 1; и характери = 89;тик объекта разработки являются ос = 85;овой для выбора, предваритеl= 3;ьного планированl= 0;я и последующеk= 5;о системного анализа все = 75;о жизненного цикла ПС. Достоверноl= 9;ть планов и про= 075;нозов определяетl= 9;я точностью с = 74;едений об объекте разработки, характерисm= 0;иках технологичk= 7;ской среды и прототипов, принятых за основу при планированl= 0;и. Таким образ = 86;м, производитl= 9;я технико-эко = 85;омическое обоснованиk= 7; проекта (см. лекцию 5), определяюm= 0;ся приближеннm= 9;е значения трудоемкосm= 0;и и длительно = 89;ти всей разработки ПС, а также число необх = 86;димых специалистl= 6;в, что позволяет оценить предваритеl= 3;ьный укрупненныl= 1; план создан = 80;я ПС в заданны= 093; условиях, ре= 089;урсах и сроках. Вследствие творческогl= 6; характера большинствk= 2; работ на это= 084; этапе невоз = 84;ожно составить жесткий пла = 85; их выполнения. Помочь може = 90; типовой перечень ча = 89;тных работ, представлеl= 5;ный в стандартах ЖЦ ПС и ориентировl= 6;чный график, иллюстрируn= 2;щий их взаимосв= 03;зь.<o:p></o:p> Пров= еденные таким образом оценки проекта ПС позволяют осуществитn= 0; предваритеl= 3;ьный выбор основных методов и инструментk= 2;льных средств для провед = 77;ния последующеk= 5;о детального = 80; рабочего проектировk= 2;ния и поддержки всего ЖЦ ПС. Кроме того, должна подготавлиk= 4;аться адаптация средств автоматизаm= 4;ии, применителn= 0;но к особеннос = 90;ям объекта и среды проектировk= 2;ния. Разрабатывk= 2;ются проекты рук = 86;водств для специалистl= 6;в, выделяемых на данный проект, и осуществляk= 7;тся их обучение. </= span>Интегри= ;рованные инструменm= 0;альные средства служат для ф= 086;рмализации знаний зака = 79;чика на этапе проведения обследованl= 0;я, анализа и подготовки техническоk= 5;о задания, а та&#= 1082;же для проектировk= 2;ния концептуалn= 0;ной и логическо = 81; структуры комплекса программ и б= 072;зы данных. При этом должно активно использоваm= 0;ься моделироваl= 5;ие и тестированl= 0;е корректносm= 0;и системных решений. Благодаря высокому качеству проработки = 80; документирl= 6;вания системного проекта, создается о = 89;нова для снижени= 03; трудоемкосm= 0;и тестированl= 0;я, испытаний, а также сопровождеl= 5;ия и модификац = 80;и ПС. <o:p></o:p> В процессе системного проектировk= 2;ния должны предваритеl= 3;ьно определятьl= 9;я состав и стр= 091;ктура основных технологичk= 7;ских и эксплуата = 94;ионных документов для поддерж = 82;и всего ЖЦ ПС. Эти документы должны обес = 87;ечивать реализацию процессов ж = 80;зненного цикла ПС, планированl= 0;я и управлени= 03;, регистрироk= 4;ать выполнение требуемых действий, фо= 088;мализовать систему качества. Пр= 080; этом следуе = 90; подготовитn= 0; первоначалn= 0;ные требования = 82; документацl= 0;и и обеспечит= 00; их реализац = 80;ю, которая должна быть однозначноl= 1; <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";letter-spacing:.2pt;mso-char-type:s= ymbol; mso-symbol-font-family:Symbol'>- написана в стандартизl= 0;рованных терминах, которые допускают только единственнm= 1;ю интерпретаm= 4;ию, уточняемую, = 077;сли необходимо, соответствm= 1;ющими комментариn= 3;ми.<o:p></o:p> Сист= емный проект программноk= 5;о средства но = 74;ой или модерни = 79;ированной системы должен содержать достаточно полные требования = 82; функциям и характерисm= 0;икам качества комплекса программ, оп= 080;сание и графическоk= 7; представлеl= 5;ие его архитектурm= 9;, базы данных = 080; взаимодейсm= 0;вия компонентоk= 4;, предполагаk= 7;мую модель жизненного цикла, предв= 072;рительные планы последующиm= 3; этапов и раб= 086;т. Кроме того, в него должны входить про = 77;кты техническоk= 5;о задания и контракта н = 72; детальное проектировk= 2;ние и весь жизненный цикл ПС. Если заказчик уд = 86;влетворен результатаl= 4;и системного проектировk= 2;ния, то возможно оформление акта завершения работ и утверждениk= 7; системного проекта ком = 87;лекса программ с требуемыми характерисm= 0;иками качества новой или мо= 076;ернизирова&= #1085;ной системы, а также контракта (договора) на детальное проектировk= 2;ние или на весь жизненный цикл ПС. <o:p></o:p> = <o:p></o:p> <h1><sp= an style=3D'mso-spacerun:yes'> <a name=3D"_Toc508102460"></a><a name=3D"_Toc508102233">4.3. Структурноk= 7; проектировk= 2;ние сложных про = 75;раммных средств</a><o:p></o:p></sp= an></h1> = <o:p></o:p> При разработке структуры п = 88;ограммного средства в процессе системного проектировk= 2;ния, прежде всег = 86;, необходимо сформулироk= 4;ать критерии её формированl= 0;я. Важнейшими критериями могут быть: модифицируk= 7;мость, отлаживk= 2;емость и удобство управления разработкоl= 1; ПС, обеспечениk= 7; возможностl= 0; контролируk= 7;мого изменения конфи= ;гурации, состава и функций компонентоk= 4; с сохранениеl= 4; целостностl= 0; структурноk= 5;о построениn= 3; базовых версий ПС. В з= 072;висимости от особенностk= 7;й проблемной области, критериями при выборе архитектурm= 9; ПС могут также применятьсn= 3;: эффективнl= 6;е использоваl= 5;ие памяти или производиm= 0;ельности реализующk= 7;й ЭВМ, трудоемкоl= 9;ть или длительносm= 0;ь разработки, надежность, безопасносm= 0;ь и защищенносm= 0;ь. В соответст = 74;ии с целями и за= 076;ачами проектировk= 2;ния на стадии системного анализа и формированl= 0;я структуры П = 57; необходимо ранжироваm= 0;ь и выделить доминирующl= 0;е критерии. <o:p></o:p></span= > Гибкость модификациl= 0; и расширяем = 86;сть комплексов программ пр = 80; их совершен = 89;твовании обеспечиваk= 7;тся рядом принц = 80;пов и правил структурноk= 5;о построения = 55;С и их компонентl= 6;в, а также взаи= 084;одействия между ними. Эти правила направлены на стандарт = 80;зацию и уни= фикацию структуры и взаим= ;одействия компонентоk= 4; ПС разного ранга и назначения = 74; пределах проблемной области. Некоторая часть принципов и правил имее = 90; достаточно общий= ; характер, и может применятьсn= 3; практическl= 0; всегда. Другая част= 00; отражает проблемную и/или машин= ;ную ориентироk= 4;анность класса ПС и подлежит от = 88;аботке при системн = 86;м проектировk= 2;нии для эффективноk= 5;о применения = 74; соответствm= 1;ющей области. Основные принципы<o:p></o:p><= /p> &#= 1080; правила стр= ;уктурирова = 85;ия ПС и БД можно объединить = 74; группы, кото= 088;ые отражают:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 90;андартизир&#= 1086;ванную структуру целостного построения ПС и/или БД определеннl= 6;го класса;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила структурнl= 6;го построения функционалn= 0;ных программныm= 3; компонентоk= 4; и модулей;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>с = 90;андартизир&#= 1086;ванную структуру базы данных, обрабатывk= 2;емых программамl= 0;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила структурноk= 5;о построения информациоl= 5;ных модулей, заполняющl= 0;х базу данных;<o:= p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила организациl= 0; и структурн = 86;го построения межмо= ;дульных интер= ;фейсов программныm= 3; компонентоk= 4;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 85;ифицирован&#= 1085;ые правила внешнего интерфейсk= 2; и взаимодей = 89;твия компонентоk= 4; ПС и БД с внешней средой, с операционнl= 6;й систе= ;мой и другими типовыми средствами организациl= 0; вычислителn= 0;ного процесса, за= 097;иты и контроля системы.<o:p></o:p> = Методологl= 0;я структурноk= 5;о анализа и предваритеl= 3;ьного структурноk= 5;о проектировk= 2;ния ПС начинается = 89; общего обзора функ = 94;ий системы. Далее функции должны дета = 83;изироватьс&#= 1103; сверху вниз = 074; виде иерарх = 80;ческой структуры таким образом, чтобы проце = 76;уры сбора, хранения и п= 077;реработки информации, рассматривk= 2;емые сначала как нечто едино = 77; целое, расчленялиl= 9;ь на отдельны = 77; элементы да = 85;ных, компонентоk= 4; и действия, с&#= 1086;вершаемые над этими данными. Структурныl= 1; анализ, исходя из функционалn= 0;ного описания системы в целом, позво= 083;яет разделить е= 05; на функцион = 72;льные части, выделить функционалn= 0;ные описания отдельных частей, иссл= 077;довать в них информациоl= 5;ные потоки и фор= 084;ализовать структуры д = 72;нных.<o:p></o:p> </spa= n>Разделение общей задач = 80; системы и программноk= 5;о средства на компоненты </sp= an>= - это использоваl= 5;ие принципа здравого см = 99;сла, который должен быть применен в системной разработке крупного ПС для преодол = 77;ния свойственнl= 6;й ему сложности. Очень часто многи = 77; решения прочно взаимосвязk= 2;ны и взаимозав = 80;симы. Когда различные проек= ;тные решения прочно взаимосвязk= 2;ны, то бывает полезно, чтобы всеми ими сразу занимались = 74; одно и то же время одни и те же люди, но = на практике эт = 86; обычно невозможно. Единственнm= 9;й способ сl= 7;равиться со сложностью проекта - разделить задачи. Прежде всег = 86;, необходимо пытаться из = 86;лировать функции, которые менее всего связаны с другими. Зат= 077;м рассматривk= 2;ть раздельно функции, учитывая имеющ= 080;е отношения между собой и деm= 0;али связанных п = 88;облем.<o:p></o:p> Спецификац= 080;я требований = 82; предваритеl= 3;ьной архитектурk= 7; комплекса программ формируетсn= 3; в процессе детализациl= 0; и уточнения спецификацl= 0;и требований = 82; характерисm= 0;икам ПС в результате проверки последних н = 72; непротиворk= 7;чивость и полноту. Задача спец = 80;фикации требований архит= ;ектуры состоит в том, чтобы представитn= 0; достаточно = 03;сное и удобное общее описание внешнего по = 74;едения системы и свойств, а также её внутренней структуры и механизмов функционирl= 6;вания. В общем сл= 091;чае формализовk= 2;нные методы, применяемыk= 7; при специфицирl= 6;вании системной архитектурm= 9; ПС, должны обеспечиваm= 0;ь:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>э = 92;фективные и удобные средства описания св = 86;йств и особеннос = 90;ей структуры создаваемоl= 1; системы – но= 090;ации описания;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>м = 77;тодику последоватk= 7;льного, итерационнl= 6;го уточнения с = 87;ецификаций требований = 80; проектных спецификацl= 0;й компонентоk= 4;, позволяющуn= 2; проверять и = 93; корректносm= 0;ь;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]> = 89;редства и методику для возможностl= 0; прослеживаl= 5;ия реализации требований = 80; тестированl= 0;я, позволяющеk= 5;о устанавливk= 2;ть соответствl= 0;е свойств реа = 83;изуемого ПС и компоне= 085;тов его специфи = 82;ациям.<o:p></o:p>= Описания проектных решений должны содержать первичные спецификацl= 0;и крупных функционалn= 0;ных компонентоk= 4; ПС, подлежащ= 080;х разработке = 74; детальном проекте соз = 76;аваемой системы, и спецификацl= 0;й используемm= 9;х готовых компонентоk= 4;, состав кото = 88;ых определяетl= 9;я при декомпо = 79;иции общей струк = 90;уры системы. В требованияm= 3; спецификацl= 0;и к системной архитектурk= 7; комплекса п = 88;ограмм должно обес = 87;ечиваться:<o:p></o= :p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;ответствие функций и структуры П = 57; аппаратной = 80; операционнl= 6;й среде, их ресурсам и интерфейсаl= 4;; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;вместимос = 90;ь ПС с другими системами п = 86; источникам = 80; потребител= ям информации; <o:= p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1089;оответстви= е стандартам структурноk= 5;о построения = 80; интерфейсоk= 4; комплекса программ, функционалn= 0;ных компонентоk= 4; и модулей; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ая организациn= 3; информациоl= 5;ного обеспечениn= 3; и структура базы данных; <o= :p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;став, структура и способы обмена данными между функц = 80;ональными компонентаl= 4;и и внешней средой ПС;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>в = 88;еменной регламент и предваритеl= 3;ьные характерисm= 0;ики процессов реализации функций, интенсивноl= 9;ть и объемы потоков информации базы данных;<o:= p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;нтроль, хранение, обновление, защита и вос= 089;тановление программ и данных;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 90;андартизир&#= 1086;ванные, предваритеl= 3;ьные требования = 82; составу и содержанию технологичk= 7;ской документацl= 0;и.<o:p></o:p> Таким образом, для обеспечениn= 3; эффективноk= 5;о управления разработкоl= 1; прогр= ;амм необходимl= 6; при системном п = 88;оектирован&#= 1080;и стандартизl= 0;ровать и соблюдать ряд принципов архитектурl= 5;ого построения ПС. Эти принципы могут иметь особенностl= 0; для проекто = 74; ПС в различных проблемно-о = 88;иентирован&#= 1085;ых областях. Однако их стандартизk= 2;ция обеспечиваk= 7;т значительl= 5;ый эффект в сни= 078;ении трудоемкосm= 0;и и длительносm= 0;и последующеl= 1; детальной разработки программноk= 5;о продукта и версий. Част= 080;чная потеря гибк = 86;сти архитектурm= 9; ПС, некоторо= 077; возрастаниk= 7; ресурсов, необходимыm= 3; для реализации этих принци = 87;ов, обычно полностью компенсируn= 2;тся повышением управляемоl= 9;ти процесса разработки, = 072; также качес = 90;ва ПС.<o:p></o:p> Структурнl= 6;е проектировk= 2;ние программныm= 3; средств осно= вано на модульно = 84; принципе. Многоуровнk= 7;вое, иерархичесl= 2;ое пост= роение сложных пр = 86;граммных комплексов позволяет ограничиваm= 0;ь и локализов = 72;ть на каждом из уровней соответствm= 1;ющие ему компоне = 85;ты. Нижнему иерархичесl= 2;ому уровню представлеl= 5;ия прогр= ;амм соответстk= 4;уют прогр= ;аммные и информациоl= 5;ные модули (модули данн= 099;х). Эти компоненты объединяютl= 9;я в группы программ оп = 88;еделенного<s= pan style=3D'mso-spacerun:yes'> функционаl= 3;ьного назначения = 89; автономной целевой задачей. Несколько групп функционалn= 0;ных программ образует комплекс пр = 86;грамм. В особо сложных слу = 95;аях возможно создание программноk= 5;о средства из нескольких взаимодейсm= 0;вующих комплексов. Всем иерарх = 80;ческим системам (в частности, ПС) присущ ряд общих свойс = 90;в, важнейшими из которых являются:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>в = 77;ртикальная соподчиненl= 5;ость, заключающаn= 3;ся в последова = 90;ельном упорядоченl= 5;ом расположенl= 0;и взаимодейсm= 0;вующих компонентоk= 4;, составляющl= 0;х ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;аво вмешательсm= 0;ва и приоритетнl= 6;го воздействиn= 3; сверху вниз на компонен = 90;ы нижних уровней;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 79;аимозависи&#= 1084;ость действий компонентоk= 4; верхних уро = 74;ней от реакций на воздействl= 0;я и от функционирl= 6;вания компонентоk= 4; нижних уровней, инф= 086;рмация о которых передается верхним уровням.<o:p></o:p> = В результате в иерархичеl= 9;ких структураm= 3; ПС образуются два потока взаим= ;одействий между компонентk= 2;ми разных уров= ней: сверх= ;у вниз </spa= n>= - координируn= 2;щие и управляющиk= 7; воздействиn= 3; верхних уровней и снизу вверх </s= pan>= - информация о состоянии и реализации предписаннm= 9;х сверху функ = 94;ий компонентаl= 4;и нижних уровней. Координируk= 7;мые компоненты обычно имею = 90; некоторую автономносm= 0;ь поведения и подготовки локальных решений. Степень автономносm= 0;и компонентl= 6;в и интен= ;сивность координирm= 1;ющих возд= ействий устанавливk= 2;ются в результате компромиссk= 2; при выделении числа и размеров ие = 88;архических уровней. Вза= 080;модействие компонентоk= 4; в пределах у= 088;овня целесообраk= 9;но максимальнl= 6; ограничиваm= 0;ь, что позволяет упростить о = 73;щее координирl= 6;вание компо= ;нентов и прово= ;дить его только по ве= ;ртикали.<o:p></o:p> = Менее наглядными являются иерархия данных, обраб= ;атываемых ПС, и их&nbs= p; взаимодейl= 9;твие с прогр= ;аммными компонентk= 2;ми. Функционалn= 0;ная иерархия данных отражаетсn= 3; расстояниеl= 4; между расче = 90;ом или изменением переменной = 80; её использо = 74;анием, или условно = 81; длительносm= 0;ью хранения неизменяемm= 9;х значений переменной. Взаимодейсm= 0;вие двух программныm= 3; модулей мож = 77;т осуществляm= 0;ься так, что некоторые перем= ;енные используюm= 0;ся тольк= ;о этими модулями. Такие обменные переменные имеют более широк= ;ую облас= ;ть применениn= 3; и должны хран = 80;ться все время, пока не буду= 090; вызваны вза = 80;модействую&#= 1097;ие модули. Ряд переменных = 80; массивов ис = 87;ользуется многими модулями и групп= ;ами программ в комплексе = - это глобальные переменные. Они характеризm= 1;ются наиболее широким использоваl= 5;ием и соответстk= 4;уют высшему иерархичесl= 2;ому уровню сред = 80; данных. <o:p></o:p> Анализ концепции, требований техническоk= 5;о задания и технико-эко = 85;омических оценок должен позволять выполнить предваритеl= 3;ьное структурноk= 7; проектировk= 2;ние ПС = и оценку вычислителn= 0;ных ресурсов не = 86;бходимых для решения основных функционалn= 0;ных задач. Повышению э = 92;фективност&#= 1080; структурирl= 6;вания могут значи = 90;ельно способствоk= 4;ать заимствоваl= 5;ие из предыдущих проектов спецификацl= 0;й прототипов, версий и отдельных компонентоk= 4; ПС. Для обеспечениn= 3; системного проектировk= 2;ния на этом этап= 077; большое значение имеют графическиk= 7; методы визу = 72;лизации техническиm= 3; решений и логическогl= 6; контроля пр = 86;екта.<o:p></o:p> = Характериl= 9;тики внешней среды= ; применениn= 3; ПС и особенностl= 0; реализующеl= 1; ЭВМ в значительнl= 6;й степени определяют архит= ;ектуру и структуру применяемl= 6;й операционнl= 6;й системы, средств контроля и организациl= 0; вычислителn= 0;ного процесса. Пр= 080; разработке версий ПС дл= 103; некоторой прикладной области целесообраk= 9;но выбирать и унифицировk= 2;ть внешний интерфейс и операционнm= 1;ю систему. Это обеспечивk= 2;ет многократнl= 6;е использоваl= 5;ие одних и тех же организу= 02;щих программ, дисци= ;плинирует структурнl= 6;е постр= оение версий ПС и способствуk= 7;т унификации межмодульнl= 6;го интерфейса. Переход на н= 086;вую операционнm= 1;ю систему, так же как и переход на реализующуn= 2; ЭВМ другого = 090;ипа, может приве = 89;ти к необходимоl= 9;ти некоторого изменения структурноk= 5;о построения ПС и базы данны= ;х. Это способно повлиять н = 72; возможностn= 0; использоваl= 5;ия готовых ком = 87;онентов, а, следователn= 0;но, и на эффекти= 074;ность всей разраб = 86;тки.<o:p></o:p> Учет возможностl= 0; изменений = - это принцип, который более всего отличает пр = 86;граммное средство от большинствk= 2; других типо = 74; промышленнm= 9;х продуктов. В= 086; многих случаях структура П = 57; разрабатывk= 2;ется, когда требования заказчика к нему осознаны не полностью. Позже, при детализациl= 0; и после поставки, ПС должно развиватьсn= 3; на основе откликов за = 82;азчика и пользоватеl= 3;ей, поскольку о = 73;наруживают&#= 1089;я новые требования, = 072; старые уточняются. = 042; дополнение = 82; этому, программныl= 1; продукт часто встраиваетl= 9;я в среду, которая воздействуk= 7;т на него, и это воздействиk= 7; генерирует новые требования, которые не были изнача = 83;ьно известны. Таким образом, воз= 084;ожности изменений </sp= an>= - это принцип, кот= 086;рый следует использоваm= 0;ь при системном проектировk= 2;нии структуры для достижения способностl= 0; к её развити= 102; - эволюционн&#= 1086;сти структуры П = 57;.<o:p></o:p> Повторная применимосm= 0;ь - является ещ = 77; одним качеством структуры п = 88;ограммного продукта, на которое заметно воздействуk= 7;т принцип возможностl= 0; изменений. Компонент является многократнl= 6; применимым, если он може= 090; быть непосредстk= 4;енно использоваl= 5; для произво = 76;ства нового продукта ил = 80; версии. На практике, компонент может прете = 88;петь некоторые изменения прежде, чем будет использоваl= 5; повторно. Отсюда, мног= 086;кратное использоваl= 5;ие можно рассматривk= 2;ть как эвол= 02;ционность системной структуры П = 57; на уровне компонентоk= 4;. Если можно предвидеть изменения контекста, в который будет встроен программныl= 1; компонент, т= 086; и компонент можно спроектироk= 4;ать таким образом, что изменения будут им учт= 077;ны.<o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102461"></a><a name=3D"_Toc508102234">4.4. Проектировk= 2;ние программныm= 3; модулей и ко= 084;понентов<= /span></a><o:p></o:p></= span></h1> <o:p> </o:p> = Сложная система обычно може = 90; быть разделена н = 72; более прост = 99;е части -</span= > = 84;одули. Модульностn= 0; является важным качеством инженерных процессов и продуктов. Большинствl= 6; промышленнm= 9;х процессов я = 74;ляются модульными = 80; составлены из комплекс = 86;в работ, которые комбинируюm= 0;ся простыми способами (последоват = 77;льными или перекры = 74;ающимися) для достижения требуемого результата. = 043;лавное преимущестk= 4;о модульностl= 0; заключаетсn= 3; в том, что она позволяет п = 88;именять принцип раз = 76;еления задач на дву= 093; этапах: <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и работе с элементами каждого модуля отде = 83;ьно (игнорируя э= 083;ементы других модулей);<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;и работе с общими характерисm= 0;иками групп модулей и от= 085;ошениями между ними с целью объединить, = 080;х в конкретны = 81;, более крупный и сл= 086;жный компонент. <o:p></o:p= > Если данны = 77; этапы выполняютсn= 3; в последоватk= 7;льности, предусматрl= 0;вающей сначала концентрацl= 0;ю процессов н = 72; модулях, а затем -</span= > их объединениk= 7;, то система п= 088;оектируетс&= #1103; сниз = 91; вверх. Если сначала сис = 90;ему разбивают н = 72; модули, а потом работают на = 76; их индивидуалn= 0;ным проектировk= 2;нием, то это -</span= > проектl= 0;рование свер = 93;у вниз.<o:p></o:p> При структурноl= 4; построении = 82;омплексов программ важное знач = 77;ние имеет разме = 88; и сложность компонентl= 6;в для каждого уро = 74;ня иерархии и соответствk= 7;нно число иерархичесl= 2;их уровней k= 6;ля крупных ПС. По принципа = 84; построения, языку описания, размеру и другим характерисm= 0;икам компонентоk= 4; в структуре ПС можно выделить иерархичесl= 2;ие уровни:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;ограммных модулей, оформляемыm= 3; как законченныk= 7; компоненты текста программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>ф = 91;нкциональн&#= 1099;х групп (компоненто = 74;) или пакетов программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>к = 86;мплексов программ, оформляемm= 9;х как законченныk= 7; программныk= 7; продукты определеннl= 6;го целевого назначения. <o:p></o:p> С повышением иерархичесl= 2;ого уровня увеличиваеm= 0;ся размер текс = 90;а программ, реализующиm= 3; компоненты этого уровн= 03; и количеств = 86; обрабатываk= 7;мых переменных. = 054;дновременн&= #1086; совокупносm= 0;и команд все более специализиl= 8;уется и снижается возможносm= 0;ь повторного применения компонентоk= 4; в различных комбинацияm= 3; для решения аналогичныm= 3; задач.<o:p></o:p> Программнm= 9;е модули= решают относительl= 5;о небольшие функционалn= 0;ные задачи, и каждый реализуетсn= 3; 10-100 операторамl= 0; языка= ; прогр= ;аммировани= 03;. Каждый мод = 91;ль может использоваm= 0;ь на входе около десят = 82;а типов переменных. Если для решения небольшой функционалn= 0;ной задачи требуется более 100 опера= торов, то обычно целесообраk= 9;но проводить декомпозицl= 0;ю задачи= на несколько более прост = 99;х модулей. <o:p></o:p> Функционаl= 3;ьные группы прог = 88;амм (компоненты) формируютсn= 3; на базе нескольких или десятко = 74; модулей и решают дост = 72;точно сложные автономные задачи. На их = 88;еализацию целесообраk= 9;но использоваm= 0;ь до десятка тысяч строк текста программы. Соответстk= 4;енно возрастают число используемm= 9;х типов перем = 77;нных и разнообразl= 0;е выходных да = 85;ных. При этом быстро растет числ = 86; типов переменныm= 3;, обрабатывk= 2;емых модул= ;ями и локализующl= 0;хся в пределах одного или нескольких = 84;одулей.<o:p></o:p> Комплексы программ – программныk= 7; продукты создаются для решения сложн= ;ых задач= ; управлениn= 3; и обработки информации. = 042; комплексы о = 73;ъединяются несколько или десят= ;ки функционаl= 3;ьных групп прогр = 72;мм для решения общей целевой задачи сист = 77;мы. Размеры ПС зачастую исчисляютсn= 3; сотнями модул= ;ей, десятками и сотнями тысяч операторов. Встречаютl= 9;я ПС, содержащи= 077; до двух-трех десятков струк= ;турных иерархичеl= 9;ких уровн= ;ей, построеннm= 9;х из модулей.<o:p></o:p> <s= pan style=3D'mso-spacerun:yes'> </sp= an> = П = 88;оектирован&#= 1080;е модулей включает в себя разраб = 86;тку локальных функций и по= 076;робных описаний алгоритмов обработки д = 72;нных; межмодульнm= 9;х интерфейсоk= 4;; внутренних = 89;труктур данных; структурныm= 3; схем переда = 95; управления; средств управления = 74; исключителn= 0;ных ситуациях. С их помощью определяютl= 9;я функции: порядок следования отдельных ш = 72;гов обработки, ситуации и типы данных, вызывающие изменения процесса об = 88;аботки, а также повт= 086;рно используемm= 9;е функции программы. </s= pan>Программны&= #1077; модули для и= 093; многократнl= 6;го использоваl= 5;ия должны бази = 88;оваться на унифицировk= 2;нных правилах структурноk= 5;о построения, оформ= ;ления спецификацl= 0;й требований = 80; описаний текстов программ и комментариk= 7;в. Кроме того, целесообраk= 9;но для каждого проекта дир = 77;ктивно ограничиваm= 0;ь размеры модулей по числу строк = 090;екста с учетом языка прогр = 72;ммирования, например, 30-ю или 50-ю операторамl= 0; (см. лекцию 13). <o:p></o:p> Основная цель такой унификации облегчить разработку модулей, обеспеченl= 0;е их качества = 080; тестированl= 0;я, а также упростить управление их функциям = 80; и характерисm= 0;иками. Эти правила = 074; значительнl= 6;й степени стандартизl= 0;рованы в современныm= 3; языках прог = 88;аммировани&#= 1103;. Однако при и= 093; применении целесообраk= 9;но выделять типовые ас = 89;оциации операторов = 80; ограничениn= 3; их использоваl= 5;ия, а также, вводить правила описа= ;ния текстов программ, комментарl= 0;ев, данных и заголовков модулей, ограничениn= 3; их размеров = 080; сложности. Эти правила наиболее полно должн = 99; соблюдатьсn= 3; при разрабо = 90;ке основной массы функционаl= 3;ьных программ, подлежащиm= 3; повторному использоваl= 5;ию в модифицир = 91;емых версиях программныm= 3; продуктов. Компонентm= 9; организациl= 0; вычислителn= 0;ного процесса, контроля функциониl= 8;ования, ввода-выво = 76;а и некоторые другие могу = 90; иметь отлич = 80;я в правилах структурноk= 5;о построения модулей.<o:p></o:p> Для обеспечениn= 3; управляемоl= 1; модификаци&#= 1080; и развития конфигурацl= 0;й версий программноk= 5;о продукта ва = 78;но стандартизl= 0;ровать структуру базы данных, в которой накапливаk= 7;тся и хранится исходная, промежутоm= 5;ная и результир = 91;ющая информация = 74; процессе функционирl= 6;вания ПС. Основными компонентk= 2;ми этой структуры являются информациоl= 5;ные модули или пакеты данных. В них = 90;акже целесообраk= 9;но использовk= 2;ть типовые структуры, ориентировk= 2;нные на эффектив = 85;ую обработку данных в кон= 082;ретной проблемной области. Объед= ;инение информациl= 6;нных модулей позволяет создавать более сложные структуры данных определеннl= 6;го целевого назначения. Иерархия связей межд = 91; этими компонентаl= 4;и в некоторой степени соответстk= 4;ует процессу обработки и = 087;отокам данных и отн= 086;сительно слабо связана со структурой = 87;рограммных<s= pan style=3D'mso-spacerun:yes'> компонентl= 6;в в ПС. Структуры информациоl= 5;ных модулей цел = 77;сообразно координирl= 6;вать между собой с учетом цели = 080; места их исп= 086;льзования программныl= 4;и компонентаl= 4;и. <o:p></o:p> Особое значение дл= 03; качества модулей и компоненто&#= 1074; крупных ПС имеет станд = 72;ртизация структуры межмодульнm= 9;х интерфейсоk= 4; по передача = 84; управления и по инфор= ;мации. Эти правила формируютсn= 3; на базе описаний языков программирl= 6;вания или оформляютl= 9;я на основе прави= ;л структурнl= 6;го построения программ и базы данных конкретных проектов ПС. В последнем случае соглашения = 86; связях конкретизиl= 8;уются в макрокома = 85;дах межмодульнl= 6;го взаимодейсm= 0;вия. Структурноk= 7; проектировk= 2;ние сложных ком = 87;лексов программ активно развиваетсn= 3; на основе концепции и стандартов = 86;ткрытых систем. Применение стандартоk= 4; открытых систем следует начинать пр = 80; создании ар = 93;итектуры исходных модулей мобильных ПС и БД, а далее неукоснитеl= 3;ьно использоваm= 0;ься при всех процессах ЖЦ. Во всех случая = 93; создание архитектурm= 9; модулей и компонентоk= 4; современныm= 3; сложных систем целесообраk= 9;но вести с использоваl= 5;ием профилей международl= 5;ых стандартоk= 4;, значительl= 5;ая часть= ; которых обесп= ;ечивает мобильносm= 0;ь и возможнос = 90;ь повторного использоваl= 5;ия готовых программныm= 3; средств и ба= 079; данных (см. лекцию 3). <o:p></o:p> Основными целями созд= ;ания и применени= 03; концепции, м= 077;тодов и стандарто = 74; открытых систем явля = 77;тся повышение общей экономичеl= 9;кой эффек= ;тивности разработкl= 0; и функциони = 88;ования систем, а также логич = 77;ской и техническоl= 1; совместимоl= 9;ти их компонен = 90;ов, обеспечениk= 7; мобильностl= 0; и повторног = 86; применения готовых про = 75;рамм и данных. Они реализуют спецификацl= 0;и на интерфейсы, проце= ;ссы и форматы данных, доста= ;точные для того, чтобы обеспечить:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 86;зможность расширения ПС, а также переноса (мобильност= 00;) программныm= 3; компонентоk= 4; и систем, разра= ;ботанных должным образом, с минимальныl= 4;и изменениямl= 0; на широкий диапазон аппаратныm= 3; и операцион = 85;ых платформ;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;вместную работу с другими программныl= 4;и продуктами = 80; системами н = 72; локальных и удаленных платформах;<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 79;аимодейств&#= 1080;е с пользоватk= 7;лями в стиле, облегчающk= 7;м последним, переход от системы к системе (мобильнос = 90;ь пользоватk= 7;лей).<o:p></o:p> = Для достижения этих целей р= 072;звиваются и применяютl= 9;я разли= ;чные проблемно-о = 88;иентирован&#= 1085;ые технологии = 80; комплексы средств авт = 86;матизации ЖЦ мобильны = 93; программ и баз данных, основанные на повторно = 84; использовk= 2;нии готовых апробировk= 2;нных модулей, программныm= 3; компонентоk= 4; и данных, их эффективноl= 4; переносе на различные аппаратные = 80; операционнm= 9;е платформы = 80; согласованl= 5;ом взаимодейсm= 0;вии в распредел = 77;нных информациоl= 5;ных системах. Профессионk= 2;лы в области от= 082;рытых систем акцентируюm= 0; усилия на поиске и создании гибкой, способной к наращиваниn= 2; среды, что базиру = 77;тся на трех напр= 072;влениях стандартизk= 2;ции в области систем (см. лекцию 2):<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 87;паратных и операционнm= 9;х платформ;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тодов и технологи = 80; обеспечениn= 3; жизне= ;нного цикла прикл = 72;дных программныm= 3; средств и ба= 079; данных;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 85;терфейсов компонентl= 6;в и модулей между собой, с операцион = 85;ой и внешней средой. = &nb= sp; = = <o:p></o:p> Методы открытых систем обеспечиваn= 2;т эффективныk= 7; по трудоемкосm= 0;и и качес= ;тву структурноk= 7; проектировk= 2;ние, расширение = 80; перенос готовых про = 75;раммных средств обработки информациl= 0; и баз данных на различные аппаратные = 80; операционнm= 9;е платформы. Эти методы можно разделить н = 72; три части:<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>о = 73;щая концепция и методы непосредстk= 4;енного обеспечениn= 3; мобильностl= 0; компонентоk= 4; программныm= 3; средств и ба= 079; данных в процессе разработки систем за с= 095;ет унификации интерфейсоk= 4; с операционнl= 6;й и аппаратно = 81; средой;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды, поддерживаn= 2;щие мобильностn= 0; компонентоk= 4; и комплексо = 74; программ и данных в распределеl= 5;ных системах и совме= ;стимость их взаимоде = 81;ствия с внешней средой;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды создания текстов программныm= 3; средств, баз данных и их компонентоk= 4; на стандарт = 80;зированных языках= программиl= 8;ования высок= ;ого уровня, обеспечиваn= 2;щие потенциальl= 5;ую возможностn= 0; их переноса на различны = 77; аппаратные платформы.<o:p></o:p>= Первая группа методов соз= ;давалась с ограниченнl= 6;й и определенl= 5;ой целью локализоваm= 0;ь и унифицировk= 2;ть интерфейсы = 87;рограммных компонентоk= 4; между собой, с зара&#= 1085;ее выделеннымl= 0; операционнm= 9;ми системами и = 089; внешней средой. Интерфейснm= 9;е стандарты являются базой для обеспечениn= 3; структурноk= 5;о проектировk= 2;ния, свободного перемещениn= 3; и расширени= 03; программныm= 3; проду= ;ктов и компонентоk= 4; в различные по архитект = 91;ре и функциям операционнm= 9;е окружения и аппаратные платформы. Эти методы п= 086;зволяют разделить функционалn= 0;ную часть комплексов = 87;рограмм и их связи с организац = 80;онным окружением, обеспечиваn= 3; технологичk= 7;скую, архитектурl= 5;ую и языковую независимоl= 9;ть функционалn= 0;ной части= ; прогр= ;амм и данных. Тем самым они являются базой для ре= 072;лизации концепции открытости = 74; системах и обеспечиваn= 2;т свободу разработчиl= 2;ам при выборе методов структурноk= 5;о проектировk= 2;ния и языков программирl= 6;вания для создани= 03; компонентоk= 4; программ и описаний данных. Стандарты этой группы включают группу стандартов POSI= X, в которой определены концепция и функции интерфейсоk= 4; переносимm= 9;х операционl= 5;ых систем, команды управления = 80; сервисные программы, а также расширение = 76;ля переносимыm= 3; операционнm= 9;х систем.<o:p></o:p> Вторая группа методов име= ;ет целью= ; поддержатn= 0; мобил= ;ьность программныm= 3; продуктов в откры= ;тых системах путем унификации их интерфей = 89;ов с внешней средой. Они обеспечиваn= 2;т совместимl= 6;сть обмена данными в различных файловых си = 89;темах и базах данных, унифи= ;кацию администраm= 0;ивного управления и взаимодейl= 9;твия с пользоват = 77;лями, а также методов обеспечениn= 3; безопасносm= 0;и и защиты информации. Таким образом, создается стандартизl= 0;рованная по интерфейсk= 2;м внешн= ;яя среда на различных г = 77;терогенных аппаратных платформах, в которую могут эффективнl= 6; погружатьl= 9;я различные п = 88;ограммы, согласованl= 5;ые по интерфей = 89;ам с этими стандартамl= 0;. Стандарты этой группы = 088;егламентир&= #1091;ют функции и процессы, поддерживаn= 2;щие взаимодейсm= 0;вие с внешней ср= 077;дой:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;нцепции и архитектурm= 1; визуализацl= 0;и информации для взаимодейl= 9;твия с пользоватеl= 3;ями и её предста= 074;ления в базовых системах графическоk= 5;о отображениn= 3;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 88;хитектуру, интерфейсы, базовые пр = 86;цессы и языки управления файловыми системами = 80; базами данных, обеспечивk= 2;ющими их совмести = 84;ость и унификаци= 02; в сложных системах;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>а = 76;министрати&#= 1074;ное управление локал= ;ьными и распределk= 7;нными компонентаl= 4;и систем в процессе решения функционаl= 3;ьных задач обраб = 86;тки информации.<o:p= ></o:p> Третья группа= методов создаваласn= 0; в значительнl= 6;й степени независимо от первой и второй. Эти методы преследуют = 94;ель унифицировk= 2;ть тексты прог = 88;аммных модулей, компонентоk= 4; и описания д= 072;нных, созда= ;ваемых для различных аппаратных платформ пр = 80; любой их архитектурk= 7;, независимо от операцио = 85;ной и внешней ср= 077;ды. Первоначаl= 3;ьное огромное чи = 89;ло языков программирl= 6;вания (свыше 200),= каждый из которых име = 83; несколько диалектов, в результате сократилосn= 0; до 6 - 10 массовых языков, ограниченl= 5;ых станд= ;артами, не допускающиl= 4;и диалектов. Создание современныm= 3; модулей и компонентоk= 4; ПС и БД поддерживаk= 7;тся методами и и= 085;струментал&= #1100;ными средствами технологий, методами тестированl= 0;я и аттестаци = 80; программ и и= 093; интерфейсоk= 4;, а также стандартизl= 0;рованным составом и содер= ;жанием документаm= 4;ии на программ = 99; и базы данных. Эти мk= 7;тоды и средства обеспечиваn= 2;т необходимоk= 7; качество мо = 76;улей и компонk= 7;нтов сложных ПС и БД. В результате обеспечена = 84;обильность функционалn= 0;ной части текстов про = 75;рамм, однако они могут требовать доработок интерфейсоk= 4; для сопряжения = 89; новой средо = 81; аппаратногl= 6; и операционнl= 6;го окружения систем.<o:p></o:p> = <o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p></sp= an> <h1><a name=3D"_Toc508102462"></a><a name=3D"_Toc508102235">Лекция 5. Технико-эко = 85;омическое обоснованиk= 7; проектов программныm= 3; средств</a></h1> <o= :p> </o:p> <h1><a name=3D"_Toc508102463"></a><a name=3D"_Toc508102236">5.1. Цели и процессы технико-эко = 85;омического обоснованиn= 3; проек= ;тов программныm= 3; средств</a></h1> <o:p></o:p> Выбор и формированl= 0;я требований = 82; функционалn= 0;ной пригодностl= 0; ПС наиболее ответственl= 5;ая, стратегичеl= 9;кая задача начальных этапов технико-эко = 85;омического обоснованиn= 3; проекта программноk= 5;о продукта, си= 089;темного проектировk= 2;ния и всего последующеk= 5;о развития ег = 86; жизненного цикла. Жизненный цикл ПС можн= 086; разделить н = 72; две части, существеннl= 6; различающиk= 7;ся экономичесl= 2;ими особенностn= 3;ми процессов и ресурсов, ха= 088;актеристик&= #1072;ми и влияющими на них факторами. В первой части ЖЦ ПС производятl= 9;я системный анализ, проектироk= 4;ание, разработка, тестированl= 0;е и испытания базовой версии программноk= 5;о продукта. Номенклатуl= 8;а работ, их трудоемкосm= 0;ь, длительносm= 0;ь и другие экон = 86;мические характерисm= 0;ики на этих этапах ЖЦ существеннl= 6; зависят от характерисm= 0;ик объекта, технологии = 80; инструмент&= #1072;льной среды разработки. Особенно важно учиты = 74;ать возможное возрастаниk= 7; суммарных з = 72;трат при завышении требований = 82; качеству пр = 86;граммного продукта. Ка= 082; и для других видов промы = 96;ленной продукции, улучшение качества комплексов программ обычно дост = 80;гается не пропорци = 86;нальным, а более значительнm= 9;м возрастаниk= 7;м требуемых для этого ресурсов. Сокращение этой потребностl= 0; в ресурсах ч= 072;сто возможно только за счет принци = 87;иального изменения и совершенстk= 4;ования технологии проектировk= 2;ния и разработк = 80;.<o:p></o:p> Ориентираl= 4;и для оценива = 85;ия необходимыm= 3; ресурсов трудоемкосm= 0;и, длительносm= 0;и и числа специалистl= 6;в по крупным этапам рабо = 90;, при создани = 80; сложных ПС высокого качества, могут служить дан = 85;ые приведенныk= 7; ниже в п. 5.2 – п. 5.4. Максимум трудоемкосm= 0;и и числа специалистl= 6;в приходится = 85;а этапы прогр = 72;ммирования и тестирова = 85;ия компонентоk= 4;, когда привлекаетl= 9;я основная масса программисm= 0;ов-кодировщ&#= 1080;ков для разрабо = 90;ки компонентоk= 4; ПС. При активном использоваl= 5;ии и совершенстk= 4;овании технологий системного анализа и проектировk= 2;ния, проис= ;ходит перераспреk= 6;еление всех видов затрат в сто= 088;ону увеличения трудоемкосm= 0;и начальных э = 90;апов разработки. Это дает значительнl= 6;е снижение использовk= 2;ния совокупных ресурсов дл= 03; всего проек = 90;а. Менее изучены распределеl= 5;ия необходимыm= 3; ресурсов по этапам рабо = 90;, с учетом реа= 083;изации требуемых конкретных характерисm= 0;ик качества ПС. Опубликоваl= 5;ные данные и зависимостl= 0; для различных к = 83;ассов ПС, позволяю= 090; прогнозироk= 4;ать совокупные затраты и другие основные технико-эко = 85;омические показатели (ТЭП), планы и графики раб = 86;т вновь созда = 74;аемых проектов пр = 86;граммных продуктов.<o:p></o:p>= = Вторая часть ЖЦ, отражающаn= 3; эксплуатаm= 4;ию, сопровождеl= 5;ие, модификациn= 2;, управление конфигурацl= 0;ей и перенос ПС на иные платформы, в меньшей степени зав = 80;сит по величине требуемых ресурсов от = 092;ункциональ&= #1085;ых характерисm= 0;ик объекта и среды разработки. = 053;оменклатур&= #1072; работ на эти= 093; этапах боле = 77; или менее определеннk= 2;я, но их трудоемкосm= 0;ь и длительносm= 0;ь могут сильн = 86; варьироваm= 0;ься, в зависимосm= 0;и от массовости = 80; других внешних фак = 90;оров распростраl= 5;ения и применени= 03; конкретных версий программноk= 5;о продукта. Успех ПС у пользоватеl= 3;ей и на рынке, а также будущий процесс раз = 74;ития версий трудно предсказатn= 0;, и он н = 77; связан напрямую с экономичесl= 2;ими параметрамl= 0; процессов разработки ПС. Определяющl= 0;ми становятся потребителn= 0;ские характерисm= 0;ики продукта, а их экономичесl= 2;ие особенностl= 0; с позиции разработчиl= 2;ов и вложенные ресурсы на очередную версию отходят на второй план (см. первую часть ЖЦ). <o:p></o:p> Вследствиk= 7; этого в широк= ;их пределах могут изменяться = 90;рудоемкост&#= 1100; и число специалистl= 6;в, необходимоk= 7; для поддержки этих этапов ЖЦ. Это затрудн= 03;ет статистичеl= 9;кое обобщение ТЭП разл= ичных проектов и прогнозироk= 4;ание на их основе аналогичныm= 3; характерисm= 0;ик новой разработки. Поэтому планы на эти= 093; этапах имею = 90; характер об = 97;их взаимосвязk= 7;й содержания работ, которые требуют рас = 87;ределения во времени, индивидуалn= 0;но для каждого проекта. В резул= ;ьтате прогнозироk= 4;ание и планироваl= 5;ие трудоемкосm= 0;и и длительносm= 0;и этапов= приходитсn= 3; производиm= 0;ь итерационl= 5;о на базе накопл = 77;ния опыта и анализа раз = 74;ития конкретных версий ПС, а также от их у&#= 1089;пеха на рынке.<o:p></o:p> = Для прогнозирl= 6;вания и планированl= 0;я любых процессов или характе = 88;истик объектов (в частности П = 57;) используютl= 9;я исходные да = 85;ные двух типов: <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>ф = 91;нкции и номенклатуl= 8;а характерисm= 0;ик самого прог = 85;озируемого объекта или процесса, для которого необходимо спланироваm= 0;ь жизненный цикл;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>х = 72;рактеристи&#= 1082;и прототипов = 80; пилотных пр = 86;ектов, в некоторой степени, под= 086;бных планируемоl= 4;у объекту, о которых известны реализованl= 5;ые планы и необходимыk= 7; экономичесl= 2;ие характерисm= 0;ики уже заверше = 85;ных аналогичныm= 3; процессов или объектов. <o:p></o:p> Совместнаn= 3;, корректная обработка исходных данных этих двух типов позволяет при проектировk= 2;нии оценивать и получать новые= ;, прогнозируk= 7;мые характерисm= 0;ики процессов, планов и экономичесl= 2;их показателеl= 1; создания ПС. Исходные данные= первого ти = 87;а отражают характерисm= 0;ики конкретногl= 6; создаваемоk= 5;о объекта или процесса, доступные методы и инс= 090;рументальн&= #1099;е средства автоматизаm= 4;ии труда при их создании. Эт= 080; данные посл = 77;довательно детализируn= 2;тся и уточняютс= 03; в процессе проектировk= 2;ния и дальнейшегl= 6; ЖЦ ПС, что, в частности, позволяет уточнять выбор компонентоk= 4; аналогичныm= 3; объектов и и= 093; характерисm= 0;ик для исходных данных второ= ;го типа. <o:p= ></o:p> = Второй тип исходных данных для обоснованиn= 3; и планирова = 85;ия разработки ПС составляют обобщенный = 86;пыт проектировk= 2;ния и экономиче = 89;кие характерисm= 0;ики прото= ;типов нового программноk= 5;о продукта. Для достоверноk= 5;о планированl= 0;я необходимо накопление, обобщение и изучение конкретных данных о реаl= 3;изованных планах, затратах и использоваl= 5;ных ресурсах завершенныm= 3; разработок ПС в различных аспектах. Та= 082;ие ТЭП и факторы, их определяющl= 0;е, изуче= ;ны в процессе обработки значи= ;тельного стати= ;стического материала реальных отечественl= 5;ых и зарубежны = 93; проектов программныm= 3; продуктов и использоваl= 5;ы ниже в метод= 080;ках прогнозироk= 4;ания (см. п. 5.2 - п. 5.4). <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> При технико-эко = 85;омическом обоснованиl= 0; проекта ПС н= 072; любом уровн = 77; целесообраk= 9;но применять методы и методики ад = 77;кватные целям и этапам его реализации. <sp= an style=3D'letter-spacing:.35pt'>Следуе&#= 1090; согласовывk= 2;ть цели оценивания ТЭП с потребностn= 3;ми в информаци = 80;, спосо = 73;ствующей принятию решений для план = 80;рования затрат труд = 72; и других ресурсов. В общем случае необходимо достигать </sp= an>сбалансиро= 074;анного состава целей оценивания разных характерисm= 0;ик, которые бы давали прим = 77;рно одинаковую </sp= an>абсолютl= 5;ую величину уровня неоп = 88;еделенност&#= 1080; оценок для всех компонентов ПС. Кроме того, к= 072;ждая оценка ТЭП долж&#= 1085;а сопровождаm= 0;ься, указанием степени ее неопределеl= 5;ности. По мере разработки проекта их необход= 080;мо пересматриk= 4;ать и изменять, к&#= 1086;гда это становится выгодным. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Привлеченl= 0;е заказчика помогает менее болезненно решать проб = 83;емы управления масштабом проекта и ре= 072;лизуемыми функциями с учетом ограничениl= 1; ресурсов. В зависимостl= 0; от этапа разработки сложного комплекса программ и достоверноl= 9;ти исходных да = 85;ных о характери = 89;тиках и особенностn= 3;х проекта ПС целесообраk= 9;но выбирать и применять разные мето = 76;ики и сценарии технико-эко = 85;омического обоснованиn= 3; проекта и пр= 086;гнозирован&= #1080;я ТЭП. </span= >С самого начала рабо = 90;ы над проекто = 84; ПС важно вести посто= ;янный учет данных = 086; его &#= 1076;ействитель= ной трудоемкосm= 0;и, стоимости и развитии затрат и сравнивать эти данные с реальными оценками характерисm= 0;ик проекта l= 7;о сл= едующим причинам:<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1085;есовершенс= тво исходных данных при оценивании ТЭП (оценки размера, рей= 090;инги влияния фак = 90;оров) определяеm= 0; важность дл= 03; руко= водителя проекта пересматриk= 4;ать их оценки, учитывая новую инфор = 84;ацию, чтобы обеспечить более реальную основу для дальнейшегl= 6; управления проектом; <o:p></o:p></span= > <![if = !supportLists]>- = <![endif]>&#= 1074;следствие несовершенl= 9;тва методов оце = 85;ивания ПС следует сравнивать = 86;ценки с действителn= 0;ными значениями = 80; использоваm= 0;ь эти результ = 72;ты для улучшен = 80;я методов оце = 85;ивания ТЭП;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;оекты ПС имеют тенденцию к изменению х = 72;рактеристи&#= 1082; и экономичесl= 2;их факторов и р= 091;ководителю проекта необходимо идентифици= ровать эти изменения и выполнять реалистичнl= 6;е обновление оценок затра= ;т.<o:p></o:p> При разработке ПС необходимо учитывать, ч= 090;о экономичесl= 2;ие, временные, вычислителn= 0;ные и другие ресурсы на разработку = 80; весь ЖЦ прог= 088;амм в= ;сегда ограниченнm= 9; и используе = 84;ые затраты для улучшения каждой хара = 82;теристики должны учитывать эти огранич = 77;ния. Для рациональнl= 6;го распределеl= 5;ия этих ресурс = 86;в необходимо знать как отражается изменение затрат на улучшении каждой характерисm= 0;ики качества ПС. Эта взаимос = 74;язь затрат ресурсов и значений каждой хара = 82;теристики зависит от н= 072;значения, а также от ряда свойст = 74; и других осо= 073;енностей комплекса п = 88;ограмм, что усложняет учет влияни= 03; таких связе = 81;. Тем не менее,<s= pan style=3D'mso-spacerun:yes'> выявлены основные тенденции т = 72;кого взаимодейсm= 0;вия, которые мог = 91;т служить ори = 77;нтирами при выборе и установленl= 0;и требований = 82; определеннm= 9;м характерисm= 0;икам качества в конкретных проектах ПС. <o= :p></o:p> Оl= 9;новными ресурсами у разработчиl= 2;ов при создани = 80; сложных комплексов программ являются: допустимые тl= 8;удозатраты (стоимость) на разработку ПС с требуемым к = 72;чеством; время R= 11; длительносm= 0;ь полного цикла создания программноk= 5;о продукта; необходимоk= 7; и доступное <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>чl= 0;сло специалистl= 6;в соответствm= 1;ющей квалификацl= 0;и. Потребностn= 0; в этих ресур= 089;ах в наибольше = 81; степени зависит от размера – масштаба и сложности р = 72;зрабатывае&#= 1084;ого ПС. Уто&#= 1095;нения размеров ПС = 080; компонентоk= 4; могут быть решены последоватk= 7;льно к концу детального проk= 7;ктирования,<s= pan style=3D'mso-spacerun:yes'> однако при этом сохран= 03;ется неопределеl= 5;ность оценки размера комплекса п = 88;ограмм и его трудоемкосm= 0;и поря = 76;ка 5 – 10%, связанная = 89; тем, насколько хорошо программисm= 0;ы пони = 84;ают спецификацl= 0;и, в соответствl= 0;и с которыми они должны <sp= an style=3D'letter-spacing:.35pt'>кодиро&#= 1074;ать программу, при этом це= 083;есообразно учитывать:<o:p></o:p>= <![if= !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>цели оцениk= 4;ания ТЭП должны быть согласованm= 9; с потребнос = 90;ями в информаци = 80;, сп&= #1086;собствующе= ;й принятию решений на соответствm= 1;ющем этапе проекта ПС;<o:= p></o:p> <![if= !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>достове = 88;ность оценок= ТЭП должны быть сбалан = 89;ированы для различных компонентоk= 4; системы и величина уровня неопределеl= 5;ности для каждого компонента должна быть примерно одинаковой, если в процессе принятия решения все компоненты имеют одина = 82;овый вес;<o:p></o:p> <![if !supportLists]>- = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>следует возвращ = 72;ться к предшествуn= 2;щим целям оцени = 74;ания ТЭП и изменя= 090;ь их, когда это не= 086;бходимо для ответст = 74;енных бю= джетных решений, принимаемыm= 3; на ранних эт= 072;пах и влияющих на следующие э = 90;апы.<o:p></o:p> Достат = 86;чно трудно оценить объем трудозатраm= 0;, необходимыm= 3; для выполнения = 79;адачи, без достоверноl= 1; информации относительl= 5;о её размера. Таким образ = 86;м, изме&#= 1088;ение размера (сложности) предшествуk= 7;т оценке ТЭП, а эта оценка, в свою очеред= 00;, предшествуk= 7;т составлениn= 2; график= 072; работ. Недостатоm= 5;но достоверныk= 7; оценки влекут проблемы вз = 72;имодействи&#= 1103; разработчиl= 2;а с заказчико = 84; и увеличива= 02;т степень риска проек = 90;а. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> <sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext; mso-bidi-font-weight:normal;mso-bidi-font-style:italic'>Исm= 3;одные данные реальных завершенныm= 3; разработок</spa= n> для оценива = 85;ия ТЭП, собираю= 090;ся, накапливаn= 2;тся и обрабатыв = 72;ются, с начала 70-х годов в разн= 099;х отечественl= 5;ых организациn= 3;х и за р= ;убежом. Они позволили получать и прогнозироk= 4;ать основные об = 86;бщенные ТЭП процессов р = 72;зработки ПС. При этом обычно рассматривk= 2;лся полный= технологиm= 5;еский процесс разработки = 55;С от начала подготовки техническоk= 5;о задания до заk= 4;ершения испытаний базовой вер = 89;ии программноk= 5;о продукта. Учитывалисn= 0; все категории специалистl= 6;в, участвующиm= 3; в создании программ и обеспечиваn= 2;щих разработку, а также все виды работ, связанные с созда= ;нием программноk= 5;о продукта на выделенном интервале времени. Тео= 088;етические работы и системный анализ до подготовки требований = 79;аказчика в значениях ТЭП не учитывалисn= 0;. В общем случае для оценки техн = 80;ко-экономич&= #1077;ских характерисm= 0;ик новых проек = 90;ов необхl= 6;димы исход= ;ные данные:<o:p></o:p>= <![i= f !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>обобщенн&= #1099;е характерисm= 0;ики использоваl= 5;ных ресурсов и т= 077;хнико-эконо= мические показатели завершенныm= 3; разработок </sp= an><span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>-</span= > прототипов ПС, а также оценки влия = 85;ия на их характерисm= 0;ики различных факторов объекта и среды разра = 73;отки;<o:p></o:p> <![i= f !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>реализов&= #1072;нные и обобщенны = 77; перечни вып = 86;лненных работ, и реальные графики про = 74;еденных ранее разра = 73;оток различных классов ПС;<o:p></o:p= > <![if !supportLis= ts]>-&nb= sp; = <![endif]>цели и содержание частных работ в процессе создания сложн= ;ых комплексов программ и требования = 82; их выполнен = 80;ю для обеспечениn= 3; необходимоk= 5;о качества ПС = 074; целом;<o:p></o:p> <![i= f !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>структур&= #1072; и содержани = 77; документов, являвшихсn= 3; результатоl= 4; выполнения частных работ.<o:p></o:p> В качестве базового в = 72;рианта целесообраk= 9;но принять статистиm= 5;ес-кие данные ТЭП, перечень работ и документов жизненного цикла созда = 85;ия наиболее слl= 6;жного встроенногl= 6; комплекса программ реального времени. Н= 072; основе этих исходных данны= ;х могут быть оценен = 99; ТЭП для полн= 086;го цикла разработки ПС конкретногl= 6; вида в более простых случаях путем исключения = 80;з базового варианта работ и документоk= 4;, в которых отс = 91;тствует необходимоl= 9;ть. По оставшим = 89;я работам могут быть о= 094;енены ТЭП для анализируеl= 4;ых вариантов, и<sp= an style=3D'mso-spacerun:yes'> вы= бран из них предпочтиm= 0;ельный. Для технико-эко = 85;омического анализа процесса создания программ ва = 78;нейшей составляющk= 7;й являются соk= 4;окупные трудовые затраты – трудо= ;емкость на непосредстk= 4;енную разработку ПС. <o:p></o:p></= span> Трудоемкос= ;ть разработки программныm= 3; средств наиболее сильно зависит от <sp= an style=3D'display:none;mso-hide:all'>- раз = 84;ера – масштаба комплекса прогр= амм, выраж= енного: числом оператор= ;ов,- строк на языке программирl= 6;вания или функцио-нал= 00;ных точек (см. стандарт ISO 14143:1-5:1998-2004.<= span style=3D'mso-no-proof:yes'> –= Измерениk= 7; функционалn= 0;ного размера). Реальное= ; изменени= ;е созда= ваемых в настояще= ;е время= сложн= ых ПС от </spa= n>104 до 107 строк (LOC</sp= an>) определя= ;ет диапа= зон трудоем= ;ко- сти= разработки </sp= an>таких программ= ; от человеко-го = 76;а до десятков= ; тысяч человеко-ле = 90;. Подтв= ерждена по большому= ; числу проектов= ; высок= ая ст= атис-тическ = 72;я к= орреляция между размером комплексов </sp= an> прогр= амм и т&= #1088;удоем-костью </sp= an>их ра= ;зра- ботки= . <o:p></o:p> Эффективно= ;сть затрат при повторном использоваl= 5;ии комполнентl= 6;в (ПИК) и сборк&= #1077; ПС в з= ависимости от их </spa= n>доли, зачас= тую оцениваласn= 0; путем анализа </spa= n>эквивалентн= 086;й произво- дител= ьности труд= а разработ-чик= ;ов и= длительн= ;ости созда= ния ПС. В ряде случае = 74; особое знач = 77;ние имеет не столько использоваl= 5;ие готовых программныm= 3; компонентоk= 4;, сколько перенос баз данных. Информация = 86; процессах, п= 088;оисходящих во внешней среде, может иметь большой объем и труд= 086;емкость первичного накопления = 80; актуализацl= 0;и, что определ= 03;ет необходимоl= 9;ть ее тщательн = 86;го хранения. Практическl= 0; вl= 9;егда необходимо время и труд= 086;емкость на: <o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>первичны&= #1081; системный анализ целесообраk= 9;ности применения ПИК; <o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>поиск, ада= ;птацию и процессы использоваl= 5;ия готовых ком = 87;онентов;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>оценку затрат с учетом стоимости приобретенl= 0;я и адаптации переносимыm= 3; программ и баз данных; <o:p></o:= p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>интегрир&= #1086;вание в новой операционнl= 6;й или внешней среде;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тестиров&= #1072;ние и испытания компонентоk= 4; в комплексе = 089; унаследоваl= 5;ными программамl= 0;. <o:p></o:p> Для планированl= 0;я разработки сложных ПС важно знать = 080; использоваm= 0;ь эксперименm= 0;альные статистичеl= 9;кие распределеl= 5;ия основных ТЭ = 55; – трудоемко = 89;ти, длительносm= 0;и и числа специалистl= 6;в п= ;о этапам рабо = 90; и по реальному времени реа = 83;изации компонентоk= 4; проектов. Относительl= 5;ые значения распределеl= 5;ия этих величи = 85; на интервале реализации крупных проектов несколько различаютсn= 3; в зависимос = 90;и от размера и типа комплекса п = 88;ограмм, однако наибольший = 80;нтерес представляn= 2;т сложные встроенные = 55;С реального в = 88;емени размером порядка 500 тысяч строк. <o= :p></o:p> <s= pan style=3D'font-size:14.0pt;color:windowtext'> В совокупных затратах на создание полностью новых ПС дом= 080;нирует трудо= ;емкость непосредсm= 0;венной разра= ;ботки программнm= 9;х компонентоk= 4;. &#= 1056;аспределен= ие необходимоl= 1; трудо= ;емкости на этапы разработки программ сложного П = 57; реального времени пре = 76;ставлено в таблице 5.1. Этап технологичk= 7;ской подготовкl= 0; разработкl= 0; включен в техническоk= 7; проектировk= 2;ние, а документи = 88;ование объединено с компл= ;ексной отладкой. В распределk= 7;нии учтены под = 84;ножества работ, соотв= 077;тствующие разным кате = 75;ориям специалистl= 6;в. Все специалисm= 0;ы были разделены на трl= 0; категории: руководитеl= 3;и разработки = 80; системные аналитики; непосредстk= 4;енные разработчиl= 2;и программнm= 9;х компо= ;нентов и специ= ;алисты по комплексирl= 6;ванию; вспомогатеl= 3;ьный персонал, обеспечиваn= 2;щий разработку = 80; документирl= 6;вание программ. Первая и третья кате = 75;ории специалистl= 6;в непосредстk= 4;енно не взаимоде = 81;ствуют с текстом пр= 086;грамм при их отраб= 086;тке, однако их труд является неотъемлемl= 6;й частью всего= ; процесса разработки и в крупных проектах с = 86;ставляет около полов = 80;ны затрат на к= 072;ждом этапе. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = Основ= ное содер= жание, размер= и требуемое = 82;а- честв= о, со&= #1079;даваемых</span= > ПС, практическl= 0; всегда определяют </sp= an>затраты</span= >, связа= нные с их непос-реk= 6;ственной<sp= an style=3D'mso-no-proof:yes'> р= азработкой. Влияние это = 81; части затрат определяет</spa= n> ся наиболее= ; сложным </spa= n>творческ= ;им проце= ссом созда= ния программ, котор= ый завис= ит от многих m= 2;акторов= ;. Некоторы= ;е из них могут из= - менят= ь з= атраты даже в= ; нескольк= ;о раз, но в боль&= #1096;инстве своем изменяют их на десят= ки проце= нтов. Накоп= ленный опыт </span= >создания ПС и l= 6;бобщени= ;е прове= денных иссле= дований позво- лили </span= >выделить= ; четыре основные группы факто= ров, влия= ющих на оценки затра= т при н= ;епосред= ;ственной разработке </sp= an>программ= ;: <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, </span= >от&= #1088;ажающие особе= нности созда= ваемого компл= екса прогр= амм, как объекта</span= > разработ= ;ки, требо= вания к е<sp= an style=3D'mso-no-proof:yes'>го функционалn= 0;ным ха- ракте= рис-тикам и к качеству; </s= pan><o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, определяющи= е организа= ;цию проце= сса разработ= ;ки комп-лексов </s= pan>про- грамм= и его обеспече= ;ние квали= фицированнm= 9;ми специ= алистами; <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, характеризу= ющие технолог= ;ическую среду и <= /span> оснащ= енность инс&#= 1090;рументальн= ыми средст= вами автом= атизации проце= сса разра= ботки прогр= амм; <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l8 level1 lfo87;tab-stops:list 18.0pt 91.95pt left 452.4pt;mso-lay= out-grid-align: none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>факторы, отражающие оснащ= енность проце= сса созда= ния ПС ап- паратурныl= 4;и вычислителn= 0;ными средства= ;ми, на которых реализуютсn= 3; комплексы программ и = 073;азируют= ;ся инструментk= 2;льные систе= мы авто- матиз= ации разработки. <o:= p></o:p> В пре= ;дставленны = 93; четыре= х групп= ах распр= еделены факто= ры, котор= ые наиболее важны при анализе основных затрат на проекты ПС.<sp= an style=3D'mso-no-proof:yes'> В эти г<sp= an style=3D'mso-no-proof:yes'>руппы k= 4;ключены= ; факторы, </sp= an>которые </spa= n>могут изменять оценку = 87;роиз- во-дит= ;ельности т= руда при с= ;оздании ПС не </spa= n>менее чем на 10% в ту ил= и иную </span= >сторону. = 42; то же время= имеющийс= ;я опыт </span= >показыва= ;ет, что отсутств= ;уют отдел= ьные факто= ры или м= ;етоды</span= >, способны= ;е измен= ять на порядок </spa= n> или более основные ТЭ= ;П п= роцесса разра= ботки прогр= амм. Боль- шинст= во факторов изменяет= ; экономич= ;еские харак= теристики разра- ботки программ на десятки проце= нтов и не более чем в= ; 1,5 раза. Для оценивания ТЭП ниже в п.п. 5.2 – 5.4 последоваm= 0;ельно рассмотренm= 9; и рекоменду= 02;тся три методики:<o:p></o:p>= <![if !supportList= s]>-&nb= sp; = <![endif]>Методиl= 2;а 1 – экспертн&= #1086;го технико-эк = 86;номическог&#= 1086; обос&= #1085;ования проектов программныm= 3; средств при подготовке концепции и техническоk= 5;о задания на новый компл = 77;кс программ на основе экспертных данных разработки одной строк = 80; текста прог = 88;амм – прототипо = 74;;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>Методика 2<s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";mso-bidi-font= -weight: bold'> – оценка технико-эко = 85;омических показателеl= 1; проектов программныm= 3; продуктов с учетом совокупносm= 0;и основных фа = 82;торов предваритеl= 3;ьной модели СОСОМО II (см. Boehm B.W. = et al. Software cost estimation with COCO= MO II. Prentice = Hall PTR. New Jersey. 2000); <o:p>= </o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>Методиl= 2;а 3 – уто= чненная оценка технико-эко = 85;омических показателеl= 1; проектов программныm= 3; продуктов с учетом полной сово= купности факторов де = 90;альной модели СОСОМО II.2000 (там же).= <o:p></o:p> В качестве основ= ;ных критериев выбора методик прогнозироk= 4;ания ТЭП разра= ;ботки ПС целесообрk= 2;зно учитывать возможностn= 0; их использо = 74;ания, как на начальных, так и на боле&#= 1077; поздних этапах разр = 72;ботки. Для практическl= 6;го применения модели СОСОМО II опубликоваl= 5; пакет прикладных программ и р= 091;ководство по его применению. Оно иллюстр = 80;ровано формами экранов и несколькимl= 0; обширными практическl= 0;ми примерами применения для технико-эко = 85;омического анализа конкретных проектов сложных комплексов программ. <o:p></o:p></span= > Важl= 5;ейшим фактором пр = 80; технико-эко = 85;омическом обоснованиl= 0;, определяющl= 0;м создание программныm= 3; средств являются люди – спеm= 4;иалисты, с их уровнем профессионk= 2;льной квалификацl= 0;и, а также с мно&#= 1075;ообразием знаний, опыта, стимулов и потребностk= 7;й. Быстрый рос = 90; сложности и повышение ответственl= 5;ости за качество комплексов программ привели к = появлению новых требований = 82; специалистk= 2;м, обеспечиваn= 2;щим все этапы жизненного цикла ПС. При проектировk= 2;нии ПС различны = 93; классов, разделение труда специалистl= 6;в по квалификацl= 0;и при разработке программ и данных, организациn= 3; коллективоk= 4; и экономика таких разра = 73;оток стали важнейшей частью выбора, обуче= ;ния и подготовк = 80; специалистl= 6;в для обеспечениn= 3; всего ЖЦ ПС (см. лекцию 9).<o:p></o:p><= /span> В детальной<sp= an style=3D'mso-spacerun:yes'> модели СОСОМО значительнl= 6;е внимание уделено влиянию организациl= 0; и взаимодейсm= 0;вия коллектива разработчиl= 2;ов на трудоемкосm= 0;ь создания сложных программныm= 3; средств. В со&#= 1089;таве организациl= 6;нных характерисm= 0;ик коллектива рекомендуеm= 0;ся учитывать согласованl= 5;ость целей специалистl= 6;в, участвующиm= 3; в проекте, их психологичk= 7;скую совместимоl= 9;ть и способностn= 0; к дружной коллективнl= 6;й работе, наличие опыта работ = 99; в данном коллективе = 80; другие объективныk= 7; и субъективнm= 9;е свойства уч = 72;стников проекта. При этом большо = 77; значение может иметь личная мотивация и психологичk= 7;ские особенностl= 0; поведения разных специалистl= 6;в при комплексноl= 1; работе над сложным проектом. Эт= 080; характерисm= 0;ики могут быть обобщены в качественнm= 9;й показатель влияния сло = 78;ности взаимодейсm= 0;вия специалистl= 6;в в коллектив = 77;, которому сопос-тавле = 85;ы коэффициенm= 0;ы изменения трудоемкоl= 9;ти разработки ПС. Наилуч-шим считается продолжитеl= 3;ьное корректное взаимодейсm= 0;вие организоваl= 5;-ных специалистl= 6;в с большим опытом работы в данном колл = 77;ктиве при полной согласованl= 5;ости их целей, планов и методов работы. При <s= pan style=3D'font-size:14.0pt'>ра&= #1079;работке прогр= амм больш= ими колле= ктивами значи= тельно повыш= ается роль </span= >квалификаци = 80; руков= одителей р= азработки, что непос= редственно отраж= ается на средней </spa= n>производ= ;ительности труда= всего= коллекти= ;ва. Однак= о форма= лизовать и учесть влиян= ие руков= одителя разработки </sp= an>и в= едущих специ= алистов на<= /span> за- траты и ТЭП комплекса программ пока трудно. <o:p></o:p> Урове= нь квалификаци= и заказ= чика и= опреде- ленно= сть техни= ческого задан= ия на раз= ;работку ПС может весьма сильн= о влият= ь на суммарны= ;е затра= ты и дли= ;- тельн= ость созда= ния прогр= амм. Измен= ения техни= ческого задан= ия и объем переделок = 85;епосред= ;ственно отраж= аются на средней </spa= n>произ- водит= ельности т= руда специалистl= 6;в, рассч= итанной по конечном= ;у размеру созданного комплекса программ. О= собенно сильно на достоверноl= 9;ть техни- ческо= го задан= ия и возраста= ;ние затра= т влияе= т попытка заказчик= ;а форси= ровать сроки= разработ= ;ки. При э= ;том первонач= ;альное техниче= ;- ское= з= адание оказы= вается недос= таточно квали= фицированнm= 9;м и под= ;- верга= ется в дальнейш= ;ем много= кратным измен= ениям. Этому же мож&= #1077;т спосо= бствовать разли= чие между= заказчик= ;ом и разра= ботчиком в квалифик= ;ации, уровн= е поним= ания целей= разра- ботки= и необходимыm= 3; затрат l= 5;а реализацию допол= нительных тре- бован= ий.<o:p></o:p> При проектировk= 2;нии и создании высококачеl= 9;твенных комплексов программ, прежде всег = 86;, необходима организациn= 3; и тесное взаимодейсm= 0;вие представитk= 7;лей заказчика и разработчиl= 2;ов проекта. Взгляды и тр= 077;бования заказчика, в основном, отражаются = 74; функционалn= 0;ных и потребите = 83;ьских характерисm= 0;иках ПС. Устремлениn= 3; разработчиl= 2;ов направлены на возможностn= 0; и способы их реализации = 89; требуемым качеством. Эти различи= 03; исходных точек зрени= 03; на проект приводят к тому, что некоторые н = 77;формализов&#= 1072;нные представлеl= 5;ия тех и других имеют зоны неоднозначl= 5;ости и взаимного непониманиn= 3;, что может пр= 080;водить к конфликта = 84;. = <o:p></o:p> Затраты и труд специалистl= 6;в при реализации крупномасшm= 0;абного проекта ПС можно распределиm= 0;ь по дв= 091;м категориям специалистl= 6;в: разрабатывk= 2;ющим компоненты = 80; ПС в целом и обеспечиваn= 2;щим технологию = 80; качество программноk= 5;о продукта (см. лекцию 9). Организацl= 0;онное разделение = 89;пециалисто&#= 1074;, осуществляn= 2;щих разработку = 55;С (первая кате= 075;ория), и специалистl= 6;в, контролируn= 2;щих и управляющ = 80;х его качеством в процессе разработки = 80; всего ЖЦ (вто&#= 1088;ая категория), должно обеспечиваm= 0;ь эффективноk= 7; достижение заданных характерисm= 0;ик, а также независимыl= 1;, достоверныl= 1; контроль затрат и качества ре = 79;ультатов разработки.<o:p= ></o:p> = Затl= 8;аты на технологию = 80; инструментk= 2;льные программныk= 7; средства автоматизаm= 4;ии разработки ПС обычн= о являются весьма весом= ;ыми при использоваl= 5;ии высокоэффеl= 2;тивных автоматизиl= 8;ованных технологий. При технико-эк= 086;номическом обоснованиl= 0; проекта следует учи = 90;ывать, что размер и сложность с = 86;здаваемого ПС значител= 00;но влияет на выбор инструментk= 2;льных средств и уровня авто = 84;атизации технологии, = 072; также на дол= 102; этих затрат = 074; общих затратах на разработку. Встречаютсn= 3; ситуации, пр= 080; которых зат = 88;аты на технолог = 80;ю достигают 30 <= span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - 50% общих затрат= на разработку. Такие затра = 90;ы могут быть оправданы повышением производитk= 7;льности труда, сокращениеl= 4; сроков= разработкl= 0; и последующl= 0;м снижением затрат на м= 085;ожество базовых версий ПС. Однако чаще всего эта группа затрат= при создании первой= версии сложных ПС находится в = 087;ределах 30% от суммарных затрат. В первом приб = 83;ижении степе= ;нь автоматизk= 2;ции разработкl= 0; программ отраж= ;ает размер программныm= 3; средств, используемm= 9;х в технологичk= 7;ских системах. Этот показатель соотв= ;етствует сложности систе= ;м автоматизаm= 4;ии разработки программ и п= 088;опорционал&= #1077;н затратам на их приобретенl= 0;е (или создание) и эксплуатацl= 0;ю. <o:p></o:p> </= span>Стремление уменьшить технологичk= 7;ские затраты в период разр = 72;ботки без учета последующеk= 5;о испол= ;ьзования ПС, его компо= ;нентов и всего жизн= 077;нного цикла может оказаться мало полезным, а в некоторых случаях привести к значительl= 5;ому увеличению совокупных затрат в ЖЦ. При применении сложных ПС э= 090;и затраты исч = 80;сляются сотнями человеко-ле = 90;, что определ= 03;ет особую актуальноl= 9;ть их снижения. Поэтому необходим системный а = 85;ализ распределеl= 5;ия и использоваl= 5;ия технологиm= 5;еских ресурсов на разработку программ с учетом всег = 86; их жизненного цикла, включая сопровождеl= 5;ие и возможный перенос на д= 088;угие платформы. <o:p></o:p= > Уровень автоматизаm= 4;ии и качество технологии = 80; инструментk= 2;льных средств, = 80;спользуемы&#= 1093; для поддержки всего жизненного цикла ПС, обычно силь = 85;о коррелировk= 2;н с достигаемыl= 4; качеством к = 86;мплексов программ, а также с качеством с = 88;едств автоматизаm= 4;ии для оценивания этого качества. Поэтому определениk= 7; уровня зрелости технологичk= 7;ской поддержки процессов жизненного цикла, организациl= 6;нного и инструмен = 90;ального обесп= ;ечения качества ПС, непосредстk= 4;енно связано с выбором и оцениваниеl= 4; реальных ил = 80; возможных характерисm= 0;ик качества конкретногl= 6; комплекса программ. В </= span>модели СОСОМО для оценивания технико-эко = 85;омических показателеl= 1; при разработке ПС рекомендуеm= 0;ся методологиn= 3; сложных программныm= 3; средств СММ = 211; система и модель оценки зрел = 86;сти комплекса, применяемыm= 3; технологичk= 7;ских процессов жизненного цикла ПС (см. лекцию 3). Эти уровни зрелости характериk= 9;уются степенью формализацl= 0;и, адекватносm= 0;ью измерения и документирl= 6;вания процессов и продуктов Ж = 62; ПС, широтой применения стандартов = 80; инструментk= 2;льных средств автоматизаm= 4;ии работ, наличием и полнотой реализации функций системой обеспечениn= 3; качества технологичk= 7;ских процессов и их результа = 90;ов. &#= 1042; модели СОСОМ = 54; приводятс&= #1103; количествеl= 5;ные реком = 77;ндации к= ;оэффициент = 86;в влияния уровней зрелости СМ = 52; на трудоемк = 86;сть реаl= 3;изации сложных проектов ПС.<sp= an style=3D'mso-spacerun:yes'> Влиян= ;ию технологичk= 7;ской зрелости разработки ПС в детальной модели СОСОМО сопоставлеl= 5;ы уровни СММ, для каждого из которых приводятся коэффициенm= 0;ы изменения трудоемкоl= 9;ти разработки.<o:p= ></o:p> </spa= n>Для приближен = 85;ой оценки влияния на трудоемкосm= 0;ь некот= ;орых характерисm= 0;ик процессов разработки ПС, в детальной модели СОСОМО выде = 83;ена небольшая группа пока = 79;ателей и соответствm= 1;ющие им наборы рейтингов. Инструментk= 2;льные системы, подде= ;рживающие разработку, описаны качественнm= 9;ми характерисm= 0;иками и рейтингам = 80;, изменяющимl= 0; трудоемкосm= 0;ь в пределах приблизитеl= 3;ьно 20% l= 6;т средней – но= 084;инальной. Уровень технологии = 80; комплекса и = 85;струментал&#= 1100;ных средств особенно сильно влия = 77;т на ТЭП крупных проектов ПС. Поэтому зат = 88;аты на их реализ= 072;цию и применени = 77;, целесообраk= 9;но учитывать конкретно с использоваl= 5;ием функций и характерисm= 0;ик проек= ;та. <o:p></o:p> В модели и таблицах отмечено зн = 72;чительное влияние на трудоемкосm= 0;ь ПС директив = 85;ого огра = 85;ичения сроков разработки</spa= n> относительl= 5;о типовых – но= 084;инальных. При ограничениl= 0; сроков, сокра= ;щению трудоемкосm= 0;и может сопутствовk= 2;ть значительнl= 6;е снижение качества ПС = 080; увеличение рисков реализации проекта. Для уменьшения сроков разр = 72;ботки есть ряд путей, с помощью которых рук = 86;водство может добиваться некоторого ускорения разработки за счёт увеличения трудоемкосm= 0;и и стоимости проекта, для чего рекоме = 85;дуется:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>обеспечить детальные структурирl= 6;вание комплекса п = 88;ограмм на модули и спецификацl= 0;и интерфейса для обеспечениn= 3; максимальнl= 6;го параллелиз= ма работы специалистl= 6;в;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>приобрести и освоить технологичk= 7;ские, инструментk= 2;льные средства дл= 03; более быстр = 86;го кодированиn= 3;, контроля и тестированl= 0;я и обучить разработчи= ков их использо = 74;анию;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;еспечить дополнителn= 0;ную подготовку = 87;рограммист&#= 1086;в и группы тестирован= ия к работе в тематическl= 6;й облас= ;ти функций про = 77;кта;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>привлечь дополнителn= 0;ный вспомогатеl= 3;ьный персонал;<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>отложить нk= 2; время не существеннl= 6;е документирl= 6;вание проекта.<o:p></o:p> Тем не менее, есть предел сокр = 72;щению сроков разработки = 89; по- мощью увеличения числа специалистl= 6;в и приобрете = 85;ия оборудованl= 0;я. При максимальнl= 6; возможном с = 86;кращении сроков разработки до 75% от опт= имального, затраты возрастают на 25%. <o:p></o:p> </spa= n>При разработке комплексов программ систем реального времени бол= ;ьшие затраты могут потребоватn= 0;ся для обеспечениn= 3; тестированl= 0;я и испытаний ПС, которые непосредстk= 4;енно не учитываютсn= 3; моделью СОСОМО. Основ= ные усилия сосредотачl= 0;вались на процесса = 93; программирl= 6;вания и автономно = 81; отладки компонентоk= 4;. На этих этапах выявлялась основная масса дефектов и ошибок, хотя при использовk= 2;нии ПС и сопl= 8;овождении обнаруживаl= 3;ось некоторое и = 93; количество. В последнее в = 88;емя центр тяжести раз = 88;аботки сложных ПС сдвинулся к начальным этапа= ;м и внимание акцентировk= 2;но на предотвра = 97;ение ошибок, прежде всег = 86; путем тщательногl= 6; системного проектировk= 2;ния ПС из готовы= 093; программныm= 3; компонентоk= 4;, а также на комплексноl= 1; отладке и испытаниях = 74; реальном времени. <o:p></o:p> Эта&#= 1087;ы комплексноl= 1; отладки, испытаний = 80; модификациl= 0; программ имеют много общего, в основе которого лежит широкое при = 84;енение их тестиров = 72;ния для обнаруж = 77;ния ошибок и удостовереl= 5;ия функционалn= 0;ной корректносm= 0;и ПС. Разработка детерминирl= 6;ванных тестов при о= 090;ладке модулей и некоторых групп программ в большинстk= 4;е случа= ;ев производитl= 9;я вручную. Однако их доl= 3;я может= ; составлятn= 0; замет= ;ную часть общих затра = 90; на отладку компонентоk= 4;. Достаточно = 72;втономными и локализуе = 84;ыми обычно явля= 02;тся затраты на стохастичеl= 9;кие тесты и тест= 099; в реальном времени, используемm= 9;е при комплек = 89;ной отладке и испытанияm= 3; (см. лекцию 14). <o:p></o:p= > При технико-эко = 85;омическом обоснованиl= 0; проектов ко = 84;плексов программ, на оценку трудоемкосm= 0;и их разработки может оказать сущ = 77;ственное влияние ограничен = 85;ость вычислителn= 0;ных ресурсов специализиl= 8;ованных, реализующиm= 3; ЭВМ реального времени. Эт= 086; привело к необходимоl= 9;ти разрабатывk= 2;ть мето = 76;ы эффективноk= 5;о использоваl= 5;ия аппаратных ресурсов ЭВ = 52;. Одним из важнейших и наиболее общих показ = 72;телей, характеризm= 1;ющих возможностn= 0; применения таких ЭВМ, яв&#= 1083;яется их производ = 80;тельность для конкрет = 85;ых задач реального времени. При этом сущест = 74;енным ограничиваn= 2;щим фактором являются длительносm= 0;ь, в течение которой ЭВМ может быть предоставлk= 7;на для решения данной задачи, или то реальное время, в пределах которого це = 83;есообразно получить ре = 79;ультаты для их практическl= 6;го использоваl= 5;ия. При ограничениn= 3;х ресурсов вследствие требований минимизациl= 0; весов и габаритов специализl= 0;рованных, реализующиm= 3; ЭВМ в авиационныm= 3;, ракетных и космическиm= 3; системах, их экономное использоваl= 5;ие остается актуальным и следует учи = 90;ывать при обоснованиl= 0; соответствm= 1;ющих проектов ПС</sp= an>. <o:p></o:p> Быстр= ый рост в мире масштабов - размk= 7;ров компл= ексов прогр= амм и баз= ; данных</spa= n> , решk= 2;ющих е= диную целев= ую задач= у, потре= бовал создания но- вых= , более эффек= тивных метод= ов разработки </sp= an>слож- ных с= ;истем. = 42;озникла проблема разработ= ;ки функц= ионально закон= ченных ПС и БД и и= х компо-ненто = 74;, потенци= ;- ально= <= /span>готовых </spa= n>к м= ногократноl= 4;у приме= нению в разл= ;ичной внешн= ей и операцио= ;нной среде= , а т= акже в различны= ;х сочетаниях их взаимод = 77;йс- твия. Унифи= 082;ация всегда m= 0;ребует </spa= n>некоторы= ;х ресур= сов, которые в дан= ;- ном с= ;лучае, = 74;ыражает= ;ся в дополнит= ;ельной трудо= емкости создания повторно используемm= 9;х - прогр= амм и данных, = 72; т= акже в увеличен= ;ии необходимоl= 1; па- мяти= и= производ= ;ительности ЭВМ д= ;ля их реализации. </s= pan> Сохра= нение и развитие довольно широкого= ; спектра </spa= n>архитект= ;ур ЭВМ, естес= твенно приве= ло к повт= ;орному испол= ьзованию компо= нентов (ПИК) н = 77; тольк= о на однотипных </sp= an>платформ= ;ах, но и к= разработ= ;ке ПС и БД, пере- но-= симых на различные аппаратные </span= >и о= перационныk= 7; платф= ормы. При этом, выделили= ;сь две те&= #1093;нологическ= ;ие проблемы:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l249 level1 lfo85;tab-stops:list 18.0pt 101.85pt left 234.0pt; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>создание= ; программ= ;ных компо= нентов и баз= ; д= анных, которые рент= абель-но</span= > п= овторно приме= нять и/или </spa= n>переноси= ;ть на ра= ;зличные операционнm= 9;е и аппаратны = 77; платформы;= <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-list:l249 level1 lfo85;tab-stops:list 18.0pt 101.85pt left 234.0pt; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>проблема= ; реализац= ;ии повто= рного испол= ьзования и/или </spa= n>переноса </spa= n>ПС и= БД д= ля созда= ния из них новых систем на иных платформаm= 3;.<o:p></o:p> Увеличениk= 7; за&= #1090;рат при ре= ;шении перво= й пробл= емы должн= о компен-сиров= ;аться с= окращением затра= т при с= ;оздании= ; комплекс= ;ов прогр= амм и баз= ; д= анных на базе готовых </spa= n>компонен= ;тов. Освое= ние метод= ов и средств </spa= n>решения </spa= n>этих проблем </spa= n>позволил= ;о ка- честв= енно изменить= ; п= роцессы со= зда-ния с= ложных– комплексов программ и ре= зко повыс= ить произ= водитель-ность труда специали- стов </span= >при их раз&= #1088;аботке. Это а= ;ктивизи= ;ровало в последние = 75;оды ин- терес= к= проблеме= ; мобильно= ;сти прогр= амм и данных во всех отрас- лях п= ;рименен= ;ие вычис= лительной техни= ки. Создание новых Пi= 7; и= БД путем переноса= ; их с других k= 2;ппаратн= ;ых и операционнm= 9;х плат- форм </span= >стало особенно= ; актуальн= ;ым для современныm= 3; администраm= 0;ивных систе= м госуд= арственногl= 6; и регионал= ;ьного управ- ления= , управлениn= 3; отраслям= ;и и предприя= ;тиями, а также бk= 2;нковс- кими </span= >системам= ;и и в социальн= ;ой сфере= . <o:p></o:p> На практике= ;, при создании нового i= 5;С, н= ;е всегда имеет= ся полны= й набор готовых</span= >, и пригодны= ;х для п= ;рименен= ;ия программнm= 9;х компо-н= ;ентов. Тогда при с= ;борке k= 4;ерсии i= 5;С м= ожет потре= боваться дораб= отка отдел= ьных компо= нентов, их сопряжен= ;ие в новых соче- тания= х, = и создание новых программ= ; для решения дополнит= ;ельных задач. Поэтому целе-сообраk= 9;но оцени= вать трудо= емкость сборо= чного прогр= аммированиn= 3; с учетом m= 5;астичны= ;х затра= т на<= /span> <= /span>новые кl= 6;мпо- ненты= . Относителn= 0;ное сниже= ние трудо= емкости разра= ботки в первом прибл= ижении пропо= рционально доле </span= >готовых </spa= n>ПИК. В пред&= #1077;ле при создании базовой </spa= n>версии i= 5;С п= олностью из многокра= ;тно при- меняе= мых готовых ко = 84;понентов, т= рудоемкостn= 0; может сокра= титься в 3 -</span= > 5 р= аз. В промежут= ;очных случа= ях, когда= готовые </spa= n> компо= ненты используютl= 9;я части= чно, оценк= у измен= ения трудоем- кости= можно провести по степени сокра= щения затра= т на пр= ;о- грамм= ирование и автономную </sp= an>отладку </spa= n>всех необходи= ;мых компо- ненто= в. <o:p></o:p> <o:p></o:p> <h1> <a name=3D"_Toc508102464"></= a><a name=3D"_Toc508102237">5.2. Методика 1 – экспертное технико-эк = 86;номическое<s= pan style=3D'mso-spacerun:yes'> = обоснованl= 0;е проектов программныm= 3; средств</a> <o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> <o:p></o:p= > </sp= an>В эm= 0;ой методике реализоваl= 5; метод прогноза Т = 69;П с учетом экспер= тной оценки минимальноk= 5;о числа факто = 88;ов. Данная методика оценки ТЭП может приме = 85;яться, когда определены цели и общие &#= 1092;ункции проекта ПС, сформулироk= 4;анные в концепции = 080; первичных требованияm= 3; с достоверн = 86;стью около 20 – 40% . Основная цk= 7;ль оценки ТЭП = 211; подготовитn= 0; возможностn= 0; принять обоснованнl= 6;е решение о допустимосm= 0;и дальнейшегl= 6; пl= 8;одвижения проекта в область системного анализа, разработки требований = 80; предваритеl= 3;ьного проектировk= 2;ния. Если оказываетсn= 3;, что рассчит = 72;нные технико-эко = 85;омические показатели = 80; требуемые р = 77;сурсы не могут быт= 100; обеспечены для продолж = 77;ния проекта, то возможны кардинальнm= 9;е решения: либ= 086; изменение некоторых ТЭП и выделяемых ресурсов, либо прекращениk= 7; проектировk= 2;ния данного ПС. Учитывая полноту и достоверноl= 9;ть доступных х = 72;рактеристи&#= 1082; и требовани = 81; к проекту ПС должны бm= 9;ть определены цk= 7;ли и возможная достоверноl= 9;ть технико-эко = 85;омического обоснованиn= 3; продолжениn= 3; проектиров&#= 1072;ния ПС. <o:p></o:p> При первичном технико-эко = 85;омическом обоснованиl= 0; сложных проектов ПС, составляетl= 9;я таблица 5.2 – исходными, для которой являются концепm= 4;ия проекта ПС и комплекс предваритеl= 3;ьных требований</spa= n> к иерархичесl= 2;ому набору функций, которые мог = 91;т быть разбит = 99; на предпола = 75;аемые фактическиk= 7; компоненты ПС. В дальней&#= 1096;ем разбиение может детализироk= 4;аться, формируя упрощенный или более точный уровень абс = 90;ракции и взаимодейсm= 0;вия компонентоk= 4;. Наиболее низкий и глубокий уровень детализациl= 0;, как правило, редко формируетсn= 3; ко времени первоначалn= 0;ной экспертной оценки размера ПС. <o:p></o:= p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>Эти факторы могут быть оценены квалифицирl= 6;ванными экспертами на основе им= 077;ющегося у них опыта реализации предшествоk= 4;авших подобных проектов, а также испол= 00;зования опубликоваl= 5;ных данных. При наличии необходимыm= 3; данных важн = 86; оценить их д= 086;стоверност&= #1100; и возможную точность (20 – 40%).<= span style=3D'mso-spacerun:yes'> Наиме= ;нее точный из перечисленl= 5;ых факторов по = 83;ностью определяет достоверноl= 9;ть расчета технико-эко = 85;омических показателеl= 1; проекта ПС, поэтому желательно, чтобы значения точности экспертногl= 6; оценивания перечисленl= 5;ых факторов бы = 83;и сбалансироk= 4;аны. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'>При наличии перечисленl= 5;ых исходных да = 85;ных и положителn= 0;ной оценке целе = 89;ообразност&#= 1080; экспертногl= 6; анализа ТЭ = 55; проекта может реали = 79;овываться методиl= 2;а, состоящая и = 79; следующих шагов:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>опр= еделение класса, сложности функций про = 77;кта программноk= 5;о средства;<o:p></o:p>= <![if !supportLis= ts]>-&nb= sp; = <![endif]>экс= пертная оценка размера – масштаба, чи= 089;ла строк предполагаk= 7;мого текста разрабатывk= 2;емых программ, с учетом размера повторно ис = 87;ользуемых компонентоk= 4; и характери = 89;тик возможного языка программирl= 6;вания;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>экс= пертная оценка возможной средней про = 80;зводительн&#= 1086;сти труда специалистl= 6;в при разрабо = 90;ке программ и/и= 083;и стоимости (и длительносm= 0;и) разработки одной сроки текста программ проекта ПС;<o:p></o:p= > <![if !supportLis= ts]>-&nb= sp; = <![endif]>рас= чет возможной полной трудоемкосm= 0;и и длительно = 89;ти разработки проекта ПС, а также среднего числа специ = 72;листов, необходимыm= 3; для его реализации;<o:p= ></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>обо= бщение основных технико-эко = 85;омических показателеl= 1; и полной стоимости разработки проекта ПС, анализ результатоk= 4; и технико-экономи-ческое обоснованиk= 7; рентабелn= 0;ности продолжениn= 3; проектировk= 2;ния комплекса программ.<o:p></o:p>= <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Достовернl= 6;сть прогнозов ТЭП зависит, прежде всег = 86;, от точносm= 0;и экспертной оценки исходных данных: размера ̵= 1; масштаба ПС = 080; от достовер = 85;ости экспертной оценки производитk= 7;льности труда специ = 72;листов или оценки стоимости разработки одной строк = 80; текста программ (см. таблицу 5.2). Кроме того, экспертны&= #1077; оценки зависят от компетенциl= 0; и объективн = 86;сти экспертов, и= 093; &#= 1086;птимистичн= ости, пессимистиm= 5;ности, знания суще = 89;твенных особенностk= 7;й проекта. <o:p></o:p> Экспертнаn= 3; оценка размера про = 77;кта программноk= 5;о средства наиболее сложная задача в это= 081; методике. Пl= 8;иступая к разработк = 77; комплекса программ, ка= 082; в любой проф= 077;ссионально&= #1081; деятельносm= 0;и, необходимо сначала провести реалистичеl= 9;кую оценку возм = 86;жного м= ;асштаба проекта – поставленнm= 9;х целей, ресурсов проекта и вы= 076;еленного времени. Задач= ;а управления масштабом состоит в задании базовых требований, = 082;оторые включают разбитое на компоненты = 86;граниченно&#= 1077; множество функций и требований, намеченных для рk= 7;ализации в конкретно = 81; версии= проекта. Бk= 2;зовый уровень масштаба должен обеспечиваm= 0;ь:<o:p></o:p> <![if !supportList= s]>-&nb= sp; = <![endif]>при= емлемый для заказчика минимум функций и требований = 82; проекту;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>разумн= 091;ю вероятностn= 0; успеха с точки зрени= 03; возможностk= 7;й и ресурсов коллектива разработчиl= 2;ов.<o:p></o:p> При оценивании масштаба следует определить приоритеты функций для установленl= 0;я состава работ, согласованl= 5;ого между заказ = 95;иком и разработч = 80;ком, которые обn= 3;зательно должны быть выполнены и для определ = 77;ния базового уровня масштаба конкретногl= 6; проекта с допустимым риском неуспешной реализациl= 0;. Сокращение масштаба проекта до размеров, адекватных выделенномm= 1; времени и ре= 089;урсам, может привести к к= 086;нфликтам заказчиков = 80; разработчиl= 2;ов. Для уменьшения вероятностl= 0; таких конфликтов целесообраk= 9;но активно привлекать заказчиков = 82; управлению их требованияl= 4;и и масштабом проекта, что= 073;ы обеспечить как качеств = 86;, так и своевременl= 5;ость разработки ПС.<o:= p></o:p> <sp= an style=3D'font-size:14.0pt'> <s= pan style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>Эl= 2;спертные оценки удельных затрат на строку текста прог = 88;амм относятся к полному циклу разработки крупных комплексов программ, начиная от с= 086;здания концепции и требований до завершен = 80;я испытаний и передачи программноk= 5;о продукта заказчику или пользоватеl= 3;ям, с учетом всего состава коллектива = 89;пециалисто&#= 1074; всех квалификацl= 0;й. По мнению некоторых специалистl= 6;в, несмотря на появление новых меm= 0;одов и инструмен = 90;альных средств разработки сложных ПС, средняя производитk= 7;льность при их создании за = 087;оследние двадцать ле = 90; осталась почти неизменной = 80; составляет около 3000 строк кода на одного разработчиl= 2;а проекта в го= 076; (порядка 250 строк на человеко-ме = 89;яц). Это отражае = 90; то, что уменьшение = 74;ремени, затрачиваеl= 4;ого на цикл разработки, не может быт= 100; достигнуто за счет значительн= ого повышения производитk= 7;льности труда отдельных с = 87;ециалистов. Причем это практическl= 0; не зависит о= 090; усовершенсm= 0;вований языка программирl= 6;вания, организациl= 6;нных усилий со стороны менеджеров, от наличия или отсутствия некоторых о = 90;дельных видов инструментk= 2;рия и автоматизаm= 4;ии работ, хотя значительнm= 1;ю роль играет увеличившаn= 3;ся д= ;оля повторно используемm= 9;х компонентоk= 4; (ПИК). На самом деле при дос= 090;аточно высоком уровне техн = 86;логии (3 – 4 уровень СММ – см. лекцию 3) большое зна = 95;ение имеет возросший размер и сложность с = 86;става функционалn= 0;ных задач компл = 77;ксов программ, а также значительнl= 6;е повышение требуемого качества создаваемыm= 3; ПС. <= o:p></o:p> </spa= n>В качестве ориентиров</spa= n> при экспертной оценке ТЭП, для таблицы 5.2 можно использоваm= 0;ь следующие д = 72;нные сре = 76;ней трудоемкосm= 0;и разработки сложных комплексов программ. Весьма общи = 77; данные опуб = 83;икованы в виде широких диапазонов производитk= 7;льности труда: дл= 03; относительl= 5;о простых ПС – 8 = LOC= на человеко-де = 85;ь, и 4 LOC на человеко-де = 85;ь для достаточно сложных ПС. Так же приво= 076;ятся широкие диапазоны п = 88;оизводител&#= 1100;ности труда при разработке программ на ассемблере R= 11; 60 – 500 LOC на чело = 74;еко-месяц, и 50 – 300 LOC на человеко-ме = 89;яц для языков высокого ур = 86;вня. Подобные оц = 77;нки можно испол= 00;зовать к&= #1072;к ориентиры при первичных определениn= 3;х ТЭП.<o:p></o:p> Более точные оценки производитk= 7;льности при разработке программ различного размера и классов на основе обобщения статистичеl= 9;ких данных множ = 77;ства проектов пр = 77;дставлены в базовой модели СОСОМО:<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>для программ администраm= 0;ивных систем (ИПС) размером по = 88;ядка 30 тысяч строк оценка производитk= 7;льности составляет около 220 строк на человеко-= 084;есяц, а для ПС размером 500 тысяч строк = 211; 160 строк на чел= ;овеко-месяц;<o= :p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>для встроенных комплексов программ реального времени раз = 84;ером 30 тысяч строк рекомендуеm= 0;ся для оценок использоваm= 0;ь производитk= 7;льность около 140 строк на человеко-= 084;есяц, а для крупны= 093; ПС размером 500 тысяч строк предлагаетl= 9;я значение производитk= 7;льности около 80 строк на человеко-= 084;есяц.<o:p></o:p> Эт&#= 1080; данные находятся в середине представлеl= 5;ных выше диапаз = 86;нов и их целесоо= 073;разно использоваm= 0;ь при экспертной оценке полной труд = 86;емкости разработки соответствm= 1;ющих новых ПС. При использоваl= 5;ии готовых повторно используемm= 9;х компонентоk= 4; обобщенная производитk= 7;льность труда возрастает = 80; зависит от доли таких компонентоk= 4; в комплексе программ. Их также можно использоваm= 0;ь для оценки пl= 6;лной стоимости проекта конкретногl= 6; ПС. Однако при этом необходимы удельные данные средней стоимости труда одног = 86; человеко-ме = 89;яца специалистl= 6;в в конкретно = 84; предприятиl= 0; с учетом все= 093; накладных расходов, ко= 090;орые могут различатьсn= 3; в несколько раз. Такие сведения обычно являются коммерческl= 6;й тайной, и при использоваl= 5;ии данной методики дл= 03; определеннl= 6;го проекта ПС, их слk= 7;дует запрашиватn= 0; у экономичесl= 2;их служб конкр = 77;тного предприятиn= 3;м. Тем нk= 7; менее, опубликоваl= 5;ы о= ;риентиры стоимост= ;и разработки одной строк = 80; текста программ ре = 72;льного времени около= ; 100$ и бол= ее, а для = 72;дминистрат&#= 1080;вных систем около 20$ – 50$. <o:p></o:p> </spa= n>Эксперm= 0;ная оценка длительносm= 0;и разработки</spa= n> сложных ПС (таблица 5.3), может базироватьl= 9;я на формулах модели СОСОМО (см. п. 5.3).<= /span> Основой дл= 03; расчета длительносm= 0;и целесообраk= 9;но использоваm= 0;ь рассч= ;итанную ранее трудоемкосm= 0;ь разработки проекта ПС, от которой н= 077; линейно зависит длительносm= 0;ь (месяцы) приблизитеl= 3;ьно равная труд = 86;емкости (человеко-ме= 089;яцы) в степени 0,3. Например, крупные проекты ПС р= 077;ального времени размером около 500 тысяч строк требуют для реализации около 3,5 лет, а небольшие (30 тысяч строк) – около одного года. При этом сле= 076;ует учитывать, что необходимаn= 3; численностn= 0; коллектива специалистl= 6;в изменяется = 74; десяток раз.<o:= p></o:p> Экспертна= 03; оценка необходимоk= 5;о числа специ = 72;листов всех кв&= #1072;лификаций рассчитываk= 7;тся путем деления полной трудоемкосm= 0;и разработки ПС на длител= 100;ность её реализац = 80;и. Для примера крупного проекта ПС р= 077;ального времени, размером 500 тысяч строк,<sp= an style=3D'mso-spacerun:yes'> необходим = 86;е число специ = 72;листов достигает 160 ч= еловек, а для относительl= 5;о небольшого проекта (30 тысяч строк) </= span>– в десять раз меньше (16 человек). Аналогич&= #1085;о можно получить оценки необходимоk= 5;о числа специ = 72;листов на выделенных крупных этапах разр = 72;ботки ПС, что полезно для первичного формированl= 0;я коллектива = 80; оценки возм = 86;жности реализации им конкретн = 86;го проекта ПС (см. таблицу 5.1). </= span> <o:p></o:p></sp= an> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </sp= an> <o:p></o:p></span= > <h1><a name=3D"_Toc508102465"></a><a name=3D"_Toc508102238">5.3. Методика 2 – оценка технико-эко = 85;омических показателеl= 1; = проектов программныm= 3; продуктов с учетом сово = 82;упности факторов = предваритk= 7;льной модели СОСОМО </a>II<o:p></o:p></h1> <o:p> </o:p> <s= pan style=3D'font-size:14.0pt;color:windowtext'> </sp= an>В СО= 057;ОМО II для оценки ТЭП представлеl= 5;ы две модели – дл= 103; этапов пред = 74;арительног&#= 1086; и детальног = 86; проектировk= 2;ния (см. Boehm B.W. et al.<s= pan lang=3DEN-US style=3D'font-size:14.0pt;font-family:"Times New Roman","serif= "; color:windowtext;mso-ansi-language:EN-US'>= Software cost estimation with COCOMO II. Prentic= e&= nbsp; Hall PTR. New Jersey. 2000)</spa= n>. Предваритk= 7;льная модель пред = 85;азначена для анализа общих, архитек= ;турных решен= ;ий и выработки стратегий последующеl= 1; разработки при начальных сведениях о содержании предваритеl= 3;ьного проекта. Дет= 072;льная модель рекомендуеm= 0;ся для примене = 85;ия при разработке наиболее сложных и до= 088;огих систем, когда требуется тщате= ;льный учет ряда факторов, влияющих на оценку стои = 84;ости на уровне техническоk= 5;о проекта ПС. В &= #1086;беих моделях исх = 86;дным и, определяющl= 0;м достоверноl= 9;ть прогнозов, является размер комп = 83;екса программ (с учетом повторно ис = 87;ользуемых компонентоk= 4;) и совокупносm= 0;ь набора влияющих факторов. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> На </span= >этапе предваритеl= 3;ьного проектировk= 2;ния комплекса п = 88;ограмм, после утверждениn= 3; требований = 80; концепции проекта, пов= 099;шается достоверноl= 9;ть данных о функциях, спецификацl= 0;ях, компонентаm= 3; и структуре разрабатывk= 2;емого ПС. Это позволяет, п= 088;ежде всего, более точно оцени = 90;ь размер – масштаб ПС и возможностn= 0; использоваl= 5;ия готовых про = 75;раммных компонентоk= 4; из других аналогичныm= 3; проектов. Если достоверноl= 9;ть оценки размера ПС достигает 15 – 20%, то при определ = 77;нии ТЭП, целесообрk= 2;зно сбалансироk= 4;ано выделять и учитывать ф = 72;кторы, влияние которых на трудоемкосm= 0;ь и стоимость достаточно велико, и составляет также около 20%. Таких= факторов может быть около 5 – 10, и их число зависит от конкретных = 93;арактерист&#= 1080;к объекта и среды разработки ПС. При технико-эко = 85;омическом обоснованиl= 0; проекта ПС н= 072; этом этапе, с&#= 1086;став и номенклатуl= 8;а учиты= ;ваемых факторов должны выбираться путем включения в анализ, тех факторов, ко= 090;орые достаточно влияют на ТЭ= 055; конкретногl= 6; проекта. <o:p></o:p> Так как величи= на и достоверноl= 9;ть определениn= 3; размера проекта ПС <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>кl= 3;ючевой фактор последующеk= 5;о технико-эко = 85;омического анализа, то целесообраk= 9;но применять н = 77;сколько доступных методов для его оценива = 85;ия. Конкретизаm= 4;ия функций, структуры П = 57; и состава компонентоk= 4; проекта позволяет более досто = 74;ерно определить размеры групп прогр = 72;мм и, суммируя их, рассчитать размер всег = 86; комплекса программ. Кроме того, на этом этап= 077; повышается возможностn= 0; выбора и использоваl= 5;ия аналогов данного проекта, так как становя = 90;ся более определеннm= 9;ми задачи, функ= 094;ии и компонент = 99; разрабатывk= 2;емого ПС, для, котор= ;ого желательно найти аналоги с известными = 72;пробирован&#= 1085;ыми характерисm= 0;иками. Ос= обенно сильно на ТЭ= 055; влияет использl= 6;вание готовых компонентоk= 4; из предшест = 74;ующих разработок. </s= pan>Пl= 8;и анализе аналогов могут быть выделены ко = 84;поненты, пригодные для повторного применения = 74; новом проекте. Это позволяет о = 94;енить возможную долю использоваl= 5;ия готовых компонентоk= 4; и тем самым определить = 01;квивалентн&#= 1099;й размер комп = 83;екса программ, по= 076;лежащий непосредстk= 4;енной разработке. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n>Для трех классо = 74; комплексов программ в п= 088;едваритель&= #1085;ой модели СОСОМО II), представлеl= 5;ы коэфф= ициенты для расчета </s= pan>зависимо= ;сти трудо= емкости разработки </sp= an>про- грамм С (челове&#= 1082;о-месяцы) от &#= 1080;х объемов – П (тысяч&#= 1080; строк текста) (таблиц&#= 1072; 5.4). <= /span>Для аппроксимац= ии завис= имости трудо= емкости от размера ПС, рекомендуеm= 0;ся испол= ьзовать степ = 77;нную функцию </spa= n>вида: <o:p></o:p>= = &nb= sp; = &nb= sp; С =3D А × = П Е . = = (5.1)<o:p></o:p> = <o:p></o:p> При р= ;азработ= ;ке ПС бол= ;ьшого размера- , должна возрастать </sp= an>сложност= ;ь разра= ботки по сравнени= ;ю с ПС малого объема, так как в боль&= #1096;их прогр= аммах сущес= твенно усложняютсn= 3; взаимосв= ;язи компо= нентов по информации </sp= an>и управl= 3;ению, а= также становят= ;ся более= трудоемк= ;ими проце= ссы планиро= ;ва- ния= и управления проектом в х= оде разра= ботки. Выдви= нутая гипо- теза= , = о возрастаниl= 0; трудоемк= ;ости разра= ботки с ростом размера ПС быстр= ее, чем п= ;о линейному = 79;акону, = 89;праведл= ;ива, если </span= >показате= ;ль степе= ни в уравнении = 88;егресси= ;и Е > 1. - В ряде работ опре= делены коэффициенm= 0;ы А и Е = 74; ура= ;в- нения= х с= тепенной регре= ссии, показ= ывающие характер зависимо= ;сти трудо= емкости от размера ПС. В таблице 5.4. представлеl= 5;ы значения коэффициенm= 0;ов регрессии для моделей СОСОМО для трех основных классов проектов программныm= 3; средств. Выражение (5.1) l= 9; использоваl= 5;ием этих коэффициенm= 0;ов и значений размера ПС – П в тысячах строк ассемблера</spa= n> рекомендуеm= 0;ся для прогнозироk= 4;ания трудо-емкос = 90;и полной разработки = 74; чk= 7;ловеко-меся&#= 1094;ах. <o:p></o:p></spa= n> <s= pan style=3D'font-size:14.0pt;color:windowtext;mso-no-proof:yes'> Длит&= #1077;льность разработки программныm= 3; средств- является= ; важнейши= ;м ТЭП- , поскольку ч= ;асто она определяет </span= >общие сроки= разработ= ;ки систе= м, а значит, = 73;ыстроту= ; реали= зации идей в различны= ;х облас= тях автомат= ;и- зации= . При определениl= 0; коэффициенm= 0;ов в табл= ;ице 5.5 за начало l= 8;азработ= ;ки ПС при= ;нят момен= т начал= а создания техни= ческого задан= ия, а= за окончание – заве= ;ршение - испыт= аний программноk= 5;о продукта в ц= елом .&= nbsp; Диапазону размеров современ= ;ных ПС в т= ри-четыре поряд= ка (до 10 млн. строк) соответс= ;твуют прибл= изительно такие= же ди= ;а- пазон= ы и= зменения трудоемкоl= 9;ти и= стоимост= ;и их разработ= ;ок. = Од- нако= , очевидна принципиалn= 0;ная нерен= табельностn= 0; разра= ботки да- же очень сложных </spa= n>ПС б= олее 5 лет. = 057; д= ругой сторо= ны, программы да&= #1078;е в нескольк= ;о тысяч строк по пол&= #1085;ому техно= логическомm= 1; циклу= с испытаниямl= 0; как продукции - редко создаются = 79;а время, меньш= ее, чем п= ;олгода-- год. i= 8;аким образом, </sp= an>вариация длительносm= 0;ей разра= боток ПС - меньш= е, чем в= ;ариация= ; их трудl= 6;емкости, и не превы= шает деся- тикра= тный д= иапазон. Длите= льности разра= боток – Т огl= 8;аничены сверх= у и снизу, и о= дним из основных= ; факторов= ;, определя= ;ющих эти грани= цы, являе= тся масштаб комплекса = 87;рограмм= ; <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol;mso-no-= proof: yes'>-</= span> П. <o:p></o:p> Чтобы сократить ош&= #1080;бки, связа= нные с неопреде= ;ленностью из- мерен= ия размерk= 2; программ= ;, исследов= ;ана зависимо= ;сть длительно- сти р= ;азработ= ;ки от ее трудоемкосm= 0;и. Учитывалась т= ;оль- ко трудоемк= ;ость не= посред-стве = 85;ной разработки </sp= an>программ= ; С </span= >без затра= т на средства= ; автомати= ;зации разра= ботки- . Обработка т= ;ех же, что= выше, наборов </spa= n>данных l= 7;озволил= ;а полу- чить коэффициенm= 0;ы уравн= ения регре= ссии представлеl= 5;ные в таблице 5.5. Обобщенныk= 7; данные длительносm= 0;и разработки R= 11; Т по l= 2;лассам комплексов </sp= an>программ= ; аппроксим = 80;ро- ваны уравнениямl= 0; регресси= ;и <= /span>по методу наиме= ньших квадр= атов в зависимостl= 0; от размера ПС и= от трудоемкосm= 0;и их ра= ;з- работ= ки: <o:p></o:p></spa= n> <o:p> </o:p> = Т =3D G</span= > × С= H</span= > . = &nb= sp; = &nb= sp; = (5.2)<o:p></o:p> <o:p></o:p> Установлен = 86; , чт&= #1086; длительн= ;ость разра= ботки ПС меньше подвергаетl= 9;я измен= ениям при а= ;втомати= ;зации разра= ботки или д= ;ругими </spa= n>метода- ми, чем трудоемкост= ь или п= ;роизвод= ;ительность труда= . Н= еобходи- мость= в= ыполнения при р= ;азработ= ;ке ПС определе= ;нной совокупносm= 0;и этапо= в и операций= ; в з= аданной техно= логической последоваm= 0;ельнос- ти остается= ; более или менее постоянной при р= ;азличных воздеl= 1;ст- виях </span= >на процесс разра= ботки. Исклю= чением являе= тся применение повторно используемm= 9;х компонентоk= 4; ( ПИК), = 87;ри котором значител= ;ьно сокращаютl= 9;я этапы= п= рограмми- рован= ия и автономной отлад= ки модул= ей и групп программ= ;, а так- же в т= ой или и= ;ной степени </spa= n>длительн= ;ость други= х этапо= в.. Поэто= му завис= имость T</s= pan> , о<= span style=3D'mso-no-proof:yes'>т доли ПИК о= ;казывае= ;тся нелин= ейной, и заметное= ; сокращен= ;ие длительносm= 0;и разра= ботки прояв= ляется тольк= о при с= ;оздании= ; базовой </spa= n>версии i= 5;С п= рактически полно= стью из готовых компонентоk= 4;. <o:p></o:p> </s= pan>Оценка требуемого среднего числа специ = 72;листов для конкрет = 85;ого проекта ПС предваритеl= 3;ьно может быть рассчитана путем деления оценки величины трудоемкосm= 0;и разработки (5.1) на длительносm= 0;ь разработки (5.2= ). Однако рациональнl= 6;е число специ = 72;листов, участвующиm= 3; в проекте ПС распределяk= 7;тся не равномер = 85;о по этапам работ (см. таб&= #1083;ицу 5.1). Поэтому целесообраk= 9;но определять число и квалификацl= 0;ю необходимыm= 3; специалистl= 6;в с учетом этапов разработки комплексов программ. О= 073;общенные значения пр = 77;дварительн&#= 1086;го расчета ТЭП целесообрk= 2;зно оформлять в виде таблиц = 99; 5.3, где оценки представляn= 2;тся также с учетом пессимистиm= 5;еских и оптимисти = 95;еских результатоk= 4; определеl= 5;ия масштаба проекта комплекса п = 88;ограмм. <o:p></o:p> Для= учета= ; влияниn= 3; на трудоемкосm= 0;ь различных факторов удобно пользоватьl= 9;я коэффициенm= 0;ами (рейтингами) изменения трудоемкоl= 9;ти (КИТ) –&= nbsp; М (i), учитывающl= 0;ми зависимостn= 0; от i-го фактора l= 5;а совокупные затрат труда. В них входя= 090; факторы процесса непосредстk= 4;енной разработки, факторы программноl= 1; и аппаратур = 85;ой оснащенносm= 0;и, а также квалификацl= 0;я специалистl= 6;в (таблица 5.6). Затраты на разра= ;ботку С и объем прогр = 72;мм П могут быть связаны через показ = 72;тель интегральнl= 6;й с= ;редней производитk= 7;льности труда= разработчl= 0;ков Р. Непосредсm= 0;венно затраты на разработку можно представитn= 0; как частное от размера П= 057; и производи = 90;ельности труда Р =3D 1 / &= #1040;, корректируk= 7;мой произведенl= 0;ем коэффициенm= 0;ов изменения трудоемкосm= 0;и (КИТ – М</spa= n> (i) ) :<o:p></o:p> = <o:p></o:p> = П = Е <o:p></o:p> C =3D <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>---</span= > × <span style=3D'font-= size: 14.0pt;font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi= -font-family: "Times New Roman";mso-bidi-font-family:"Times New Roman";color:windowtext; mso-char-type:symbol;mso-symbol-font-family:Symbol'>P &#= 1052; (i) =3D А × П Е × <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>P</span= > &#= 1052; (i) . = &nb= sp; (5.3)<o:p></o:p> = Р </spa= n>i = &nb= sp; i<o:p></o:p> <o:p></o:p> </spa= n> Средн= яя производитk= 7;льность труда коллектива специалистl= 6;в при разработке сложного полностью нового комплекса п = 88;ограмм Р= в выражении (5.3) может служить ориентиром для сравнен = 80;я эффективноl= 9;ти труда при создании различных п = 88;оектов ПС. Эта харак&#= 1090;еристика, конечно, ра= 079;личается для различных классов, размеров и других пара = 84;етров комплексов программ, однако диапазон этих различ = 80;й не столь велик как из= 084;енения размера и требований = 82; качеству. Та= 082; при диапазоне изменения размеров программ реального в = 88;емени на четыре порядка средняя производитk= 7;льность труда изменяется только в два раза, что в ряде случае = 74; существеннl= 6; облегчает упрощенные оценки и про= 075;нозировани&= #1077; ТЭП. <o:p></o:p> В предва= рительной модели СОСОМО= II при достаточноl= 1; достоверноl= 9;ти определениn= 3; масштаба ПС рекомендуеm= 0;ся в выражении (5.= 3) учитывать семь фактор = 86;в М (i), представлеl= 5;ных в таблице 5.6. Для каждого из них в табл&#= 1080;це 5.7 приведены значения рейтингов (коэффицие = 85;тов изменения трудоемкосm= 0;и), которые целесообраk= 9;но использоваm= 0;ь при выборе определеннl= 6;го содержания факторов конкретногl= 6; проекта ПС, а также свободный столбец для выбранных значений. Результаты уточненногl= 6; расчета трудоемкосm= 0;и проекта ПС п= 086; формуле (5.3) следует использоваm= 0;ь для последующеk= 5;о определениn= 3; длительносm= 0;и (выражение 5.2) l= 0; требуемого среднего числа специалистl= 6;в. <o:p></o:p>= <o:p> </o:p> <h1><a name=3D"_Toc508102466"></a><a name=3D"_Toc508102239">5.4. Методика 3 – уточненная оценка технико-эко = 85;омических = &nb= sp; показателk= 7;й проектов пр = 86;граммных продуктов с учетом полной сово= купности факторов детальной м = 86;дели СОСОМО </a>II.2000<sp= an style=3D'mso-fareast-font-family:"MS Mincho"'><o:p></o:p></h1> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'><o:p> </o:p> П = 88;и д= ;етальном проектировk= 2;нии возможно значительнl= 6;е повышение точности определениn= 3; размера – ма= 089;штаба проекта комплекса программ. После= ;довательна= 03; детализациn= 3; и конкретизаm= 4;ия проекта ПС позволяет уточнять ег = 86; будущий размер и привлекать для расчета трудоемкосm= 0;и большее число факто = 88;ов, способных повысить точность пр = 86;гноза всех ТЭП. Разработка полного содержания спецификаm= 4;ий функций и структуры программныm= 3; компонентоk= 4;, их вз= ;аимодейств = 80;я и интерфейсоk= 4;, а также архитектурm= 9; всего комплекса программ и базы данных,<sp= an style=3D'mso-spacerun:yes'> обычн= ;о позволяют повысить точность определениn= 3; размера ПС, приблизитеl= 3;ьно на 10%. Поэтому пр = 80; расчете трудоемкосm= 0;и разработки при прогнозироk= 4;ании целесообраk= 9;но выбирать и учитывать влияние ряд = 72; дополнителn= 0;ных факторов из таблицы 5.8, которые не оценивалисn= 0; в методиках 1 и 2, вследствие</s= pan> их отноl= 9;ительно меньшего влияния. <o:p></o:p> Таких дополнителn= 0;ных факторов обычно може = 90; быть выделе = 85;о около 10, котор= ые целесообраk= 9;но рассматривk= 2;ть и учитывать при оценках,<sp= an style=3D'mso-spacerun:yes'> если он способен = 080;зменить трудоемкосm= 0;и разработки конкретногl= 6; проекта на 5 – 10%. Анали= ;з, выбор и оценивани = 77; коэффициенm= 0;ов влияния F ( j ) и <sp= an style=3D'color:windowtext;mso-bidi-font-weight:normal;mso-bidi-font-style:i= talic'>М ( i ),= этих дополнителn= 0;ных факторов до = 74;ольно сложный процесс. Он оправдан, когда совместное влияние совокупносm= 0;и этих дополн = 80;тельных факторов может измен = 80;ть оценки трудоемкосm= 0;и на 10 – 20%. В результа = 90;е расчет трудоемкосm= 0;и несколько усложняетсn= 3;, однако процессы последующеk= 5;о расчета дли = 90;ельности разработки = 80; необходимоk= 5;о числа специ = 72;листов практическl= 0; не изменяются. = 042; целом, процессы методики 3 технико-эко = 85;омического обоснованиn= 3; проекта ПС с учетом ряда дополнителn= 0;ных факторов, практичесl= 2;и не отличает = 89;я от предыдущей предваритеl= 3;ьной методики 2, однако требуется более тщательное определениk= 7; размера комплекса программ, и оценивания влияния на трудоемкосm= 0;ь разработки большего числа факторов.<o:p></o:p>= Для более точного технико-эко = 85;омического обоснованиn= 3; проектов ПС</sp= an> при детальном проектировk= 2;нии обычно целесообраk= 9;но учитывать влияние ряд = 72; дополнителn= 0;ных факторов из четырех гру = 87;п позволяет повысить достоверноl= 9;ть прогнозироk= 4;ания технико-эко = 85;омических показателеl= 1; ПС до уровня около 5 – 10%. В дет= альной модели СОСОМО II влиян= ие на трудоемкосm= 0;ь определяют 22 фактора, из которых пят= 00; – масштабны = 77; факторы, характеризm= 1;ются множителем </sp= an>F ( j ) <sp= an style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho"'>в значении степени раз = 84;ера ПС, а 17 множителеl= 1; <= /span>M = ( i= ) непосредстk= 4;енно изменяют трудоемкосm= 0;ь разработки. Перечень, ма= 082;симальные значения и содержание этих множит = 77;лей представлеl= 5;о в таблице 5.8. Пр= ;и этом номина = 83;ьными (средними) ниже принимаютсn= 3; все M ( i ) </span= >=3D 1,00, при которы = 93; соответствm= 1;ющий фактор практическl= 0; не влияет на трудоемкосm= 0;ь ПС. <o:p></o:p> Для выполнения оm= 4;енок трудоемкосm= 0;и разработки</spa= n> (человеко-ме= 089;яцы) в детальной модели СОСОМО II предложены выражения, уточняющие зависимостl= 0;, представлеl= 5;ные выше в п. 5.3: </span= > </spa= n> = &nb= sp; <o:p></o:p> <s= up> = &nb= sp; = &nb= sp; n<sp= an style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext; mso-no-proof:yes'> = &nb= sp; = &nb= sp; <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = C =3D &= #1040; × П E<s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> × <span style=3D'font-size:14= .0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";mso-bidi-font-family:"Times New Roman";color:windowtext; mso-char-type:symbol;mso-symbol-font-family:Symbol'>P M ( i ) , = &nb= sp; = &nb= sp; (5.4)<o:p></o:p> = &nb= sp; </spa= n>i =3D 1 = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> = &nb= sp; = &nb= sp; 5<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> где: &= nbsp; А =3D 2,94; E =3D B + 0,01× <span style=3D'font-size:14.0pt;font-famil= y: Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-family:"Times= New Roman"; mso-bidi-font-family:"Times New Roman";color:windowtext;mso-char-type:symbo= l; mso-symbol-font-family:Symbol'>å F ( j ); B =3D 0,91. = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = &nb= sp; = &nb= sp; = j =3D 1 </spa= n><o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> Для прогнозироk= 4;ания длит&#= 1077;льности (месяцы) разработки ПС рекоменд = 91;ются выражения: = = &nb= sp; = &nb= sp; = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";color:windo= wtext'> = Т =3D </sp= an>G</spa= n> × С</sp= an> H , = &nb= sp; = &nb= sp; = &nb= sp; (5.5)<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> = &nb= sp; = &nb= sp; = &nb= sp; = <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> где: G =3D 3,67; <o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> = &nb= sp; = &nb= sp; 5 <o:p></o= :p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal'> = H = =3D D + 0,02× 0,01× <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-bidi-font-family:"Times New Rom= an"; color:windowtext;mso-char-type:symbol;mso-symbol-font-family:Symbol'>å= F (j</spa= n>) =3D D + </spa= n>0,02×(E</spa= n> – B) ; D =3D 0,28. <o:p></o:p> = &nb= sp; = j<sp= an style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho"'> =3D 1</span= > <o:p></o:p= > <o:p> </o:p> В модели СОСОМО II подд&= #1077;рживаются вероятностl= 5;ые диапазоны оценок, представляn= 2;щие одно станда = 88;тное отклонение на фоне наиболее достоверныm= 3; оценок. При использоваl= 5;ии представлеl= 5;ных выражений для прогнозироk= 4;ания ТЭП конкретных проектов сл = 77;дует выбирать набор факторов (кk= 2;либровать модель), имеющих наибольшие значения ко= 01;ффициентов изменения трудоемкосm= 0;и (КИТ) F ( j ) и M ( i ) </span= > &#= 1074; соответствl= 0;и с характери = 89;тиками конкретногl= 6; проекта и ср= 077;ды разработки = 80; вставлять вm= 9;бранные значения в таблицу 5.8. Значения этих коэффициенm= 0;ов и уровни оценок их влияния на трудоемкосm= 0;ь по основным = 074;ыделенным группам факторов представлеl= 5;ы в модели СОСОМО II. <o:p></o:p> З= 072;казчик может заказать разработку специальныl= 4; образом калибр= ованной версии коэ = 92;фициентов в формулах (5.4) = 80; (5.5), которая должна боле = 77; точно отраж = 72;ть применяемm= 9;е технологичk= 7;ские процессы, особенностl= 0; и возможностl= 0; проекта ПС, чем в методи= 082;е 2 . При калибровке модели СОСОМО II последоватk= 7;льно выполняютсn= 3; следующие процедуры для конкретногl= 6; проекта: <o:p></o:p> = <![if !supportLists]>-&nb= sp; = &nb= sp; <![endif]>выбир= 072;ется набор факторов M ( i ) <= span style=3D'font-size:14.0pt;font-family:"Times New Roman","serif"'>, оказывающиm= 3; наибольшее вли-яние на прогнозируk= 7;мую трудоемкосm= 0;ь проекта ПС;<o:p></o:p= > <![if !supportLists= ]>-&nb= sp; = &nb= sp; <![endif]>устанав= ;ливаются значения масштабных факторов F = ( j );<o:p></o:p> <![if !supportLists= ]>-&nb= sp; = &nb= sp; <![endif]>для каждого из выбранных факторов производитl= 9;я оценка коэффициенm= 0;а изменения т = 88;удоемкости для анализи = 88;уемого проекта ПС.<o:p></o:p= > </spa= n>Выбор с= ;остава и оценку факторов, влияющих н = 72; ТЭП конкрет = 85;ого проекта ПС предваритеl= 3;ьно целесообраk= 9;но проводить п = 86; шагам при калиброванl= 0;и модели СОСОМО II на основе совокупносm= 0;и 22 факторов из таблицы 5.8. Первоначаl= 3;ьно должна производитn= 0;ся оценка коэффициенm= 0;ов влияния пяти групп факторов = - F ( j ). </sp= an>В выраженияm= 3; (5.4), (5.5) значения M ( i ) отражаю= ;т коэффициенm= 0;ы влияния i -ых факторов на трудоемк = 86;сть разработки ПС, которые первоначалn= 0;но (все n ) считаются равными единице. Предваритеl= 3;ьный расчет трудоемкосm= 0;и и длительносm= 0;и разработки ПС при M ( i ) =3D 1 может слу = 78;ить уточненныl= 4; ориентиром, так как он базируется на более точном знач = 77;нии размера проекта комплекса п = 88;ограмм и более адекватных значениях основных коэффициенm= 0;ов, чем в l= 4;етодике 2. </span= ><o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext;mso-bidi-font-weight:normal;mso-bidi-font-styl= e: italic'> Выб= ирать и учитывать следует те факторы, ко= эффициенты</spa= n> влияния которых на трудоемкосm= 0;ь в конкретно = 84; проекте, имеют достаточнуn= 2; величину, сбалансироk= 4;анную с точностью определениn= 3; размера ком = 87;лекса программ ил = 80; превышают е= 05;. Эти факторы можно разделить н = 72; две группы, которые существеннl= 6; различаютсn= 3; по степени влияния на трудоемкосm= 0;ь разработки ПС. В первую группу – F <= /span>( j ) следует включать, кроме размера и доли повтор = 85;о используемm= 9;х компонентоk= 4;, совокупносm= 0;ь факторов, которые способны изменять трудоемкосm= 0;ь в несколько (до 3 – 5) раз:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>нов= изну проекта комплекса программ;<o:p></o:p>= <![if !supportLis= ts]>-&nb= sp; = <![endif]>нео= бходимую степень согласованl= 5;ости проекта с требованияl= 4;и техн= ического задания;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>нал= ичие управления рисками и архитектурl= 6;й проекта;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>уро= вень обобщенной слаженностl= 0; и организов = 72;нности коллективнl= 6;й разработки проекта;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>уро= вень обеспечениn= 3; и оснащения технологии разработки по оценке СММ.<o:p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> </spa= n>Вторую группу – M ( i ) следует выбирать из совокупносm= 0;и перечисленl= 5;ых в таблице 5.8 семнадцати факторов, таких которые в ко= 085;кретном проекте могут повлиять на изменение трудоемкосm= 0;и разработки на 10 – 20%, соизмеримоk= 7; с точностью оценок разм = 77;ра ПС:<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тре= бования надежности ПС;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тре= бования степени соответствl= 0;я документацl= 0;и программноl= 4;у продукту;<o:p></o:p>= <![if !supportLis= ts]>-&nb= sp; = <![endif]>тем= атическая квалификацl= 0;я специалистl= 6;в;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>тех= нологическk= 2;я квалификацl= 0;я проектировm= 7;иков и программи = 89;тов;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>ста= бильность состава коллектива разработчиl= 2;ов;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>огр= аничения ресурсов объектной ЭВМ реально = 75;о времени;<o:p></o:p> <![if !supportLis= ts]>-&nb= sp; = <![endif]>ста= бильность требований заказчика к задачам и функциям ПС.<o:= p></o:p> <s= pan style=3D'font-size:14.0pt;font-family:"Times New Roman","serif";mso-fareast= -font-family: "MS Mincho";color:windowtext'> Остальная совокупносm= 0;ь около десят = 80; факторов модели СОСОМО II обычно может изменять трудоемкосm= 0;ь проекта менее чем на 10% и их не целесообраk= 9;но учитывать в процессе детальног = 86; проектировk= 2;ния, когда точность оценивания размера проекта ПС м= 086;жет составлять около 10%. <o:p></o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Обобщенны = 77; оценки технико-эко = 85;омических показателеl= 1; проекта ПС целесообраk= 9;но представляm= 0;ь в виде табли= 094; с указанием достоверноl= 9;ти оценок результатоk= 4; расчетов. На основе анализа результатоk= 4; и оценивани= 03; рассчитаннm= 9;х характерисm= 0;ик следует вып = 86;лнять заключителn= 0;ное техникl= 6;-экономичес&#= 1082;ое обоснованиk= 7; проекта ПС и опред&= #1077;лять:<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>целесооб&= #1088;азно ли продолжать работы над к= 086;нкретным проектом ПС = 074; направлениl= 0; детализациl= 0; требований, функций и те= 093;нико-эконом= ических характерисm= 0;ик или следует его прекратить, вследствие = 85;едостаточн&#= 1099;х ресурсов специалистl= 6;в, времени или возможной стоимости и трудоемкосm= 0;и разработки;</sp= an><o:p></o:p> <![if !supportLis= ts]>- = <![endif]>при наличии достаточныm= 3; ресурсов, следует ли провести ма = 88;кетинговые исследованl= 0;я для определениn= 3; рентабельнl= 6;сти полного вып = 86;лнения проекта ПС и создания программноk= 5;о продукта дл= 03; поставки на = 088;ынок;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>дос= таточно ли полно и корректно формализовk= 2;ны концепция и требования = 82; проекту ПС, на осl= 5;ове которых проводилисn= 0; расчеты ТЭП, или их следу= 077;т откорректиl= 8;овать и выполнить повторный анализ с уто= 095;ненными исходными д = 72;нными;<o:p></o:p> <![if !supportLis= ts]>- = <![endif]>ест= ь ли возможностn= 0; применить готовые пов = 90;орно используемm= 9;е компоненты ПС, в каком относительl= 5;ом размере от всего комплекса программ, и рентабельнl= 6; ли их применять в конкретном проекте ПС или весь проект целесообраk= 9;но разрабатывk= 2;ть как полностью н = 86;вый. <o:p></o:p> <o:p> </o= :p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p>= <o:p> </o:p> <o:p> </o:p= > <o:p> </o:p> <h1><a name=3D"_Toc508102467"></a><a name=3D"_Toc508102240">Лекция 6. Разработка требований = 82; программныl= 4; средствам</a><= /h1> <o:p> </o:p> <h1><a name=3D"_Toc508102468"></a><a name=3D"_Toc508102241">6.1. Организациn= 3; разработки требований = 82; сложным про = 75;раммным средствам</a><= /h1> <o:p> </o:p> Проекты программныm= 3; средств раз = 83;ичаются по уровню сл= 086;жности, масштабу и н= 077;обходимому качеству. Он= 080; имеют различное н = 72;значение, содержание = 80; относятся к разным областям применения. Поэтому сущ = 77;ствует потребностn= 0; в четко организоваl= 5;ном процессе, методах формализацl= 0;и и управлени= 03; требованияl= 4;и к конкретны = 84; программныl= 4; продуктам. Чаще всего проблемамl= 0;, с которыми встретилисn= 0; не достигши = 77; своих целей = 087;роекты программныm= 3; продуктов, я= 074;ляются: недостатоl= 2; информации от пользова = 90;еля или заказчи = 82;а о функциях проекта, неполные, некорректнm= 9;е требования, = 072; также многочислеl= 5;ные изменения требований = 80; спецификацl= 0;й. Это происходит потому, что з&#= 1072;частую разработчиl= 2;и и заказчики считают, что “даже если м= 099; не очень точно знаем, чего хотим д= 086;стичь, лучше быстрее приступить = 82; реализации проекта, так как мы и так выбились из графика и на= 084; некогда размышлять. = 052;ы можем уточнить требования позднее”. Подобный подход приводит к хаотическиl= 4;, неупорядочk= 7;нным действиям при разработке ПС, когда никто не знает, что на самом деле хочет заказчик и пользоватеl= 3;ь, и как в дейст&#= 1074;ительности функционирm= 1;ет созданная на данный момент сист = 77;ма и/или программнm= 9;й продукт.<o:p></o:p> Формали= ;зация и управлени = 77; требованияl= 4;и = - это систематичk= 7;ский метод выявления, организациl= 0; и документи = 88;ования требований = 82; системе и/ил= 080; ПС, а также процесс, в ходе которого вы = 88;абатываетс&#= 1103; и обеспечиваk= 7;тся соглашение между заказчиком = 80; выполняющиl= 4;и проект спец = 80;алистами, в условиях меняющихся требований = 82; системе -</span= > рис. 6.1. Развитие программноl= 1; инженерии, е= 105; обозримое будущее, связаны с непрерывныl= 4; возрастаниk= 7;м сложности, поэтому раз = 88;аботкой ПС должны заниматься хорошо орга = 85;изованные и обученные коллективы </sp= an>-</span= > командm= 9; разработчиl= 2;ов. Каждый член команды в то= 081; или иной сте= 087;ени должен привлекатьl= 9;я к управлени= 02; и формализа = 94;ии требований = 82; проекту. Ком= 072;нде необходимо выработать профессионk= 2;льные приемы для понимания п = 86;требностей пользоватеl= 3;ей, управления масштабом П = 57;, структурой = 80; построениеl= 4; системы, удовлетворn= 3;ющей эти потребн = 86;сти. <o:p></o:p> К= 086;манда должна применить методы и процессы дл= 03; того, чтобы п&#= 1086;нять решаемую проблему заказчика д = 86; начала разработки ПС. Дл= 03; этого следует ис = 87;ользовать метод анализа, выявления и освоения проблемы и интересов заказчика:<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>д = 86;стигнуть соглашения между заказчиком = 80; разработчиl= 2;ом по определениn= 2; проблемы, целей и зада= 095; проекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 99;делить основные причины = - проблемы, являющиеся её источник = 72;ми и стоn= 3;щие за основной проблемой проекта системы и ПС;<o= :p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 99;явить заинтересоk= 4;анных лиц и пользоватеl= 3;ей, чье коллект = 80;вное мнение и оценка в конечном итоге опред = 77;ляет успех или неудачу про = 77;кта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;ределить, где приблизитеl= 3;ьно находятся область и гр= 072;ницы возможных р = 77;шений проблем;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>п = 86;нять ограничениn= 3;, которые будут налож = 77;ны на проект, коман= ду и решения проблем.<o:p></o:p> &#= 1042; результате необходимо предложить заказчику возможные решения рассматривk= 2;емой проблемы. Дл= 103; анализа проблемы можно испол= 00;зовать разнообразl= 5;ые методы. В частности, моделироваl= 5;ие бизнес-проц = 77;ссов, специальныl= 1; метод анализа про = 73;лем, который достаточно = 93;орошо зарекомендl= 6;вал себя для сложных инф = 86;рмационных систем, осущ= 077;ствляющих поддержку ключевых инфраструкm= 0;ур. Выявленные на данном этапе преце = 76;енты, могут позднее применятьсn= 3; для определениn= 3; совокупносm= 0;и требований = 82; ПС. Методы сис = 90;емного анализа, позволяют о = 89;уществить разбиение сложной системы на п= 086;дсистемы. Этот процес = 89; помогает понять, каки= 084; общим целям должн= ;о служить ПС. При этом часто оказы = 74;ается, что в чем-то усложняютсn= 3; требования, создавая новые подсистемы, для которых = 074; свою очеред= 00; нужно заниматься разработкоl= 1; и понимание = 84; требований.<o:p= ></o:p> Понимание потребностk= 7;й пользоватеl= 3;ей необходимm= 9;й организациl= 6;нный этап, так как разработчиl= 2;и редко получают совершенныk= 7; спецификацl= 0;и требований = 82; создаваемоl= 1; системе, они должны сами добывать информацию, необходимуn= 2; им для успеш= 085;ой работы. Термин выявление требований точно отраж = 72;ет данный процесс, в котором разработчиl= 2;и должны играть активную роль. Чтобы помочь команде решить эти п= 088;облемы, лучше понят= 00; потребностl= 0; пользоватеl= 3;ей и других заинтересоk= 4;анных лиц, целесообраk= 9;но использоваm= 0;ь методы:<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>интервьюи = 88;ования и анкетироваl= 5;ия - создание структуриl= 8;ованного интервью; проведение интервью с 5 <= span style=3D'mso-bidi-font-size:14.0pt;font-family:Symbol;mso-ascii-font-family= :"Times New Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - 15 пользоватеl= 3;ями и/или заинте= 088;есованными лицами; подведение итогов совокупносm= 0;и интервью, формулировk= 2;ние 10 - 15 наиболее часто уп = 86;минавшихся</= span> потребностk= 7;й заказчика и пользоватеl= 3;ей; <o:p></o:p><= /p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>с = 86;вещания, посвященныk= 7; анализу и синтезу тре = 73;ований -</span= > формулироk= 4;ание и определениk= 7; целей программноk= 5;о продукта; ознакомленl= 0;е с ними всех участников проекта и установленl= 0;е, что они с ними соглас = 85;ы; если это не так, следует остановитьl= 9;я и уточнения = 84;и добиться со = 75;ласия; обязательl= 5;о убедиться в согласии заказчикоk= 4;;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>м = 86;зговой штурм и отбо= 088; идей, чтобы: выяв= 080;ть и/или уточни= 090;ь функции про = 77;кта; отсечь нецелесообl= 8;азные идеи; провести классификаm= 4;ию функций, чтобы определить приоритеты, = 088;иски, трудоемкосm= 0;и реализации фун-кц = 80;й;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>а = 85;ализ иллюстратиk= 4;ных прецедентоk= 4; в приложени = 80; к концепции требований (или системному проекту), что&#= 1073;ы их функции были наглядны и п= 086;нятны;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>п = 86; возможностl= 0; выявление или создани = 77; временных прототипов на основе первичных требований.<o:p= ></o:p> Хо= тя ни один из методов не является универсальl= 5;ым, каждый из ни= 093; позволяет лучше понят= 00; потребностl= 0; пользоватеl= 3;ей и тем самым превратить “неясные” требования, = 074; требования, которые “лучше известны и п= 086;нятны”. Каждый из этих методо = 74; эффективен = 74; определеннm= 9;х ситуациях, однако целесообраk= 9;но отдавать предпочтенl= 0;е совещанию, п= 086;священному требованияl= 4;, и мозговому штурму. <o:p></o:p> Для сложных систем требуются стратегии управления информациеl= 1; о требованияm= 3;. Для этого применяетсn= 3; информациоl= 5;ная иерархия; он= 072; начинается = 89; потребностk= 7;й пользоватеl= 3;ей, описанных с помощью фун = 82;ций, которые затем превращаютl= 9;я в более подр= 086;бные требования = 82; ПС, выраженные посредствоl= 4; прецедентоk= 4; или традиционнm= 9;х форм описан = 80;я и стандартизl= 0;рованных характерисm= 0;ик. Эта иерархи= 03; отражает уровень абс = 90;ракции при рассмотренl= 0;и взаимосвязl= 0; области проблемы и области реш = 77;ния. Концепцию требований, модифицироk= 4;анную в соответствl= 0;и с конкретны = 84; содержаниеl= 4; комплекса программ, необходимl= 6; иметь в каждом проекте. В требованияm= 3; к ПС следует указывать, какие функц = 80;и должны осуществляm= 0;ься, а не то, как они могут реализоватn= 0;ся. Они используютl= 9;я для задания функционалn= 0;ных и конструкт = 80;вных требований, = 072; также огран = 80;чений ресурсов проектировk= 2;ния. Нужно использоваm= 0;ь набор харак = 90;еристик для установленl= 0;я и оценки кач= 077;ства ПС и содержащихl= 9;я в нем компон= 077;нтов. Если необходимо, документацl= 0;я требований может дополнятьсn= 3; одним или несколькимl= 0; более формальнымl= 0;, либо более структурирl= 6;ванными методами спецификацl= 0;и требуемого качества. <o:p></o:p></span= > Без лидера -</span= > руководитеl= 3;я проекта, который будет утвер = 78;дать требования = 82; ПС, согласов= 099;вать и поддерживk= 2;ть потребностl= 0; заказчика и команды раз = 88;аботчиков, нельзя быть уверенным в том, что буду&#= 1090; приняты необходимыk= 7; четкие, скоординирl= 6;ванные решения. Возможно возникновеl= 5;ие флюктуаций требований, задержек, а также принятие не = 86;птимальных решений, вызванное приближениk= 7;м срока окончания проекта. Рук= 086;водитель должен создать совет по = 82;онтролю за изменениямl= 0;, который при = 79;ван помогать лидеру в принятии действителn= 0;но сложных решений и га= 088;антировать, что изменения и утверждениn= 3; требований будут приниматьсn= 3; только посл = 77; их обсужден = 80;я. <o:p></o:p> Концепция требований = 82; проекту (или системный проект) должна быть “живым” документоl= 4;, чтобы было легче его использоваm= 0;ь и пересматр = 80;вать. Следует сделать кон = 94;епцию официальныl= 4; каналом изменения функций так, чтобы проек = 90; всегда имел = 076;остоверный, соответствm= 1;ющий современноl= 4;у состоянию документ. Ли= 076;ер должен нест = 80; персональнm= 1;ю ответственl= 5;ость за концепци= 02;, регулярно (вместе с командой) оценивать состояние дел и готовить отчеты и зап= 088;осы, способствуn= 2;щие этим действиям. Процесс отслеживанl= 0;я спецификацl= 0;й требований = 82; ПС, должен помогать убедиться, что концепц = 80;я надлежащим образом реализуетсn= 3; в детализир = 86;ванных требованияm= 3; к компонентаl= 4; ПС. Руководс= 090;во процессом контроля за изменен = 80;ями, должно= гарантироk= 4;ать, что перед тем, как разрешить внесение существеннm= 9;х изменений в систему, производитl= 9;я оценка рентабельнl= 6;сти поступившиm= 3; предложениl= 1; (см. лекцию 16).<o:p></o:p>= <s= pan style=3D'mso-spacerun:yes'> Проек= ты, как правило, инициируютl= 9;я с объемом функционалn= 0;ных возможностk= 7;й, значительнl= 6; превышающиl= 4; тот, который разработчиl= 2; может реализоватn= 0;, обеспечив п = 88;иемлемое качество пр = 80; заданных ресурсах. Те= 084; не менее, необходимl= 6; ограничиваm= 0;ься, чтобы иметь возможностn= 0; предоставиm= 0;ь в срок доста= 090;очно целостный и качественнm= 9;й продукт. Сущ= 077;ствуют различные методы задания очередностl= 0; выполнения (приоритето = 74;) требований = 80; понятие базового ур = 86;вня - со = 74;местно согласованl= 5;ого представлеl= 5;ия о том, в чем будут состоять кл= 02;чевые функции системы как продукта проекта = - понятиk= 7; состава требований, задающих ориентир дл= 03; принятия решений и их оценки. <o:p></o:p> Если масштаб проекта и сопутствуюm= 7;ие требования заказчика п = 88;евышают реальные ресурсы, в любом случа = 77; придется ограничиваm= 0;ься в функциях и качестве ПС. Поэтому следует определять, что обязательнl= 6; должно быть сделано в версии прог = 88;аммного продукта пр = 80; имеющихся р = 77;сурсах проекта. Для этого придется в = 77;сти переговоры. Нельзя ожидать, что данный процесс полностью решит пробл = 77;мы масштаба и т= 088;ебований к ПС. Но такие шаги окажут заметное во = 79;действие на размеры проблемы, позволят ра = 79;работчикам ПС сконцент = 88;ировать свои усилия на критически важных подмножестk= 4;ах требований = 80; функций и, в несколько приемов, предоставl= 0;ть высококачеl= 9;твенные системы, удовлетворn= 3;ющие или даже превосходяm= 7;ие основные ожидания пользоватеl= 3;ей. Привлечениk= 7; заказчика к решению проблемы управления масштабом и функциями повышает вз = 72;имные обязательсm= 0;ва сторон, способствуk= 7;т росту взаим = 86;понимания и доверия между заказчиком = 80; разработчиl= 2;ами. Имея достаточноk= 7; определениk= 7; функций продукта (концепцию) и сократив масштаб проекта до р= 072;зумного уровня, можно надеяться н = 72; успех в следующих фазах или версиях про = 77;кта.<o:p></o:p> На основе выполненныm= 3; оценок трудозатраm= 0; рекомендуеm= 0;ся определять базовый уровень для каждой версии концепции требований, используя атрибут “номер верс = 80;и”, достигнуть соглашения = 89; заказчиком относительl= 5;о масштаба, а также принять жесткие реш = 77;ния по масштабу версии. Итеративнk= 2;я разработка = 80; управление изменениямl= 0;, используя б = 72;зовый уровень, позволяет контролироk= 4;ать, что все предложеннm= 9;е функции записаны и н= 080;чего не потеряно. Целесообраk= 9;на система упр = 72;вления запросами н = 72; изменения требований, чтобы фиксироватn= 0; все изменения и гарантировk= 2;ть, что они поступают через эту си= 089;тему в совет по контролю за изменен = 80;ями. На всех этапах развития спецификацl= 0;и требований = 82; ПС, следует задавать полный набо = 88; характерисm= 0;ик функционалn= 0;ного и конструкт = 80;вного поведения программноk= 5;о продукта и п= 086;дробные прецеденты для основны = 93; функций системы. <o:p></o:p> В требованияm= 3; должны быть полно и с = 78;ато зафиксировk= 2;ны потребностl= 0; пользоватеl= 3;ей в таком виде, чтобы разработчиl= 2; мог построи = 90;ь удовлетворn= 3;ющее их ПС и его ко&= #1084;поненты. Кроме того, требования должны быть достаточно конкретнымl= 0;, чтобы можно было опреде = 83;ить, когда они удовлетворk= 7;ны. Зачастую именно разработчиl= 2;и обеспечиваn= 2;т эту конкретизаm= 4;ию. Существуют различные в = 86;зможности организациl= 0; и документи = 88;ования этих требований. Вся разрабо = 90;ка должна вытекать из требований, а все спецификацl= 0;и ПС и компоне= 085;тов должны найт = 80; отражение в процессах и продуктах разработки. = 057;ложный программныl= 1; комплекс следует пересматриk= 4;ать и обновлять на протяжении всего жизне = 85;ного цикла проек = 90;а. <o:p></o:p> Проектироk= 4;ание и реализаци= 03; корректной (правильной) системы, адекватной требованияl= 4; = - весьма трудоемкая задача. Один из полезных методов сос = 90;оит в использоваl= 5;ии прототипов требований = 80; прецедентоk= 4; в качестве основы архитектурm= 9; и реализаци = 80; проекта. Постоянно отслеживатn= 0; эволюцию функций и требований, = 072; также их реализацию позволяет верификациn= 3; (см. лекцию 13). Её поддержка о = 89;уществляет&#= 1089;я путем испол= 00;зования методов трассировкl= 0;, что позволя = 77;т связывать друг с друго= 084; части проек = 90;а, проводить трассировкm= 1; требований = 82; прецедентаl= 4; и функциям и обратно. С помощью трассировкl= 0; можно удост = 86;вериться в том, что:<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>в = 89;е элементы требований проекта учтены;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 89;е реализованl= 5;ые элементы проекта слу = 78;ат заданной цели и требо= 074;аниям.<o:p></o:p> Хотя верификациn= 3; является аналитичесl= 2;им методом, рекомендуеm= 0;ся помнить о важности размышлениl= 1; и интуиции. Нельзя ограничиваm= 0;ься механическl= 0;м применениеl= 4; верификациl= 0;. Основное внимание пр = 80; её проведен = 80;и уделяется тестированl= 0;ю и использов = 72;нию трассировкl= 0; для отбора компонентоk= 4; системы, нуж= 076;ающихся в тестированl= 0;и. Методы проверки корректносm= 0;и требований = 87;ризваны гарантировk= 2;ть, что:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 89;е элементы требований могут надлежащим образом и достаточно полно тести = 88;оваться;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>в = 89;е тесты служа = 90; цели проект = 72; и не являютс= 103; избыточнымl= 0;.<o:p></o:p> <s= pan style=3D'mso-spacerun:yes'> Чтобы принять решение о том, какая часть системы нуж = 76;ается в верификациl= 0; и проверке корректносm= 0;и и в каком объ&#= 1077;ме, целесообраk= 9;но применять анализ и оце= 085;ку рисков. Это позволяет определить, для каких элементов неправильнk= 2;я реализация требований недопустимk= 2;, а также разр= 072;ботать план действий по верификациl= 0; и проверке правильносm= 0;и, основываясn= 0; на результатаm= 3; этих оценок. На этом этап= 077; следует привлекать = 82; управлениn= 2; требованияl= 4;и и анализу их корректносm= 0;и, специалистl= 6;в по тестиров = 72;нию, подключая и = 93; к планированl= 0;ю тестов с самого начала прое = 82;та (см. лекцию 13) . Группа тестированl= 0;я должна разр = 72;ботать тестовые процедуры и сценарии, которые трассируютl= 9;я к прецедент = 72;м, а также функционалn= 0;ным и конструкт = 80;вным требованияl= 4;. <o:p></o:p> <s= pan style=3D'mso-spacerun:yes'> Построениk= 7; корректных требований = 82; системе во многом зави = 89;ит от надлежащей обработки изменений. И= 079;менения - неотъемлемk= 2;я часть жизни ПС, это нужно учитывать при создани = 80; планов, а также необх = 86;димо разработатn= 0; процесс, с помощью которого можно управлять изменениямl= 0; требований. Управление изменениямl= 0; дает уверен = 85;ость в том, что создаваемаn= 3; система является корректной = 80;, более того, будет правильной = 80; в дальнейше = 84;. Специалистk= 2;м по независи = 84;ой гарантии качества, должна отво = 76;иться роль в отслеживанl= 0;и и оценке про= 094;есса управления требованияl= 4;и и плана их тестироваl= 5;ия, а также пери= 086;дических испытаний п = 86; окончании значительнm= 9;х этапов, чтоб= 099; проверить правильносm= 0;ь результатоk= 4; работы и обеспечить постоянное участие зак = 72;зчиков.<o:p></o:p> = <o:p></o:p> <h1> <a name=3D"_Toc508102469"></a><a name=3D"_Toc508102242">6.2.&= nbsp; Процессы разработки требований = 82; характерисm= 0;икам сложн= ;ых программныm= 3; средств</a></h1> = <o:p></o:p> <sp= an style=3D'mso-bidi-font-size:14.0pt'> При планированl= 0;и, разработке = 80; реализации требований = 82; характерисm= 0;икам качества ПС необходимо, = 074; первую очередь, учи= 090;ывать следующие основные фа = 82;торы:<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1092;ункциональ= ную пригодностn= 0; (функционал= 00;ность) конкретногl= 6; проекта ПС;<o:p></o:p= > <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1074;озможные конструктиk= 4;ные характерисm= 0;ики качества комплекса программ, не= 086;бходимые для улучшения функционалn= 0;ной пригодностl= 0;;<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1076;оступные ресурсы для создания и обеспечениn= 3; всего жизне = 85;ного цикла ПС с требуемым качеством.<o:p></o:p>= Эти фактор = 99; целесообраk= 9;но применять последоватk= 7;льно, итерационнl= 6; на каждом из основных этапов ЖЦ ПС. При первона = 95;альном определениl= 0; требований = 82; функционалn= 0;ной пригодностl= 0; и к конструктиk= 4;ным характерисm= 0;икам качества, заданные заказчиком ограничениn= 3; ресурсов не всегда могу = 90; учитывать ряд особенностk= 7;й проекта, что обусловит недопустимl= 6;е снижение (ил= 080; завышение) требований = 82; некоторым характерисm= 0;икам качества ПС. Кроме того, возможно, чт= 086; некоторые характерисm= 0;ики проти= ;воречивы или принципиалn= 0;но нереализуеl= 4;ы в данном проекте. В ре&#= 1079;ультате не сбалансироk= 4;анные требования = 82; качеству и доступные р = 77;сурсы проявятся как риски – ущерб в виде потерь в кач= 077;стве или в пер= 077;расходован&= #1080;и ресурсов. Дл= 103; устранения или снижени= 03; рисков до допустимых пределов потребуетсn= 3; изменение требований = 82; функционалn= 0;ной пригодностl= 0; и/или к конструктиk= 4;ным характерисm= 0;икам. Таким образом, целесообраk= 9;но анализ и разработку требований = 82; качеству ПС = 087;роводить в два этапа: предваритеl= 3;ьно максимиk= 9;ируя функционалn= 0;ную пригодностn= 0; и конструкт = 80;вные характерисm= 0;ики качества, а затем ми = 85;имизируя риски снижения требуемого качества ил = 80; используемm= 9;х ресурсов. <o:p></o:p></span= > <= span style=3D'mso-spacerun:yes'> </span= >Разработку и утверждениk= 7; требований = 82; характерисm= 0;икам и атрибутам качества бе = 79; учета риско = 74;, целесообраk= 9;но проводить и = 90;ерационно на этапах си= 089;темного и детальног = 86; проектировk= 2;ния ПС. Полная и од= 085;ократная формализацl= 0;я требований = 82; характерисm= 0;икам качества в начале жизненного цикла сложного ПС обычно невозможна, прежде всег = 86;, из-за разных представлеl= 5;ий заказчика и разработчиl= 2;ов о детk= 2;лях его назначе = 85;ия, функций и возможностk= 7;й реализации при доступных ресурсах. Че= 084; крупнее и сложней проект ПС и соответствk= 7;нно выше его стоимость, тем тщательнее следует разрабатывk= 2;ть требования = 82; его характе = 88;истикам качества и распределяm= 0;ь ресурсы на и= 093; реализацию (см. лекцию 12). Поэто= ;му при средней = 080; относительl= 5;о невысокой с = 83;ожности ПС, во многих случаях, мож= 085;о удовлетворl= 0;ться подготовкоl= 1; требований = 82; качеству с п= 086;дробностью анализа, соответствm= 1;ющей системному проектировk= 2;нию. Для крупном = 72;сштабных и особо сложных про = 77;ктов необходим более детал= 00;ный анализ факторов пр = 80; разработке требований = 80; их оптимиза = 94;ия по критерию = 082;ачество/зат= раты. Поэтому на этапах прое = 82;тирования последоватk= 7;льно должны определятьl= 9;я требо= вания: <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>при проектировk= 2;нии концепции = - предваритеl= 3;ьные требования = 82; назначению, функционалn= 0;ной пригодностl= 0; и к номенклатуl= 8;е необходимыm= 3; конструктиk= 4;ных характерисm= 0;ик качества ПС; </= span><o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;и предваритеl= 3;ьном проектировk= 2;нии - требования = 82; шкалам и мерам приме = 85;яемых атрибутов характерисm= 0;ик качества с учетом общи = 93; ограничениl= 1; ресурсов;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>п = 88;и детальном проектировk= 2;нии - подробные требования = 82; атрибутам качества с детальным учетом и распределеl= 5;ием реальных ограниченнm= 9;х ресур= ;сов, а также, возможно, их<sp= an style=3D'mso-spacerun:yes'> оптимизацl= 0;я по критерию качество/за = 90;раты. <o:p></o:p> В зависимостl= 0; от сложност = 80; проекта окончательl= 5;ым результатоl= 4; работ при предваритеl= 3;ьном или детальн = 86;м проектировk= 2;нии должны быть детализироk= 4;анные и утвержденнm= 9;е требования = 82; функциям, св= 086;йствам и значениям атрибутов качества ПС, которые в обоих случаях дос = 90;аточны для его полноценноk= 5;о рабочего проектировk= 2;ния и последующ = 77;й, эффективноl= 1; эксплуатацl= 0;и (без учета рисков). В реальных пр = 86;ектах при подгото = 74;ке требований = 82; качеству ПС могут исклю = 95;аться этапы проек = 90;ирования, однако соде = 88;жание и последоватk= 7;льность работ по ана= 083;изу и детализац = 80;и требований = 82; характерисm= 0;икам и атрибутам качества целесообраk= 9;но сохранять. Эти требова = 85;ия закрепляютl= 9;я в контракте = 080; техническоl= 4; задании, по которым раз = 88;аботчик впоследствl= 0;и должен отчи = 90;ываться перед заказчиком при завершении проекта или его версии. Однако на последующиm= 3; этапах жизненного цикла и при конфигурацl= 0;онном управлении, требования могут измен= 03;ться по согласов = 72;нию между заказчиком = 80; разработчиl= 2;ом, которые чащ = 77; всего приур = 86;чиваются к подготовк = 77; новой версии= программнl= 6;го продукта. Дл= 103; этого необходим м = 86;ниторинг требований = 80; реализаций характерисm= 0;ик качества в течение всего ЖЦ ПС.<o:p></o:= p> Выбор требований = 82; харак= теристикам и атрибутам качества пр = 80; проектировk= 2;нии программныm= 3; средств начинается = 89; определениn= 3; исходных да = 85;ных. Для корректногl= 6; выбора и установленl= 0;я требований = 82; характерисm= 0;икам качества, прежде всег = 86;, необходимо = 86;пределить особенносm= 0;и проекта:<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1082;ласс, назначение = 80; основные функции l= 9;оздаваемог= 086; ПС;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1082;омплект стандартов = 80; их содержание, которые целесообраk= 9;но использоваm= 0;ь при выборе характерисm= 0;ик качества ПС;<o:= p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1089;остав потребителk= 7;й характерисm= 0;ик качества ПС, для которых важны соотв = 77;тствующие атрибуты качества;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>&#= 1088;еальные ограничениn= 3; всех видов ресурсов проекта. <o:p></o:p> = Этап разработки концепции проекта целесообраk= 9;но начинать с формализацl= 0;и и обоснованиn= 3; набора исхо = 76;ных данных, отражающих общие особе = 85;ности класса, потр= 077;бителей и этапов жизненного цикла проек = 90;а ПС, каждый из которых влияет на выбор опред = 77;ленных характерисm= 0;ик качества комплекса п = 88;ограмм. Из конструктиk= 4;ных характерисm= 0;ик и атрибутов качества, прежде всег = 86;, следует выд = 77;лять, те на которые в наибольшей степени воздействуk= 7;т класс, назна= 095;ение и функции ПС. Для этого первоначалn= 0;но целесообраk= 9;но использоваm= 0;ь классификаm= 4;ию программныm= 3; средств по стандарту ISO<= span style=3D'font-size:14.0pt'> 12182 и всю базовую ном = 77;нклатуру характерисm= 0;ик и субхар = 72;ктеристик качества, стандартизl= 0;рованных в ISO 9126 (см. лекцию 11). Их описания желат= ;ельно предваритеl= 3;ьно упорядочитn= 0; по приорите = 90;ам с учетом особенностk= 7;й назначения = 80; сферы применения конкретногl= 6; ПС. Обычно наиболее сильное влияние функции ПС о= 082;азывают на требования = 82; атрибутам характерисm= 0;ик: Защищенносm= 0;ь, Надежность = 80; Эффективноl= 9;ть. В то же время, характерисm= 0;ики Сопровоk= 8;даемость и Мобильнос = 90;ь относительl= 5;о слабо связаны с на= 079;начением и конкретно = 81; функционалn= 0;ной пригодностn= 0;ю ПС для оперативныm= 3; пользоватеl= 3;ей. Их меры и шкалы определяютl= 9;я не столько конкретнымl= 0; функциями комплекса п = 88;ограмм, сколько его архитектурl= 6;й и приспособлk= 7;нностью интерфейсоk= 4; к модификациl= 0; и переносу н= 072; иные операц = 80;онные и аппаратны = 77; платформы. <o:p></o:p= > Требованиn= 3; стандартов = 82; функционалn= 0;ной пригодностl= 0; должны выполнятьсn= 3; для любых классов и назначения ПС. Однако номенклатуl= 8;а учитываемыm= 3; требований = 82; конструктиk= 4;ным характерисm= 0;икам качества существеннl= 6; зависят от назначения = 80; функций ком = 87;лексов программ. Так, наприме= 088;, при проектировk= 2;нии:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 80;стем управлениn= 3; объектами в реальном времени наибольшее значение имеет защищ = 77;нность, корректносm= 0;ь и надежност= 00; функционирl= 6;вания стабильногl= 6; комплекса программ и менее важно может быть качест = 74;о обеспечениn= 3; сопровождеl= 5;ия и конфигура = 94;ионного управления, спосо= ;бность к взаимодей = 89;твию и практично = 89;ть;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>администр= 072;тивных систем кром = 77; корректносm= 0;и, важно обесп = 77;чивать практичносm= 0;ь применения, комфортное взаимодейсm= 0;вие с пользоват = 77;лями и внешней средой и мож= 077;т не иметь особого значение эффективноl= 9;ть использоваl= 5;ия вычислителn= 0;ных ресурсов и обеспечениk= 7; мобильностl= 0; комплекса программ;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 87;ерационных систем наиболее жесткие требования предъявляюm= 0;ся к корректно = 89;ти, эффективноl= 9;ти использоваl= 5;ия вычислителn= 0;ных ресурсов и защищенносm= 0;и, и не всегда могут учитыватьсn= 3; мобильностn= 0; и унификаци= 03; способностl= 0; к взаимодейсm= 0;вию её компонен = 90;ов;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 72;кетов прикладных программ дл= 03; вычислений или моделир = 86;вания процессов, во= зможно не учитыват= 00; их мобильностn= 0;, защищенносm= 0;ь и временную эффективноl= 9;ть, но особенно важна корре = 82;тность.<o:p></o:p> = Далее необходимо выделить и ранжироватn= 0; по приоритетаl= 4; потребителk= 7;й, которым необходимы = 86;пределенны&#= 1077; показатели качества ПС = 089; учетом их специализаm= 4;ии и профессионk= 2;льных интересов. Ши= рокая номенклатуl= 8;а характерисm= 0;ик, представлеl= 5;ная в стандарте <sp= an lang=3DEN-US style=3D'mso-ansi-language:EN-US'>ISO 9126 определяет</spa= n> разнообразl= 5;ые требования, из которых следует = 89;електирова&#= 1090;ь и выбирать те, которые необходимы = 89; позиции потребителk= 7;й этих данных: <o= :p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>з = 72;казчиков, для которых важно регламентиl= 8;овать и оценивать = 055;C по значениям требований = 82; характерисm= 0;икам, заданным и утвержденнm= 9;м в контракте, техническоl= 4; задании и спецификацl= 0;ях требований = 80; определяющl= 0;х, прежде всег = 86;, назначение, функции и сферу приме = 85;ения программноk= 5;о продукта;<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>п = 86;льзователе&#= 1081;, для которых необходима функционалn= 0;ная пригодностn= 0;, корректносm= 0;ь, надежность и другие пока = 79;атели качества пр = 80; оперативноl= 4; использоваl= 5;ии комплекса программ по основному назначению;<o:p= ></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>р = 72;зработчико&#= 1074;, для которых особенно важны: ясность и ко= 085;кретность описаний требований = 82; функциям и характерисm= 0;икам ПС, его возможная архитектурk= 2; и интерфейс = 99; между компонентаl= 4;и и с внешней средой;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>с = 87;ециалистов сопровождаn= 2;щих и модифицир = 91;ющих ПС, которые отдают прио = 88;итет характерисm= 0;икам, поддерживаn= 2;щим сопровождеl= 5;ие и конфигура = 94;ионное управление версиями комплекса программ и его компоне = 85;тов;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>л = 80;цам, ответственl= 5;ым за инсталляциn= 2; и реализаци= 02; программноk= 5;о продукта в различных аппаратных = 80; операционнm= 9;х средах, для которых наиболее важны характерисm= 0;ики мобил= ;ьности.<o:p></o:p> = В таблице 6.1 представлеl= 5; пример ранжированl= 0;я по степени важности на = 090;ри уровня= (высокая, средняя, низкая) осно= 074;ных стандартизl= 0;рованных характерисm= 0;ик качества ПС для разных к= 072;тегорий специалистl= 6;в. Первые две группы потребителk= 7;й характерисm= 0;ик качества, заинтересоk= 4;аны, преимущестk= 4;енно, в реализаци = 80; функций, проявляющиm= 3;ся в процессе использоваl= 5;ия конечного, готового пр = 86;граммного продукта. Дл= 103; этих потреб = 80;телей при выборе важно выдел= 03;ть и по возможностl= 0; формализовk= 2;ть внешние, эксплуатаm= 4;ионные характерисm= 0;ики на завершающиm= 3; этапах ЖЦ версий ПС. К ним относятся, прежде всег = 86;, высокие приоритеты для надежности, эффективноl= 9;ти и практично = 89;ти. Для заказчи = 82;ов приоритетнm= 9;ми могут быть также со = 87;ровождаемо&#= 1089;ть и мобильнос = 90;ь, которые для оперативныm= 3; пользоватеl= 3;ей ПС обычно являются второстепеl= 5;ными.<o:p></o:p> Последние три группы потребителk= 7;й интересуют преимущестk= 4;енно характерисm= 0;ики ПС на промежуточl= 5;ых этапах ЖЦ, на которых про= 03;вляются, в основном, в&#= 1085;утренние структурныk= 7;, технологичk= 7;ские свойства комплекса программ, влияющие также на = 089;опровождае&= #1084;ость и мобильнос = 90;ь. Их можно не представляm= 0;ь в составе эксплуатацl= 0;онной документацl= 0;и для оперативныm= 3; пользоватеl= 3;ей и отражать только в технологичk= 7;ской документацl= 0;и разработчиl= 2;ов, специалистl= 6;в по сопровождеl= 5;ию и переносу программ и данных, а также поставлять заказчикам = 87;о специальноl= 4;у запросу. Они должны формализовk= 2;ться для обеспеч = 77;ния возможностl= 0; контроля системой качества предприятиn= 3; или проекта, а также для т&#= 1077;хнологичес= кой поддержки реализации этих характ = 77;ристик качества в течение всего ЖЦ ПС. Для этих потребителk= 7;й надежность = 80; практичносm= 0;ь отходят на второй план, однако, ресурсная эффективноl= 9;ть может остав = 72;ться высоко прио = 88;итетной.<o:p></o:p> Приоритетm= 9; потребителk= 7;й при выборе требований = 82; качеству от = 88;ажаются не только на выделении важнейших для них критериев и ранжированl= 0;и приоритетоk= 4; других характерисm= 0;ик, но также на возможностl= 0; исключении из анализа некоторых характерисm= 0;ик качества, которые для данного потребителn= 3; не имеют значения. Представлеl= 5;ное в таблице 6.1 ра= ;нжирование может детализироk= 4;аться и изменятьс= 03; в зависимостl= 0; от функций П= 057; и реальных ресурсов, доступных для обеспеч = 77;ния их жизненного цикла. Эти приоритеты должны обобщаться = 80; учитыватьсn= 3; заказчиком = 87;роекта при подготовке контракта и техническоk= 5;о задания. После опред = 77;ления назначения = 80; функций ПС подготовка = 80;сходных данных и концепции проекта должны завершатьсn= 3; выделением номенклатуl= 8;ы приоритетнm= 9;х конструктиk= 4;ных атрибутов характерисm= 0;ик качества, имеющих доста= ;точное влияние на функционалn= 0;ную пригодностn= 0; ПС для определеннm= 9;х потребителk= 7;й.<o:p></o:p> = На этапе предваритеl= 3;ьного проектировk= 2;ния, после фиксированl= 0;я исходных данных и приоритетоk= 4; характерисm= 0;ик для конкретногl= 6; проекта и ег= 086; потребителk= 7;й, может начинаться выбор требо = 74;аний к свойствам и значениям, а также установленl= 0;е и утвержден = 80;е конкретных мер и шкал характерисm= 0;ик и атрибутов качества. Такой анали = 79; должны пров = 86;дить заказчик и некоторые потенциальl= 5;ые пользоватеl= 3;и совместно с = 86; специалистk= 2;ми, обеспечиваn= 2;щими ЖЦ комплекс = 72; программ и реализацию установленl= 5;ых требований = 82; показателяl= 4; качества. Этими специалистk= 2;ми, для каждого из выбранны = 93; атрибутов, должна быть установленk= 2; и согl= 3;асована мера и шкала оценок характерисm= 0;ик и их атрибут= 086;в для конкрет = 85;ого проекта и потребителn= 3; результатоk= 4; анализа. Там где кроме оц= 077;нивания наличия номинальныm= 3; свойств, возможны количествеl= 5;ные измерения, при оценке р= 077;ализации требований = 82; качеству может быть п= 086;лезен выбор и уста= 085;овление допусков на = 086;тклонения от величин требуемых спецификацl= 0;ями. Для показателеl= 1;, представляk= 7;мых качественнm= 9;ми свойствами = 80; признаками их наличия, желательно определить = 80; зафиксировk= 2;ть в специфика = 94;иях описания допустимых условий, при которых следует считать, что данная хара = 82;теристика может или до= 083;жна быть реализ = 86;вана в проекте ПС. <= o:p></o:p> = Принципиаl= 3;ьные и техническ = 80;е возможностl= 0;, точность реализации свойств и измерения значений характериl= 9;тик качества, а также общие ресурсы конкретноk= 5;о проекта, все= 075;да ограничены = 74; соответствl= 0;и с их содержаниеl= 4; и возможностn= 3;ми заказчика и разработчиl= 2;ов. Это определяет рациональнm= 9;е диапазоны значений каждого атрибута, которые мог = 91;т быть выбран = 99; для проекта ПС на основе требований заказчика, здравого смысла, а также путем анализа пилотных проектов и прецедентоk= 4; в специфика = 94;иях требований реализованl= 5;ых проектов. В пределах этих диапаз = 86;нов целесообраk= 9;но определениk= 7; реальной достовернl= 6;сти оценивания = 80; масштаба ме = 88; для описани= 03; соответствm= 1;ющего атрибута тр = 77;бований. <o:p></o:p> Требованиn= 3; к значениям характерисm= 0;ик качества должны быть предваритеl= 3;ьно проверены разработчиl= 2;ами на их реализуемоl= 9;ть с учетом доступных ресурсов конкретногl= 6; проекта и пр= 080; необходимоl= 9;ти откорректиl= 8;ованы по составу и значениям с учетом риск = 86;в. При ограниченнl= 6;сти ресурсов проекта ПС р= 072;спределени&= #1077; приоритетоk= 4; должно становитьсn= 3; более строгим и могут снижаться приоритеты = 93;арактерист&#= 1080;к, для реализации которых рес = 91;рсов недостаточl= 5;о. В результат = 77; формируетсn= 3; полный набо = 88; требуемых характерисm= 0;ик, свойств и атрибутов, и= 093; мер и значений ка = 95;ества для определеннm= 9;х потребителk= 7;й в ЖЦ ПС. <o:p></o:p> Входные проектные данные и требования = 82; ПС, включая установленl= 5;ые законодатеl= 3;ьные и регламентиl= 8;ующие нормативныk= 7; требования, должны быть, оформлены документалn= 0;но, а их выбор проанализиl= 8;ован поставщикоl= 4; на адекватносm= 0;ь. Неполные, дв= 091;смысленные или противоречl= 0;вые требования должны быть предметом урегулировk= 2;ния с лицами, ответственl= 5;ыми за их предъявленl= 0;е. Спецификацl= 0;ю требований должен пред = 89;тавить потребителn= 0;-заказчик. Однако по взаимному согласию её может подготовитn= 0; поставщик-р = 72;зработчик, в тесном сотрудничеl= 9;тве с потребите = 83;ем для предупреждk= 7;ний разногласиl= 1; путем, например, уточнения определениl= 1; терминов, объяснения предпосылоl= 2; и обоснован = 80;я требований. Исходные требования могут быть п= 088;едставлены и согласованm= 9; в виде специ= 092;икации всей систем = 99;. Если программныl= 1; продукт нуждается в = 86; взаимодейсm= 0;вии с другими программныl= 4;и или аппарат = 85;ыми продуктами, то в специфи= 082;ации требований должны быть оговорены непосредстk= 4;енно или при помощи ссылок интерфейсы = 84;ежду разрабатывk= 2;емыми и другими применяемыl= 4;и продуктами. = 042; этом случае должны быть = 088;азработаны процедуры, обеспечиваn= 2;щие четкое распределеl= 5;ие системных требований между аппаратнымl= 0; и программныl= 4;и компонентаl= 4;и, а также соответствm= 1;ющие спецификацl= 0;и интерфейсоk= 4; с внешней средой. При заключении контракта спецификацl= 0;я требований может быть определена не полность= 02;, она может быть доработана = 74; ходе реализ = 72;ции проекта. <o:p></o:p> Выходны= ;е проектные данные должны быть документалn= 0;но оформлены и выражены в требованияm= 3; так, чтобы их &= #1084;ожно было проверять в ЖЦ ПС и подтв&#= 1077;рдить соответствl= 0;е входным проектным т = 88;ебованиям. Выходные проектные данные долж = 85;ы содержать к = 88;итерии приемки про = 77;кта заказчиком или ссылки н= 072; них, а также идентифициl= 8;овать те характер = 80;стики проекта, которые являются критическиl= 4;и для безопасногl= 6; и надежного функционирl= 6;вания ПС. К составу выходных проектных данных могу = 90; относиться:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 87;ецификация структурноk= 5;о проектировk= 2;ния;<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1086;писание результатоk= 4; и спецификацl= 0;и рабочего проектировk= 2;ния компонентоk= 4;;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 89;ходные тексты программ и программы в объектном коде;<o:p></o:p> <![if !supportLists]><= span style=3D'mso-bidi-font-size:14.0pt'>- = <![endif]>&#= 1082;омплект эксплуатацl= 0;онной документацl= 0;и и руковоk= 6;ств для пользо = 74;ателей;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;мплект технологичk= 7;ской документацl= 0;и для обеспечениn= 3; возможностl= 0; модификациl= 0; и сопровождеl= 5;ия ПС. <o:p></o:p> Результатm= 9; системного анализа и выбора номенклатуl= 8;ы и мер характерисm= 0;ик проектов ПС средней или относительl= 5;о невысокой сложности должны быть документирl= 6;ваны в спецификацl= 0;ях требований, согласованm= 9; с их потребителn= 3;ми и утвержден = 99; заказчиком проекта для последующеl= 1; реализации. Для разрабо = 90;чиков особенно важно форма = 83;изовать требования = 82; качеству и согласоватn= 0; их с заказчиком при утвержд = 77;нии контракта и техническоk= 5;о задания на проект ПС. Требования = 82; характерисm= 0;икам, утвержденнm= 9;е после предваритеl= 3;ьного проектировk= 2;ния, могут быть закреплены = 74; техническоl= 4; задании как обязательнm= 9;е для детального = 80; рабочего проектировk= 2;ния. Эти данные могут испол= 00;зоваться при последу= 02;щем оценивании = 82;ачества и его сопоставлеl= 5;ии с требованияl= 4;и в процессе квалификацl= 0;онных испытаний или сертифи = 82;ации ПС. Однако для крупных = 080; дорогих проектов может потребоватn= 0;ся уточнение т = 88;ебований к качеству при дk= 7;тальном проектировk= 2;нии с позиции улучшения соотношениn= 3; значений качества и затрат ресурсов, ко= 090;орые необходимы или допустимы для их реали= 079;ации в ЖЦ ПС.&nbs= p; <o:p></o:p> При детальном проектировk= 2;нии может быть целесообраk= 9;но дополнителn= 0;ное уточнение совокупносm= 0;и требований выбранных характериl= 9;тик и атрибутов качества сложных ПС с учетом соотношениn= 3; качес= ;тва и затрат ресурсов, которые могут быть весьма велики. Для заказчика и пользоватеl= 3;ей может иметь значение не только опре = 76;еление функц= ;иональной пригодностl= 0;, но и потенциальl= 5;ого спроса на рынке конкретногl= 6; программноk= 5;о продукта, а также его конкурентоl= 9;пособности с другими аналогичныl= 4;и по функциям ПС с учетом его качеств = 72; и стоимости. Это обстоят = 77;льство может определять необходимоl= 9;ть уточнения требований = 82; отдельным характерисm= 0;икам качества не только для и= 093; реализации разработчиl= 2;ами в ЖЦ ПС, но также для оценивания интегральнl= 6;го качества го = 90;ового программноk= 5;о продукта поставляемl= 6;го на рынок. <o:p></o:p> Каждая характерисm= 0;ика качества и затраты ресурсов первоначалn= 0;но анализируюm= 0;ся независимо, что может использоваm= 0;ься в качестве исходных данных для и= 093; сопоставлеl= 5;ия с отдельным = 80; характерисm= 0;иками аналогичныm= 3; ПС, или для представлеl= 5;ия, как составл= 03;ющей вектора в многомерноl= 4; пространстk= 4;е стандартизl= 0;рованных атрибутов характерисm= 0;ик качества. Обычно заказчики и разработчиl= 2;и первоначалn= 0;но устанавливk= 2;ют требования = 82; каждой характерисm= 0;ике без учета от= 085;осительных затрат на их достижение, = 072; также без детального анализа их совместногl= 6; влияния на полную функ = 94;иональную пригодностn= 0; у потребителk= 7;й. Это может приводить к значительнm= 9;м перекосам и несбалансиl= 8;ованным значениям требований = 82; отдельным, взаимосвязk= 2;нным характерисm= 0;икам качества, на которые не р= 072;ционально используютl= 9;я ограниченнm= 9;е ресурсы ЖЦ ПС, или к не ад= екватно низким их значениям. В проектах крупных ПС это может угрожать зн = 72;чительным повышением стоимости и/или снижением конкурентоl= 9;пособности создаваемоk= 5;о программноk= 5;о продукта из-за недост= 072;точного уровня отдельных п = 86;казателей качества.<o:p></o:p>= Атрибуты к = 72;чества ПС имеют различные меры и шкалы, вследствие чего они в большинствk= 7; своем непос = 88;едственно не сопоставимm= 9; между собой. Они предвар = 80;тельно выбираются = 80; согласовывk= 2;ются с заказчико = 84; при последоватk= 7;льном, почти незав = 80;симом анализе каждого атрибута качества в соответствl= 0;и с их мерами и шкалами, для последующеk= 5;о использоваl= 5;ия в контракте = 080; техническоl= 4; задании. Для обобщенногl= 6; оцени= ;вания качества ПС необходим учет относи = 90;ельного влияния каждого атр = 80;бута на функционалn= 0;ную пригодностn= 0;. При этом не всегда учит = 99;ваются ресурсы для их реализации в конкретноl= 4; ПС. Это часто приводит к в= 099;движению ряда не рациональнm= 9;х требований, которые значительнl= 6; отличаются: либо по степени влияния на функционалn= 0;ную пригодностn= 0;, либо по величине ре = 89;урсов, необходимыm= 3; для их реали= 079;ации. Для целенаправl= 3;енного эффективноk= 5;о управления качеством сложного ПС при проекти = 88;овании целесообраk= 9;но иметь механизм объединениn= 3; разнородныm= 3; характерисm= 0;ик в некоторый интегральнm= 9;й показатель, отражающий их совокупн = 86;е влияние на его функцио = 85;альную пригодностn= 0;. Таким образом, при разработке требований = 82; характерисm= 0;икам качества выявилась п = 88;облема анализа систе= ;мной эффективнl= 6;сти прогр= ;аммного средства и обобщения его характе = 88;истик, а также оцениваниn= 3; совместногl= 6; влияния различных характерисm= 0;ик и атрибутов качества на функционалn= 0;ную пригодностn= 0; ПС с учетом затрат на их реализацию (см. лекцию 12). <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102470"></a><a name=3D"_Toc508102243">6.3. Структур= ;а основных документов, отражающих требования = 82; программны&= #1084; средствам</a><= span style=3D'mso-spacerun:yes'> </h1> <o:p= ></o:p> При разработке требований = 82; проектам программныm= 3; средств, кроме основных целей, назначения = 80; функций важно учест= 00; и сформулир = 86;вать содержание достаточно полного множества характерисm= 0;ик, каждая из которых может влият= 00; на успех проекта про = 75;раммного продукта. Дл= 103; уменьшения вероятностl= 0; случайного пропуска ва = 78;ного требования заказчикам = 80; пользоватеl= 3;ям целесообраk= 9;но иметь типовые проекты перечней (шаблоны) наборов требованиl= 1;, которые мож = 85;о целеустремl= 3;енно сокращать и адаптироваm= 0;ь, обеспечиваn= 3; целостностn= 0; требований для конкрет = 85;ых проектов ПС. Ниже представлеl= 5;ы примеры состава требований на двух этап= 072;х жизненного цикла сложных ПС: на этапе фор= 084;ирования концепции П = 57; и на этапе детального проектировk= 2;ния комплекса программ. <o:p></o:p></span= > <o:p></o:p> Соста= в концепции основных требо= ;ваний к программноl= 4;у средству:<o:p></o:p>= <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1086;писание обобщенных результатоk= 4; обследованl= 0;я и изучения существующk= 7;й системы и внешней среды;<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1086;писание целей, назначения программноk= 5;о продукта и потребностk= 7;й заказчика и потенциальl= 5;ых пользоватеl= 3;ей к нему в зада&#= 1085;ной среде приме = 85;ения;<o:p></o:p> <![if !supportLi= sts]>- = &nb= sp; <![endif]>&#= 1087;еречень базовых стандартов предполагаk= 7;мого проекта про = 75;раммного продукта;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;щие требования = 82; характерисm= 0;икам комплекса задач ПС:<o:p></o:p> * цели создания программноk= 5;о продукта и н= 072;значение комплекса функционалn= 0;ных задач;<o:p></o:p> * перечень объектов среды применения ПС (технолог= 080;ческих объектов управления, подразделеl= 5;ий предприятиn= 3; и т. п.), при управлении которыми до = 83;жен решаться комплекс задач;<o:p></o:p> * периодичнl= 6;сть и продолжитеl= 3;ьность решения комплекса з = 72;дач;<o:p></o:p> * связи и взаимодейсm= 0;вие комплекса задач с внеш= 085;ей средой и дру= 075;ими компонентаl= 4;и системы;<o:p></o:p> * распределеl= 5;ие функций между персоналом, программныl= 4;и и техl= 5;ическими средствами при различных ситуациях решения тре = 73;уемого комплекса функционалn= 0;ных задач= ;;<o:p></o:p> - требованиn= 3; к входной информации:<o:p= ></o:p> * источники информации = 80; их идентифи = 82;аторы;<o:p></o:p> * перечень и описание входных соо = 73;щений (идентифика = 90;оры, формы представлеl= 5;ия, регламент, сроки и част= 086;та поступлениn= 3;); <o:p></o:p> * перечень и описание структурныm= 3; единиц информации входных сообщений или ссылка н= 072; документы, содержащие эти данные;<o:p></o:p= > - требованиn= 3; к выходной информации:<o:p= ></o:p> * потребитеl= 3;и и назначени = 77; выходной информации;<o:p= ></o:p> * перечень и описание выходных сообщений;<o:p></o:p>= * регламент = 80; периодичноl= 9;ть их выдачи;<o:p></o:p></span= > * допустимоk= 7; время задержки решения определеннm= 9;х задач;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;писание и оценка преимущестk= 4; и недостатк = 86;в разработанl= 5;ых альтернатиk= 4;ных вариантов функций в концепции создания проекта ПС;<o:p></o:p= > <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1089;опоставите= льный анализ требований заказчика и пользоватеl= 3;ей к программн = 86;му продукту и набора функций в концепции П = 57; для удовлет = 74;орения требований заказчика и пользоватеl= 3;ей;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;боснование выбора оптимальноk= 5;о варианта требований = 82; содержанию = 80; приоритетаl= 4; комплекса функций ПС в концепции;<o:p></o:p>= <![if !supportLists]>- = &nb= sp; <![endif]>о = 73;щие требования = 82; структуре, составу ком = 87;онентов и интерфейс = 72;м с внешней средой; <o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;жидаемые результаты = 80; возможная эффективноl= 9;ть реализации выбранного варианта требований = 74; концепции П = 57;;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>о = 88;иентировоч&#= 1085;ый план реализации выбранного варианта тр = 77;бований концепции ПС;<o:p></o:p> <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;бщие требования = 82; составу и содержанию = 76;окументаци&#= 1080; проекта ПС;<o:p></o:p= > <![if !supportLis= ts]>- = &nb= sp; <![endif]>&#= 1086;ценка необходимыm= 3; затрат ресурсов на разработку, ввод в действие и обеспечениk= 7; функционирl= 6;вания ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ый состав требований, гарантируюm= 7;их качество применения ПС;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ые требования = 82; условиям ис = 87;ытаний и приемки си= 089;темы и ПС.<o:p></o:p> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-align:justify;text-inden= t: 35.45pt;line-height:normal;tab-stops:35.4pt'><a name=3D"_Toc4297197"> <o:p></o:p= ></a></h2> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:35.45pt;line-heig= ht: normal;tab-stops:35.4pt'> Спецификаm= 4;ия требований = 82; системе и к комплексу программ на = 101;тапе детального проектировk= 2;ния:<o:p></o:p></h2> <![if !supportLists]>- = <![endif]>тре&= #1073;ования проекта системы к комплексу программ, ка= 082; к целому в общей архит = 77;ктуре системы; <o:p></o:p></span= > <![if !supportLists]>- = <![endif]>тре&= #1073;ования к унификации интерфейсl= 6;в и базы данны= 093; комплекса п = 88;ограмм;<o:p></o:p> <![if !supp= ortLists]>-&nb= sp; = <![endif]>т = 88;ебования и обоснованиk= 7; выбора проектных решений уровня системы, состава компонентоk= 4; системы, опи= 089;ание функций системы и ПС с точки зрен= 080;я пользоватеl= 3;я; <o:p></o:p> <![if !supp= ortLists]>-&nb= sp; = <![endif]>с = 87;ецификация требований верхнего уровня комплекса п = 88;ограмм, производныk= 7; требования = 82; компонентаl= 4; ПС и требования = 82; интерфейсаl= 4; между систе = 84;ными компонентаl= 4;и, элементами конфигурацl= 0;и ПС и аппарат= 091;ры;<o:p></o:p> <![if !supportLists]>- &nbs= p; <![endif]>о = 87;исание распределеl= 5;ия системных требований по компонен = 90;ам ПС с учетом требований, которые обеспечиваn= 2;т заданные характерисm= 0;ики качества;<o:p></o:p>= <![if !supportLists]>- = <![endif]>тре&= #1073;ования к архитектурk= 7; системы, содержащей идентификаm= 4;ию и функции компонентоk= 4; системы, их назначение, статус разр = 72;ботки, аппаратные = 80; программныk= 7; ресурсы;<o:p></o:p>= <![if !supportLists]>- = <![endif]>тре&= #1073;ования совместногl= 6; целостного функционирl= 6;вания компонентоk= 4; ПС, описание и характерисm= 0;ики их динамическl= 0;х связей;<o:p></o:p> <![if !supportLists]>- = <![endif]>тре&= #1073;ования анализа тр= ;ассируемос = 90;и функций компонентоk= 4; программноk= 5;о средства к требованияl= 4; проекта сис = 90;емы;<o:p></o:p> <![if !supportLi= sts]>- = <![endif]>тре&= #1073;ования для системы или/и подсистем и = 084;етоды, которые должны быть = 080;спользован&= #1099; для гаранти = 80; того, что каждое треб = 86;вание к комплексу программ будет выпол = 85;ено и прослеживаk= 7;мо к конкретны = 84; требованияl= 4; системы:<o:p></o:p> * к режимам работы;<o:p></o:p> * к производитk= 7;льности системы;<o:p></o:p> * к внешнему и пользоватеl= 3;ьскому интерфейсу системы;<o:p></o:p> * к внутреннемm= 1; интерфейсу компонентоk= 4; и к внутренн= 080;м данным системы;<o:p></o:p> * по возможностl= 0; адаптации П = 57; к внешней ср= 077;де;<o:p></o:p> * по обеспечениn= 2; безопасносm= 0;и системы, ПС и &= #1074;нешней среды;<o:p></o:p> * по обеспечениn= 2; защиты, безопасносm= 0;и и секретностl= 0; данных;<o:p></o:p> * по ограничениn= 3;м доступных ресурсов проекта ПС;<o:p></o:p= > * по обучению и уровню квалификацl= 0;и персонала;<o:p= ></o:p> * по возможностn= 3;м средств аттестации результатоk= 4; и компонентоk= 4;, включающие = 74; себя демонс = 90;рацию, тестированl= 0;е, анализ, инспекцию и требуемые специальныk= 7; методы для контроля функций и качества ко = 85;кретной системы или компонента ПС.<o:p></o:p> Представлk= 7;нный состав спец = 80;фикации требований на этапе дет= 072;льного проектировk= 2;ния может использоваm= 0;ься как компоне = 85;т для уточнен = 80;я техническоk= 5;о задания и ко= 085;тракта с заказчико = 84; на проект ЖЦ ПС и служить базой для формированl= 0;я комплекса о = 90;четных требований, утверждаемm= 9;х и проверяемыm= 3; заказчиком при приемке = 075;отового программноk= 5;о продукта. Состав стандартизl= 0;рованных характерисm= 0;ик качества программныm= 3; средств и процессы выбора треб = 86;ваний к ним в конкретных проектах представлеl= 5;ы в лекциях 11 и 12. Эти требования должны быть отдельным, обязательнm= 9;м разделом в общей спецификацl= 0;и требований, итерационнl= 6; формируемыl= 4;и на этапах концепции и проектировk= 2;ния ПС, и контролируk= 7;мыми при испытаниях программноk= 5;о продукта.<o:p></o:p>= <o:p> </o:p> <h1><a name=3D"_Toc508102471"></a><a name=3D"_Toc508102244">Лекция 7. Планированl= 0;е жизненного цикла = &nb= sp; программнm= 9;х средств</a></h1> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-indent:35.45pt;line-heig= ht: normal'><o:p> </o:p></h2> <h1><a name=3D"_Toc508102472"></a><a name=3D"_Toc508102245">7.1. Организациn= 3; планированl= 0;я жизненного цикла = сложных пр = 86;граммных средств</a></h1> <o:p> </o:p> Цель планированl= 0;я жизненного цикла программноk= 5;о средства состоит в выборе и определениl= 0; способов создания и совершенстk= 4;ования ПС, ко = 90;орые способны удовлетворl= 0;ть требованияl= 4; техническоk= 5;о задания, спе= 094;ификаций и контракта, а также обеспечить уровень качества, со= 086;тветствующ&= #1080;й заданным тр = 77;бованиям. В современн = 99;х стандартах подчеркиваk= 7;тся, что эффективноk= 7; планированl= 0;е - определяющl= 0;й фактор высокого ка = 95;ества всего ЖЦ программноk= 5;о средства, удовлетворn= 3;ющего требованияl= 4; заказчика. В стандартах ISO 12207 и ISO 16326 рекомен&#= 1076;уется определить = 72;дминистрат&#= 1086;ра, который должен подг = 86;товить планы для выполнения процессов ЖЦ ПС. = 055;ланы, связанные с = 074;ыполнением процесса, должны содержать описания соответствm= 1;ющих работ и задач, обозн= 072;чения создаваемыm= 3; компонентоk= 4; программноk= 5;о средства и охватывать следующие задачи:<o:p></o:p> установ= ;ление графиков своевременl= 5;ого решения частных зад = 72;ч и всего ПС;<o:p></o:p></spa= n> оценки необходимыm= 3; трудозатраm= 0; на задачи и проект в целом;<o:p></o:p> определ= ;ение ресурсов, необходимыm= 3; для выполне = 85;ия задач и прое= 082;та;<o:p></o:p> распред= ;еление задач по исп= 086;лнителям;<o:p></o:p></s= pan> определ= ;ение обязанностk= 7;й исполнителk= 7;й;<o:p></o:p> определ= ;ение критическиm= 3; ситуаций, связанных с задачами ил = 80; процессами ЖЦ ПС;<o:p></o:p> установ= ;ление используемm= 9;х в процессах = 046;Ц ПС критерие = 74; управления качеством; - определенl= 0;е затрат, связанных с = 088;еализацией каждого процесса;<o:p></o:p>= обеспеч= ;ение условий и определениk= 7; инфраструкm= 0;уры выполнения процессов Ж = 62; ПС.<o:p></o:p> Должны быт= 00; определены обязанностl= 0; специалистl= 6;в по подготовке = 80; утверждениn= 2; (согласован = 80;ю) планов. Следует уст = 72;новить модель жизн = 77;нного цикла программноk= 5;о средства, задачи, расп= 088;еделение задач, их бло&#= 1082;ировку и соответствm= 1;ющие ресурсы. В пр&#= 1086;граммном проекте должен быть определен о = 76;ин основной график рабо = 90;, а все вспомо= 075;ательные графики должны быть связаны и согласованm= 9; с основным графиком. С помощью структуры классификаm= 4;ии работ можно эффективно проверять ход процессов и обеспечиваm= 0;ь контроль этих процессов и продуктов. План должен быт= 00; применен так, чтобы обеспечить управление программныl= 4; проектом на всех уровня = 93; его детализациl= 0; с использоваl= 5;ием соответствm= 1;ющих технологий = 74; зависимостl= 0; от объема, сложности, критичностl= 0; и риска прое= 082;та. Оценки проекта, используемm= 9;е при планиро = 74;ании, должны охва = 90;ывать: <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>с = 90;оимость реализации соответствm= 1;ющих процессов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>и = 85;фраструкту&#= 1088;у обеспечениn= 3; реализации = 87;роцессов;<o:p></o:p></sp= an> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>п = 86;требности в ресурсах, включая соответствm= 1;ющее управление = 80; контроль;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>о = 94;енку и контроль качества реализации процессов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>у = 87;равление риском результатоk= 4; процессов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>о = 73;еспечение среды программноl= 1; инженерии проекта ПС;<o:p></o:p= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo123;tab-stops:35.75pt;background: white;mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>= - <![endif]>з = 72;дания, выполняемыk= 7; в каждом процессе и (и&#= 1083;и) работе.<o:p></o:p> &n= bsp; Администрk= 2;торы каждого программноk= 5;о проекта должны стре = 84;иться по возможно = 89;ти использоваm= 0;ь существующm= 1;ю организациl= 6;нную инфраструкm= 0;уру предприятиn= 3;. Если существующk= 2;я инфраструкm= 0;ура не удовлетв = 86;ряет потребностn= 3;м конкретногl= 6; проекта, тогда она должна быть = 089;оответству&= #1102;щим образом ада = 87;тирована или дополне = 85;а. Для устранения несовершенl= 9;тва (неполноты) существующk= 7;й инфраструкm= 0;уры может потре = 73;оваться использоваl= 5;ие субподряднm= 9;х работ. <o:p></o:p> Планироваl= 5;ие является постоянной, повторяющеl= 1;ся работой, при выполнении которой оценивают, уточняют и, при необходимоl= 9;ти, корректируn= 2;т ход проекта. Администраm= 0;оры программноk= 5;о проекта дол = 78;ны использоваm= 0;ь соответствm= 1;ющие процессы, сп= 086;собствующи&= #1077; проведению перепланирl= 6;вания и уточненны = 93; оценок в жизненном цикле прогр = 72;ммного проекта. В каждом программноl= 4; проекте имеется мно = 78;ество взаимосвязk= 7;й, поэтому для уточнения исходного плана управления проектом обычно требуется несколько и = 90;ераций. При необходимоl= 9;ти внесения в план управл = 77;ния информации, содержащейl= 9;я в других пла= 085;ах, в данном пла= 085;е может быть приведена ссылка на эт= 080; планы.<o:p></o:p> В стандарте ISO 15504 расширены, детализироk= 4;аны задачи и вид= 099; деятельносm= 0;и, которые следует отраж= ;ать в плане управления проектом ПС: <o= :p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>в = 99;брать модель жизненного цикла программныm= 3; средств, соо= 090;ветствующу&= #1102; назначению, функциям, величине и сложности п = 88;оекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>о = 87;ределить работы, которые необходимо выполнить п = 86; проекту и возможностn= 0; достижения целей проекта в рамках суще = 89;твующих ресурсов и ограничениl= 1;;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>о = 94;енить варианты достижения целей проек = 90;а и определит= 00;, на основе анализа рисков, кака= 103; стратегия целесообраk= 9;на; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>к = 86;личественн&#= 1086; оценить сложность работ и ресу= 088;сы, необходимыk= 7; для их выпол= 085;ения, рассматривk= 2;я варианты достижения = 94;елей проекта и принимая во внимание су = 97;ествующие риски и возм= 086;жности, чтобы весь жизненный ц = 80;кл ПС удовлетворn= 3;л требованияl= 4; заказчика; <o:p></o:p= > <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>в = 99;явить и выбрать элементы человеческl= 0;х и материальнm= 9;х ресурсов, необходимыk= 7; для обеспечениn= 3; и реализаци = 80; стратегии проекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>у = 89;тановить график (исполнител = 80;, сроки, ресур= 089;ы) выполнения проекта, осн= 086;вываясь на распреде = 83;ении работ, оценках и элементах и = 85;фраструкту&#= 1088;ы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 99;явить конкретных лиц и группы, дающие треб = 91;емый вклад в проект, опре= 076;елить им конкретные зоны ответственl= 5;ости, и обеспечит= 00; то, чтобы обя&#= 1079;анности были поняты = 080; приняты, профинансиl= 8;ованы и достижимы;<o:= p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 76;ентифициро&#= 1074;ать интерфейсы между элементами проекта, а также с другими проектами и = 086;рганизацио&= #1085;ными единицами с = 80;стемы; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 87;ределить инструментk= 2;рий для обеспеч = 77;ния того, чтобы планы проекта был = 80; формально разработанm= 9;, реализованm= 9;, поддержаны = 80; доступны лицам, вовле= 095;енным в проект, обеспечить публикацию планов для специалистl= 6;в, к которым он= 080; относятся;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>и = 89;пользовать упорядоченl= 5;ые методы для т= 086;го, чтобы регул= 03;рно оценивать степень выполнение проекта, при= 085;имать меры, для корректироk= 4;ки отклонений от плана и предотвращk= 7;ния повторения проблем, выя= 074;ленных в проекте.<o:p></o:p></span= > Поставщ= ;ик-разработ= 095;ик ПС должен подготовитn= 0; планы по каж= 076;ому виду деятельносm= 0;и. Следует установить = 80; поддерживаm= 0;ь в рабочем состоянии документирl= 6;ванные процедуры, гарантируюm= 7;ие разработку программноk= 5;о продукта в соответствl= 0;и с заданными требованияl= 4;и и согласно плану развития ЖЦ. Такие планы должны описывать в = 80;ды деятельносm= 0;и или содержать ссылки на разделы стандартов = 80; определять ответственl= 5;ость за их осущес= 090;вление. <o:p></o:p> Планиро= ;вание жизненного цикла ПС должно опре = 76;елить действия по анализу тре = 73;ований, проектировk= 2;нию, программирl= 6;ванию, интегрировk= 2;нию, тестированl= 0;ю, установке и поддержке программныm= 3; средств с це= 083;ью их принятия = 080; применения заказчиком. = 046;изненный цикл следуе = 90; оформить документамl= 0;, которые необходимо = 87;роанализир&#= 1086;вать на реализуе = 84;ость и утвердить. Они должны актуализирl= 6;ваться по мере развития пр = 86;екта. В планах необходимо определить, каким образом сле = 76;ует управлять проектом, контролироk= 4;ать и анализировk= 2;ть выполнение работ, а такж&#= 1077; установить вид и частот= 091; отчетов для руководствk= 2;, заказчика и других заин = 90;ересованны&#= 1093; сторон, принимая во внимание вс = 77; конкретные требования заказчика. В планах должны определятьl= 9;я организациl= 6;нные подразделеl= 5;ия и специалистm= 9;, которые будут испол = 85;ять различные виды работ. Для этого планы должн = 99; содержать с = 83;едующую информацию:<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>р = 86;ли и обязанностn= 3;х соответствm= 1;ющих субъектов проекта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>п = 86;длежащие выполнению работы и задачи;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>п = 77;речень всех проектных результатоk= 4; (продуктов), подлежащих поставке и определеннm= 9;х в структуре классификаm= 4;ии работ;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>к = 88;итерии завершения соответствm= 1;ющей деятельносm= 0;и, работ, задач;<o= :p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>с = 86;став окончательl= 5;ых отчетных документов;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>о = 90;четные документы п = 86; стоимости и графикам проведения = 88;абот;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>с = 86;держание средств организациl= 0; работ по упр= 072;влению, выпуску продукта и/или синхронизаm= 4;ии работ;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>п = 77;риодичност&#= 1100; и средства выдачи отчетных документов;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>о = 90;четные материалы п = 86; проблемам-д = 77;фектам или выполнению деятельносm= 0;и;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l6 level1 lfo124;tab-stops:14.2pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- <![endif]>т = 88;ебования к ресурсам и их наличие.<o:p></o:p= > Стандар= ;тами ISO 16326 и ISO 90003 &nb= sp; рекомендуk= 7;тся в процессе п= 083;анирования ЖЦ ПС подгот= 086;вить и утвердить содержание следующих п = 83;анов (рис. 7.1): <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;зработки компонентоk= 4; и всего ЖЦ ПС, который должен определять используемm= 1;ю модель жизненного цикла комплекса п = 88;ограмм и его компон= 077;нтов, а также внеш= 085;юю технологичk= 7;скую среду проектировk= 2;ния;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 77;рификации и тестированl= 0;я, который оп = 88;еделяет методы и средства, способные удовлетворl= 0;ть последоватk= 7;льные цели процесса устранения дефектов и контроля ка = 95;ества ПС и его комп&#= 1086;нентов;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 77;ализации процессов интеграции компонентоk= 4; в версии ком= 087;лекса программ;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;провождени&#= 1103; и управлени= 03; конфигурацl= 0;ей ПС, который должен устанавливk= 2;ть методы и средства, пр= 080; помощи которых буд = 91;т удовлетворn= 3;ться цели процесса со = 74;ершенствов&#= 1072;ния, управления = 80;зменениями и корректироk= 4;ками программ; <o:p></o:p></span= > <![if !supportLists]>- &nb= sp; <![endif]>т = 80;ражировани&#= 1103;, адаптации и внедрения версий ПС дл= 103; конкретных пользоватеl= 3;ей, включая их подготовку = 80; обучение; <o:p></o:p></span= > <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1076;окументиро= вания процессов и результатоk= 4; жизненного цикла ПС, создания и выпуска тех = 85;ологическо&#= 1081; и эксплуатацl= 0;онной документацl= 0;и; <o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1091;правления и обеспечениn= 3; качества ПС, определяющl= 0;х методы и средства, пр= 080; помощи которых будет гаран = 90;ировано требуемое качество ко = 84;плекса программ.<o:p></o:p>= Соответстk= 4;ующие планы должн = 99; быть разработанm= 9; администраm= 0;орами вспомогатеl= 3;ьных процессов, так как эти процессы об = 99;чно являются частью проекта. Данные план = 99; должны быть привязаны к базовому плану управ = 83;ения жизненным циклом программноk= 5;о проекта и обеспечиваm= 0;ь его реализацию; они могут быть оформл = 77;ны в виде отдел= 100;ных планов или включены в общий план. Планы должны быть согласованm= 9; (утверждены) менеджером проекта про = 75;раммного средства и подлежат контролю пр = 80; внесении изменений в проект. Менеджером </sp= an>= - администраm= 0;ором планированl= 0;я программноk= 5;о средства должна быть определена отчетность по вспомога = 90;ельным процессам (либо непосредстk= 4;енная, либо через управление организациk= 7;й). Должны быть представлеl= 5;ы отчеты о про= 073;лемах-дефек= тах и исключителn= 0;ных ситуациях д = 83;я анализа их влияния на стоимость проекта, график рабо = 90; по нему, область управления проектом и его качеств = 86;. Должен быть определен механизм дл= 03; разрешения или преодол = 77;ния конфликтныm= 3; ситуаций между админ = 80;стратором планированl= 0;я ЖЦ программноk= 5;о средства и администраm= 0;орами вспомогатеl= 3;ьных процессов н = 72; соответствm= 1;ющем уровне их полномочий по организациl= 6;нному управлению.<o:p= ></o:p> Когда определеннm= 9;е контрольныk= 7; точки проекта и результаты, установленl= 5;ые требованияl= 4;и для этих точек, зависят от выходных р = 77;зультатов вспомогатеl= 3;ьного процесса, важно, чтобы отчетные материалы п = 86; ним были представлеl= 5;ы точно и своевременl= 5;о в соответствl= 0;и с установле = 85;ными планами. Это положение является общим для всех контро = 83;ьных точек, связанных с выполнениеl= 4; договорных обязательсm= 0;в по вспомога = 90;ельным процессам, поэтому необходимы = 89;инхронизац&#= 1080;я соответствm= 1;ющих планов и своевременl= 5;ое уведомлениk= 7; администра&#= 1090;ора программноk= 5;о средства о всех затруднениn= 3;х, возникающиm= 3; при выполне = 85;ии соответствm= 1;ющих задач вспомогатеl= 3;ьных процессов. Синхронизаm= 4;ия всех планов может быть з= 072;труднена при наличии субподряднm= 9;х соглашений = 80; заданий, но упрощена пр = 80; наличии еди = 85;ого базового плана.<o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102473"></a><a name=3D"_Toc508102246">7.2. Задачи планов для обеспечениn= 3; жизненного цикла сложн = 99;х прогр= ;аммных средств</a></h1> <o:p> </o:p> План управления жизненным циклом ПС включает регламентиl= 8;ованные стандартамl= 0;, процедуры анализа, проверки и оценки сост = 86;яния проекта для реализации организациl= 6;нных и управляющиm= 3; воздействиl= 1; на компонен = 90;ы и ПС в целом. При этом должны испо = 83;ьзоваться техническоk= 7; задание и спецификацl= 0;и требований, = 074; которых определяющm= 1;ю роль играют согласованl= 5;ые с заказчико = 84; входные и выходные данные проекта ПС. П&#= 1086;требитель-з= ;аказчик может иметь определеннm= 9;е обязанностl= 0; согласно ко = 85;тракту при формиро = 74;ании ЖЦ ПС. Особого внимания потребителn= 3; требует сотрудничеl= 9;тво с разработч = 80;ком-поставщ&= #1080;ком, своевременl= 5;ое предоставлk= 7;ние ему нужной информации = 80; решение опе = 88;ативных вопросов дл= 03; обеспечениn= 3; качества ПС. Если предст = 72;витель заказчика обладает соответствm= 1;ющей компетентнl= 6;стью, то он может представляm= 0;ь конечного пользоватеl= 3;я продукта, а также админ = 80;стративное руководствl= 6; проектом и иметь полно = 84;очия заниматься контрактныl= 4;и вопросами. К ним относят = 89;я определениk= 7; и уточнение требований спецификацl= 0;й потребителn= 3; к поставщик = 91; и к показателяl= 4; качества ПС, одобрение и утверждениk= 7; предложениl= 1; разработчиl= 2;а, а также заключение дополнителn= 0;ных соглашений = 89; поставщикоl= 4;. Целесо&#= 1086;бразно планироватn= 0; либо регуля = 88;но проводить разработчиl= 2;ом и заказчико = 84; совместные анализы состояния п = 88;оекта, либо такие анализы в случае значительнm= 9;х проектных событий, чтобы охват = 80;ть:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;стояние и развитие выполняемыm= 3; поставщикоl= 4; работ по раз= 088;аботке и модификац = 80;и программноk= 5;о средства;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;ответствие результатоk= 4; разработки, согласованl= 5;ой спецификацl= 0;и требований заказчика;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 86;стояние работ, касающихся подготовки = 80; обучения конечных пользоватеl= 3;ей разрабатывk= 2;емой системы;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 77;зультаты проверок текущего состояния п = 88;оекта и приемочны = 93; испытаний.<o:p></o:p>= План разработки компонентоk= 4; и ПС в целом (см. рис. 7.1) должен включать назначение, стандарты и описание фрагментов жизненного цикла, которые следует использоваm= 0;ь в процессе разработки:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>п = 88;едваритель&#= 1085;ое описание процессов стандартизl= 0;рованного ЖЦ ПС и его компон= 077;нтов, которые должны использоваm= 0;ься для формиро = 74;ания конкретногl= 6; жизненного цикла данного проекта, включая кри = 90;ерии перехода между этапами разработки;<o:p= ></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>и = 76;ентификаци&#= 1102; фрагментов стандартов: на требован = 80;я к ПС; описание проекта; кодированиk= 7; программ дл= 03; данного проекта; а также, ссылк= 080; на стандарт = 99; для ранее ра= 079;работанных компонентоk= 4;, включая исп = 86;льзуемые готовые апробироваl= 5;ные компоненты ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 73;основание выбора инструментk= 2;льной среды разработки ПС в аппаратной = 80; программноl= 1; части, которые будут использоваm= 0;ься, включая выбор языков программирl= 6;вания, средств кодированиn= 3;, компиляторl= 6;в, редакторов связей и загрузчикоk= 4;.<o:p></o:p> План верификациl= 0; и тестированl= 0;я ПС является предваритеl= 3;ьным описанием организациl= 0; процедур тестированl= 0;я, удовлетворn= 3;ющих цели достижения = 79;аданной корректносm= 0;и программ. Данный план должен вклю = 95;ать:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;исание методов, которые будут использоваm= 0;ься на каждом этапе, а также для обеспечениn= 3; независимоl= 9;ти верификациl= 0; и тестирова = 85;ия;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;спределени&#= 1077; организациl= 6;нной ответственl= 5;ости внутри проц = 77;ссов тестированl= 0;я и интерфейс = 99; с другими процессами жизненного цикла ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;исания оборудованl= 0;я для анализа = 080; тестироваl= 5;ия, инструментk= 2;льных средств, а также руководств по применен = 80;ю этих средст = 74; и аппаратно = 75;о тестового оборудованl= 0;я;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 87;исание методов идентификаm= 4;ии компонентоk= 4;, на которые оказывает воздействиk= 7; модификациn= 3; ПС, и измененные части исполняемоk= 5;о объектного кода. <o:p></o:p> План сопровождеl= 5;ия и управлени= 03; конфигурацl= 0;ей ПС устанавливk= 2;ет методы, испо= 083;ьзуемые для сопровождеl= 5;ия программныm= 3; средств и их компонентоk= 4; в течение всего жизненного цикла. Этот план должен включать:<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>о = 87;исание процессов управления конфигурацl= 0;ей в жизненном цикле ПС, кот&#= 1086;рые обеспечат выполнение задач сопро = 74;ождения;<o:p></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1086;писание среды управления конфигурацl= 0;ей, которую следует использоваm= 0;ь, включая процедуры, инструментk= 2;льные средства, методы, стандарты, о= 088;ганизацион&= #1085;ые соглашения = 80; интерфейсы;<o:p= ></o:p> <= ![if !supportLists]>- &nb= sp; <![endif]>и = 76;ентификаци&#= 1102; отчетов о дефектах и ошибках программноk= 5;о продукта и п= 088;оцессов жизненного цикла; метод закрытия от = 95;етов об ошибках и взаимодейсm= 0;вия с контролем изменений;<o:p></o:p>= <= ![if !supportLists]>- &nb= sp; <![endif]>а = 88;хивацию версий; применение методов и ср= 077;дств формированl= 0;я версий и обеспечениn= 3; их сохранностl= 0;.<o:p></o:p> Цель планированl= 0;я технологичk= 7;ской среды жизненного цикла ПС состоит в том, чтобы оп&#= 1088;еделить методы, инструментk= 2;льные средства, процедуры, языки программирl= 6;вания и аппаратны = 77; средства, которые буд = 91;т использо= ;ваться и совершенстk= 4;оваться для разработки, верификациl= 0;, управления = 80; подготовки документацl= 0;и программноk= 5;о средства. План должен включать стандарты, методы предотвращk= 7;ния ошибок и обеспечениn= 3; отказоустоl= 1;чивости, которые ограничиваn= 2;т возможностn= 0; внесения ош = 80;бок, и такие методы тест = 80;рования, которые гарантируюm= 0; их обнаруже = 85;ие. Цель методо = 74; обеспечениn= 3; отказоустоl= 1;чивости состоит в том, чтобы включить в проект таки = 77; средства обеспечениn= 3; качества и безопасносm= 0;и применения ПС, которые могут гарантировk= 2;ть, что програм = 84;ное средство бу = 76;ет адекватно реагироватn= 0; на ошибки входных данных, предотвращk= 2;ть выдачу ошиб = 86;чных данных и контролироk= 4;ать возможностn= 0; проявления ошибок. <o:p></o:p> Кроме того, в составе перечисленl= 5;ых планов или автономно может быть полезной разработка ряда вспомо = 75;ательных планов (см. рис. 7.1):<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1087;лана подготовки = 80; обучения пользоватеl= 3;ей для квалифицирl= 6;ванной эксплуатацl= 0;и версий ПС;<o:p></o:p></span= > <![if !supportLis= ts]>- &nb= sp; <![endif]>п = 83;ана обслуживанl= 0;я пользоватеl= 3;ей в процессе эксплуатацl= 0;и ПС;<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1087;лана организациl= 0; переноса и установки в = 77;рсий ПС на различ= 085;ые аппаратные = 80; операционнm= 9;е платформы пользоватеl= 3;ей.<o:p></o:p> Все перечисленl= 5;ые планы должн = 99; иметь в свое= 084; составе предваритеl= 3;ьные графики, идентифициl= 8;ующие: этапы работ; входные, выходные данные и опи= 089;ания решаемых задач; необходимыk= 7; ресурсы, дли= 090;ельность и сроки выполнения; взаимосвязl= 0; этапов и работ. Должн= 086; быть устано = 74;лено организациl= 6;нно-техниче&#= 1089;кое взаимодейсm= 0;вие между различными группами специалистl= 6;в, которые вносят свой вклад в процессы и обеспечениk= 7; качества ЖЦ = 055;С, а необходим = 72;я информация должна документирl= 6;ваться и регулярно анализировk= 2;ться. В планах работ поставщикоk= 4; и субподряд = 95;иков при проектировk= 2;нии следует четко опред = 77;лить границы ответственl= 5;ости за каждую часть программноk= 5;о средства и з= 072; способ обмена техническоl= 1; информациеl= 1; между всеми сторонами п = 88;оекта. При установ = 83;ении этого взаимодейсm= 0;вия следует обратить внимание на вспомогатеl= 3;ьных специалистl= 6;в, помимо потребителn= 3; и поставщик = 72;, которым необходимы входные данные для проектировk= 2;ния, установки, обслуживанl= 0;я и подготовк = 80; программ и д= 072;нных. <o:p></o:p> Анализ состояния и результатоk= 4; проекта следует официально планироватn= 0; и регулярно проводить н = 72; соответствm= 1;ющих этапах ЖЦ ПС. В состав уча= 089;тников каждого ана = 83;иза должны включаться представитk= 7;ли всех служб, заинтересоk= 4;анных в результатаm= 3; анализируе&#= 1084;ого этапа проек = 90;ирования. Степень формальносm= 0;и и жесткости действий по осуществлеl= 5;ию анализа должна соответствl= 6;вать сложности П = 57; и степени риска, связа= 085;ного с областью применения = 80; использоваl= 5;ием программноk= 5;о средства. В процедуры а = 85;ализа проекта могут входить действия, ко= 090;орые необходимо предпринятn= 0; до и во время его проведения, включая используемm= 9;е методики и руководящиk= 7; указания дл= 03; всех участн = 80;ков проверок. Если оговор = 77;но в контракте, поставщик должен проводить совещания п = 86; анализу результатоk= 4; и состояния проекта вместе с зак= 072;зчиком. Обе стороны должны согл = 72;совать результаты подобных анализов. Пр= 086;верку проекта на соответствm= 1;ющих этапах ЖЦ ПС надо проводить, чтобы удост = 86;вериться, что выходны = 77; данные на этих этапах соответствm= 1;ют входным требованияl= 4;. <o:p></o:p> В проверку проекта могут входи = 90;ь: анализ выходных проектных данных; демон= ;страции прототипов = 80; моделей, а также резул= 00;татов их тестиров = 72;ния. Эти проверк = 80; следует проводить согласно документирl= 6;ванным процедурам = 80; планам. Пере= 076; тем, как пред&#= 1083;ожить продукт потребителn= 2; на испытани= 03; и приемку, по&#= 1089;тавщик должен оценить его качество со = 75;ласно назначению = 80; спецификацl= 0;ям требований, например, на этапе окончательl= 5;ого внутреннегl= 6; контроля и испытаний р = 72;зработчико&#= 1084;. При разработке программноk= 5;о средства важно, чтобы результаты оценки и люб= 099;е последующиk= 7; действия, необходимыk= 7; для выполне = 85;ия заданных тр = 77;бований, были зафиксировk= 2;ны и проверены = 087;о завершении этих работ. <o:p></o:= p> <o:p></o:p> <h1><a name=3D"_Toc508102474"></a><a name=3D"_Toc508102247">7.3. Планированl= 0;е процессов управления качеством сложных пр = 86;граммных средств</a></h1> <o:p> </o:p> При проектировk= 2;нии ПС, планированl= 0;е процессов управления качес= ;твом ПС целесооб = 88;азно отделять от непосредстk= 4;енного планированl= 0;я и управлени= 03; процессами создания и совершенстk= 4;ования крупных комплексов программ. Эт= 086; позволяет сосредоточl= 0;ть внимание выделенных специалистl= 6;в на совокупн = 86;сти мероприятиl= 1;, гарантируюm= 7;их качество конечного продукта. Чтобы такие гарантии достигалисn= 0; при минимальныm= 3; затратах, необходимы целенаправl= 3;енное, координируk= 7;мое планированl= 0;е и управлени = 77; для предотвращk= 7;ния ошибок проектировk= 2;ния, а также для в&#= 1099;явления и устранени= 03; дефектов проекта на самых ранни = 93; этапах разработки. Поэтому мероприятиn= 3; планированl= 0;я, обеспечиваn= 2;щие качество пр = 86;грамм, должны охва = 90;ывать не только завершающиk= 7; испытания, н= 086; и весь жизне= 085;ный цикл ПС. <o:p></o:p> Соответ= ;ственно должны выделяться = 80; применятьсn= 3; методы и сре= 076;ства автоматизаm= 4;ии процессов планированl= 0;я и управлени= 03; качеством п = 86; этапам разр = 72;ботки компонентоk= 4; и ПС в условиях реальных ограниченнm= 9;х ресурсов. Следует учи = 90;ывать глубокую взаимосвязn= 0; плана управ = 83;ения и применени= 03; процедур обеспечениn= 3; качества ПС = 089; планом управления непосредстk= 4;енной разработкоl= 1; программ, с процессами тестированl= 0;я, испытаний и сертификацl= 0;и ПС. Эта связь выражается = 74; аналогичноl= 4; поэтапном представлеl= 5;ии планов и в наличии в ни= 093; значительнl= 6;й части близких по содержанию = 87;роцессов и документо = 74;. При планированl= 0;и процессов обеспечениn= 3; качества ПС, целесообраk= 9;но учитывать и использоваm= 0;ь совокупносm= 0;ь рекомендацl= 0;й ряда станда = 88;тов, в которые входят – ISO 10005, ISO 10006, ISO 10013, поддерживk= 2;ющие базовые стандарты м = 77;неджмента качества серии ISO 9000 (см. ле= ;кцию 3). <o:p></o:p> В соответствl= 0;и со стандартамl= 0; процедуры у = 87;равления качеством должны прим = 77;няться к различным документам = 80; данным, вклю= 095;ая: контрактныk= 7; документы; процедурныk= 7; документы, описывающиk= 7; процессы системы качества; состояние работ поставщика- = 88;азработчик&#= 1072;; взаимодейсm= 0;вие поставщика = 80; заказчика; д= 086;кументы и данные, которые опи = 89;ывают конкретный программныl= 1; продукт. В составе документов должны соде = 88;жаться методики, инструкции = 80; описания по = 080;спользован&= #1080;ю конкретных инструментk= 2;льных средств и выполнению частных работ и опер= 072;ций в ЖЦ ПС. Для этого в обще= 084; случае долж = 85;ы быть выделены ру = 82;оводители и коллектив специалистl= 6;в, которые должны план = 80;ровать, создавать, утверждать = 80; сопровождаm= 0;ь комплекты документов. Они должны с= 090;имулирова= 090;ь разработчиl= 2;ов ПС осуществляm= 0;ь непрерывно= е, регламентиl= 8;ованное документирl= 6;вание процессов и результатоk= 4; своей деяте = 83;ьности, а также конт= 088;олировать полноту и качество результируn= 2;щих и отчетных д= 086;кументов. Стандарты и базовые нормативныk= 7; документы Ж = 62; ПС должны служить вер = 93;ним уровнем иерархичесl= 2;ой системы технологичk= 7;ских документов, регламентиl= 8;ующих и конкретизиl= 8;ующих все этапы, работы и до= 082;ументы проекта.<o:p></o:p>= Организ= ;ационной основой управления качеством П = 57; на базе стан= 076;артов ЖЦ является план обеспечениn= 3; заданных характерисm= 0;ик качества на всех этапах жизненного цикла компл = 77;кса программ (см. лекцию 11). Для этого до начала разработки = 74; процессе формированl= 0;я требований техническоk= 5;о задания следует сформулироk= 4;ать основные положения методики обеспечениn= 3; качества, по= 101;тапных испытаний компонентоk= 4; и определен = 80;я достигнутыm= 3; значений характерисm= 0;ик, допустимых для продолж = 77;ния работ на следующих этапах. Тако= 081; план целесообраk= 9;но создавать для сложных проектов ПС на этапах системного анализа, раз= 088;аботки требований техническоk= 5;о задания и проектировk= 2;ния. На этих этап= 072;х оформляютсn= 3; первичные требования = 82; характерисm= 0;икам и качеству П= 057; и, соответстk= 4;енно, должна планироваm= 0;ься совокупносm= 0;ь мероприятиl= 1;, обеспечиваn= 2;щих их достижение = 74; процессе последующеk= 5;о проектировk= 2;ния. В плане упра= 074;ления качеством П = 57; должны быть отражены:<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>ц = 77;ли управления качеством, номенклатуl= 8;а и требовани= 03; к значениям = 093;арактерист&= #1080;к качества, область действия требований = 80; условия их применения;<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1084;етоды управления = 80; достижения заданных зн = 72;чений качества; процедуры, к= 086;торые должны выполнятьсn= 3; для каждого процесса и н= 072; протяжении всего жизненного цикла ПС; действия, связанные с = 086;тчетностью об ошибках, с трассировкl= 6;й и системой к= 086;рректирующ&= #1080;х действий;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>о = 88;ганизация разработчиl= 2;ов и технологи= 03; создания ПС; утвержде= 085;ные обязанностl= 0; специалистl= 6;в по обеспечениn= 2; качества, их ответственl= 5;ость и полномочи= 03; на утвержде = 85;ие программныm= 3; компонентоk= 4; и документо = 74;;<o:p></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>р = 77;сурсы, базовые документы и стандарты, и= 089;пользуемые для обеспеч = 77;ния качества на всех этапах разработки;<o:p= ></o:p> <![if !supportList= s]>- = &nb= sp; <![endif]>с = 88;едства автоматизаm= 4;ии разработки, обеспечиваn= 2;щие достижение = 80; измерение заданных свойств и значений характерисm= 0;ик качества;<o:p></o:p>= <![if !supportList= s]>- = &nb= sp; <![endif]>структура = 80; содержание отчетных документов, удостоверяn= 2;щих достижение определеннl= 6;го качества ко = 84;понентов и ПС в целом на последов = 72;тельных этапах разр = 72;ботки, а также их соответствl= 0;е стандартам = 80; требованияl= 4; заказчика.<o:p></o:p>= Реальные ограничениn= 3; ресурсов, используемm= 9;х в процессе разработки, квалификац= ия специалистl= 6;в, изменения внешней сре = 76;ы и требовани = 81; заказчика объективно приводят к отклоненияl= 4; процессов и реализации плана от</spa= n> предполагаk= 4;шегося. Величина таких откло = 85;ений в значитель = 85;ой степени зависит от принятой технологии разработки, от уровня и характерис= тик средств автоматизаm= 4;ии создания программ. Дл= 103; своевременl= 5;ого обнаружениn= 3; отклонений от плана нео= 073;ходимо регулярно регистрироk= 4;ать результаты выполненныm= 3; работ и их качество. Дл= 103; реализации = 90;аких изменений целесообраk= 9;но предусмотрk= 7;ть и согласова = 90;ь с заказчико = 84; специальны= й документ, ре= 075;ламентирую&= #1097;ий правила корректироk= 4;ки плана обеспечениn= 3; качества ПС, а также состав и содержание поддержива= ющей его документацl= 0;и. Подобные изменения должны оформлятьсn= 3; протоколамl= 0; и доводитьс= 03; до сведения всех специалистl= 6;в, к которым они относят = 89;я.<o:p></o:p> Одна из трудностей достижения высокого ка = 95;ества ПС состоит обычно в отсутствии полной совокупносm= 0;и достоверныm= 3; требований = 82; значениям характерисm= 0;ик качества на начальных этапах проектировk= 2;ния и разработк = 80;, а также итерационнm= 9;й процесс их конкретизаm= 4;ии в течение всего жизненного цикла ПС. В ре&= #1079;ультате первично сформулироk= 4;анные требования = 82; характерисm= 0;икам качества сложных ПС, последоватk= 7;льно уточняются = 80; корректируn= 2;тся в процессе взаимодейсm= 0;вия заказчика и разработчиl= 2;а с учетом объективно изменяющихl= 9;я особенностk= 7;й развивающеk= 5;ося проекта ПС. Для этого необходимо контролироk= 4;ать требуемые характерисm= 0;ики в процессе разработки, анализировk= 2;ть их адекватносm= 0;ь целям проекта и уп= 088;авлять их изменениямl= 0; в нужном направлениl= 0;. Активное вз = 72;имодействи&#= 1077; разработчиl= 2;ов с заказчико = 84; или потенци = 72;льными пользоватеl= 3;ями на всех этапах разработки = 87;озволяет уточнять, корректироk= 4;ать и детализир = 86;вать совокупносm= 0;ь спецификацl= 0;й требований = 80; атрибуты ка = 95;ества в соответствl= 0;и с развитием концепции и возрастаниk= 7;м понимания з = 72;дач проекта, как заказчиком, так и разраб= 086;тчиком.<o:p></o:p> Управлениk= 7; качеством комплексов программ предполагаk= 7;т формализацl= 0;ю технологии обеспечениn= 3; их жизненного цикла, а также выдел = 77;ние в специальн = 99;й процесс поэ = 90;апное измерение и анализ теку = 97;его качества программныm= 3; компонентоk= 4; и проекта в ц&#= 1077;лом. В общем случае в процессе планированl= 0;я и управлениn= 3; качеством П = 57; следует учи = 90;ывать:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>а = 85;ализ контракта и спецификацl= 0;й требований заказчика к ПС, выделени= 077; и ранжирова = 85;ие приоритетоk= 4; характерисm= 0;ик и атрибутов качества ко = 85;ечного продукта;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>д = 77;композицию требований = 82; характерисm= 0;икам качества по контролируk= 7;мым этапам и компонентаl= 4; разработки = 80; создание разделов по детальным требованияl= 4; к атрибутам качества в спецификацl= 0;ях на программ = 85;ые компоненты = 80; ПС в целом;<o:p></o:p></spa= n> <![if !supportLists]>- &nb= sp; <![endif]>в = 99;бор или создани = 77; методов, технологии = 80; инструментk= 2;льных средств автоматизаm= 4;ии разработки, = 086;беспечиваю&= #1097;их создание ПС = 080; его компоне = 85;тов с требуемым = 80; характерисm= 0;иками качества;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>р = 72;зработку методик контроля соблюдения = 89;тандартов, правил= технологиl= 0; проектировk= 2;ния и системы обеспечениn= 3; качества жизненного цикла прогр = 72;ммных средств;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здание методов, методик и средств объективноk= 5;о измерения свойств и/ил= 080; значений атрибутов характерисm= 0;ик качества пр = 86;граммных компонентоk= 4; на этапах их создания и всего ЖЦ ПС для испытаний заказчиком = 80; эксплуатацl= 0;и пользоватеl= 3;ями;<o:p></o:p> <![if !supportLists]>- = <![endif]>&#= 1086;рганизацию, обучение и стимулировk= 2;ние коллектива специалистl= 6;в на создание компонентоk= 4; и ПС в целом, в максимальнl= 6;й степени удо = 74;летворяющи&#= 1093; требования заказчиков = 80; пользоватеl= 3;ей к характери = 89;тикам качества.<o:p></o:p>= Чтобы решать эти задачи, коллективы специалистl= 6;в в процессе п= 083;анирования проекта, должны игр = 72;ть активную роль и осуществляm= 0;ь их выполнен = 80;е для обеспечениn= 3; качества на последующиm= 3; этапах жизненного цикла. Они должны действоватn= 0; в соответствl= 0;и с полномочияl= 4;и, ответственl= 5;остью и независимоl= 9;тью, чтобы гаран = 90;ировать удовлетворk= 7;ние целей и требований = 82; качеству ПС. Качество объектов формируетсn= 3; и документи = 88;уется при выполнении частных работ каждого эта = 87;а ЖЦ и окончат= 077;льно удостоверяk= 7;тся при их завер= 096;ении. Измерения объектов разработки = 89;водятся к регулярно = 81;, поэтапной регистрациl= 0; и документи= ;рованию характерныm= 3; для данного объекта показателеl= 1; качества, а также к сопо= 089;тавлению их с заданными требованияl= 4;и. <o:p></o:p> В стандарте ISO<= span style=3D'font-size:14.0pt'> 15504 (раздеl= 3; MAN<= span style=3D'font-size:14.0pt'>.3) процес&#= 1089; планированl= 0;я и управлени= 03; качеством П = 57; концентрирm= 1;ется на мониторингk= 7; качества продуктов и процессов, как проекта, так и предприятиn= 3; в целом. В рез&= #1091;льтате успешной реализации процессов в = 087;роекте должно быть обеспечено: <o:= p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>на основе явны = 93; и неявных требований потребителn= 3; необходимо определить цели по качеству продукта и п= 088;оцессов, которые следует оценивать, п= 088;едпочтител&= #1100;но количествеl= 5;ным образом, для различных к = 86;нтрольных точек в жизненном цикле ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>о = 87;ределить общую стратегию н = 72; уровне прое = 82;та ПС и предпри= 103;тия, помогающие аттестоватn= 0; достижение соответствm= 1;ющих целей по качеству, оп= 088;еделяя количествеl= 5;ную меру резуль = 90;атов деятельносm= 0;и по проекту и критерии их приемки; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>д = 83;я каждой цели по качеству ПС идентифициl= 8;овать виды деятел= 00;ности по контролю = 080; обеспечениn= 2; качества, помогающие = 76;остижению этой цели и её мониторингm= 1;, как на уровн= 077; проекта, так и на уровне предприятиn= 3;, и интегрировk= 2;ть эти виды деятельносm= 0;и в жизненный цикл ПС; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>п = 88;оводить идентифициl= 8;ованные виды деятел= 00;ности по контролю = 080; обеспечениn= 2; качества и подтверждаm= 0;ь их выполнен = 80;е;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>п = 86; ходу реализации проекта в контрольныm= 3; точках жизн = 77;нного цикла ПС применять заданные метрики качества дл= 03; аттестации достижения соответствm= 1;ющих целей по кач= 077;ству;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:12.0pt;mso-bidi-font-size:14.0pt'>- = &nb= sp; <![endif]>в случаях, когда заданные цели по качеству не достигаютсn= 3;, применять корректируn= 2;щие или предотвращk= 2;ющие мероприятиn= 3;, которые могут включ = 72;ть либо исправ = 83;ение продукта, ли= 073;о изменение запланировk= 2;нного набора видо = 74; деятельносm= 0;и для лучшего достижения целей по кач= 077;ству, либо изменение с = 87;ецификации требований продукта ил = 80; определениn= 3; процесса дл= 03; предотвращk= 7;ния повторения дефектов.<o:p></o:p>= Утве= ;рждение и выпуск документацl= 0;и о качестве должны планироватn= 0;ся и контролир = 86;ваться уполномочеl= 5;ным персоналом на предмет и= 093; адекватносm= 0;и. Следует планироватn= 0; и поддерживаm= 0;ь в актуально = 84; состоянии процедуры управления документамl= 0;, которые иде = 85;тифицируют текущий статус корректироk= 4;ки и пересмотр = 72; документов, с тем, чтобы предотвратl= 0;ть использоваl= 5;ие недействуюm= 7;их и/или устаре= 074;ших документов:<o:p= ></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 72;личие актуальных изданий соответствm= 1;ющих документов на всех участках, гд= 077; проводятся работы, от которых зависит эффективноk= 7; функционирl= 6;вание системы кач = 77;ства;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>н = 77;медленное изъятие недействуюm= 7;их и/или устаре= 074;ших документов из всех пунктов их рассылки ил = 80; применения, либо принятие др = 91;гих мер по предотвращk= 7;нию их непреднамеl= 8;енного использоваl= 5;ия;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>и = 76;ентификаци&#= 1102; любых устаревших документов, составленнm= 9;х для юридиче = 89;ких целей и/или для сохранения полезной ин = 92;ормации.<o:p></o:p> Изменен= ;ия документов должны планироватn= 0;ся и утверждатьl= 9;я теми же службами и/или органи= 079;ациями, которые проводили первоначалn= 0;ный анализ и утверждали эту докумен = 90;ацию. Архивные данные по проекту явл= 03;ются основным источником для анализа = 080; осмысления возможностk= 7;й и эффективноl= 9;ти процесса планированl= 0;я в организациl= 0;, рабочих характерисm= 0;ик данного проекта и обобщения полученногl= 6; опыта. Эти архивные да = 85;ные, образующие общую базу данных предприятиn= 3;, следует постоянно и = 89;пользовать для усовершенсm= 0;вования процессов ж = 80;зненного цикла ПС. Та же самая баз= 072; данных долж = 85;а обеспечиваm= 0;ь реализацию процесса управления по отдельны = 84; программныl= 4; проектам. <o:p></o:p></span= > <o:p> </o:p> <h1><a name=3D"_Toc508102475"></a><a name=3D"_Toc508102248">Лекция 8. Объектно-ор = 80;ентированн&#= 1086;е проектировk= 2;ние программныm= 3; средств</a></h1> <o:p> </o:p> <h1><a name=3D"_Toc508102476"></a><a name=3D"_Toc508102249">8.1. Задачи и особенностl= 0; объектно-ор = 80;ентированн&#= 1086;го = &nb= sp; проектироk= 4;ания программнm= 9;х средств</a></h1> <o:p> </o:p> Междунароk= 6;ные стандарты программноl= 1; инженерии (Прилl= 6;жение 1), регламенти&= #1088;уют жизненный цикл программныm= 3; средств широкого класса в раз= 083;ичных областях их применения. Они ориентировk= 2;ны в основном н= 072; структурноk= 7; проектировk= 2;ние и разработк = 91; процессов, функций и данных в различных к = 86;мплексах программ, в которых дом = 80;нируют сложные алгоритмы обработки, относительl= 5;о небольшой совокупносm= 0;и данных. Объектно-о = 88;иентирован&#= 1085;ое проектировk= 2;ние (ООП) предназначk= 7;но организовm= 9;вать программныk= 7; системы с большими базами данных на основе опис = 72;ний объектов реального мира, важных для пользоватеl= 3;ей. Этот подход существеннl= 6; отличается от структурноk= 5;о проектировk= 2;ния, которое акцентировk= 2;но на сложные функции и процессы обработки д = 72;нных. Объекты реального мира, существующl= 0;е внутри области дей = 89;твия ООП програм = 84;ных проектов, определяютl= 9;я в терминах целей, характерисm= 0;ик и ответстве = 85;ностей поведения соответствm= 1;ющих данных (атри= 073;утов) и отношений = 089; другими многочислеl= 5;ными объектами. Все функции при этом скрыты внутри дета = 83;ей описаний об = 98;екта. <o:p></o:p> Объектно-о = 88;иентирован&#= 1085;ое проектировk= 2;ние представляk= 7;т собой страт = 77;гию, в рамках которой программнаn= 3; система состоит из взаимодейсm= 0;вующих объектов, имеющих собственноk= 7; локальное состояние и спосо= ;бных выполнять определеннm= 9;й набор опера = 94;ий, определяемm= 9;й состоянием объекта. Объекты скрывают информацию = 86; представлеl= 5;ии состояний и, следователn= 0;но, ограничиваn= 2;т к ним доступ. Под процессом ООП подразу = 84;евается проектировk= 2;ние классов объектов и в= 079;аимоотноше&= #1085;ий между этими классами. Об= 098;ектно-ориен= тированные системы можно рассм = 72;тривать как совокупносm= 0;ь автономных = 80; в определен = 85;ой степени независимыm= 3; объектов. Из= 084;енение реализации какого-нибу = 76;ь объекта или добавление новых функций не влияет на другие объекты сис = 90;емы. <o:p></o:p> Общий процесс объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния состоит из нескольких крупных эта = 87;ов:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- </spa= n><![endif]>определ= ;ение рабочего окружения системы и разработка моделей её и= 089;пользовани&= #1103;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>проекти= ;рование архитектурm= 9; программноl= 1; системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>определ= ;ение и идентификаm= 4;ия основных об = 98;ектов системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>разрабо= ;тка модели архитектурm= 9; комплекса программ;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l168 level1 lfo129;tab-stops:14.2pt list 48.05pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- </spa= n><![endif]>определ= ;ение и документирl= 6;вание интерфейсоk= 4; объектов.<o:p></o:p>= Проце= сс ООП нельзя представитn= 0; в виде прост= 086;й схемы (как при структу = 88;ном проектировk= 2;нии), в которой предполагаk= 7;тся четкая последоватk= 7;льность этапов. Фактически все перечисленl= 5;ые этапы в знач= 080;тельной мере можно выполнять параллельнl= 6;, с учетом вза= 080;много влияния дру = 75; на друга. Как только разработанk= 2; архитектурk= 2; системы, опр= 077;деляются объекты и интерфейсы. После создания моделей объ = 77;ктов отдельные объекты можно переопредеl= 3;ить, а это может привести к изменениям = 74; архитектурk= 7; системы. <o:p></o:p> Главное преимущестk= 4;о ООП програм = 84;ных средств состоит в том, что оно упрощает задачу внес = 77;ния изменений в системную архитектурm= 1;, поскольку представлеl= 5;ие состояния объекта не оказывает н = 72; нее влияния.<sp= an style=3D'mso-spacerun:yes'> Изменение внутренних данных объе = 82;та не должно влиять на другие объе = 82;ты системы. Более того, так как объекты сла = 73;о связаны между собой, обычно новы = 77; объекты просто вставляютсn= 3; без значите = 83;ьных воздействиl= 1; на остальны = 77; компоненты = 89;истемы. <o:p></o:p> Основ= ные понятия ООП включают: <o:p></o:p></span= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 88;и объектно-ор = 80;ентированн&#= 1086;м проектировk= 2;нии основные компоненты программноl= 1; системы представляn= 2;тся как объекты со своими состояниямl= 0; и операциям = 80;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 73;ъекты предоставлn= 3;ют сервисы (методы) друг&#= 1080;м объектам и создаются в = 088;еальном времени на основе определениn= 3; класса объектов;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 73;ъекты могут быть реализованm= 9; последоватk= 7;льно и параллель = 85;о, параллельнm= 9;й объект може = 90; быть пассивным, у которого состояние изменяется только чере = 79; его интерфе = 81;с, или активны = 84;, который может измен= 03;ть свое состояние без вмешательсm= 0;ва извне;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l128 level1 lfo137;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в процессе объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния возможно создание ряда различных моделей, кот= 086;рые можно разделить н = 72; статическиk= 7; (модели классов, мод= 077;ли обобщения, модели агре = 75;ирования) и динамическl= 0;е (модели последоватk= 7;льностей, модели конечного автомата); - важным преимущестk= 4;ом объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния является то, что он упрощает процесс мод = 80;фикации системы.<o:p></o:p> &n= bsp; Одна часть общей системы занимается сбором данных, другая обобщает данные, полу= 095;енные из различны = 93; источников, третья выполняет архивироваl= 5;ие данных и = 85;аконец четвертая создает результаты. Система представляk= 7;т собой многоуровнk= 7;вую архитектурm= 1;, в которой отражены вс = 77; этапы обработки данных в сис= 090;еме, сбор и обобщение данных, архи= 074;ирование данных и создание результатоk= 4;. Такая многоуровнk= 7;вая архитектурk= 2; вполне годится для проектировk= 2;ния, так как каждый этап основываетl= 9;я только на обработке д = 72;нных, выполненноl= 1; на предыдущем этапе.<o:p></o:p> Использовk= 2;ние методов ООП строго регламентиl= 8;овано, поэтому:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зрастает производитk= 7;льность труда разра = 73;отчиков благодаря переходу к в= 099;сокоэффект&= #1080;вному методу -</span= > на базе предваритеl= 3;ьного анализа про = 77;кта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>з = 72;просы и объекты реального мира проще моделируютl= 9;я путем конце = 85;трации внимания на классах, а не на алгоритм = 72;х их функционирl= 6;вания;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>к = 86;мпоненты системы легко изменяются = 80; применяютсn= 3; повторно;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>т = 88;ебования проще отслеживаюm= 0;ся;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддерживает&#= 1089;я эффектив= ;ное прототиl= 7;ирование;<o:p></o:= p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>р = 72;зработка проекта отличается непрерывноl= 9;тью в представл = 77;нии объектов = - одни и т= 077; же типы диаграмм применяютсn= 3; как при анализе, так и на этапе разработки;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l21 level1 lfo140;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>р = 72;бота по проектировk= 2;нию может осуществляm= 0;ься с помощью универсальl= 5;ых технологичk= 7;ских инструментl= 6;в.<o:p></o:p> ООП = = - только часть объектно-ор= иентированl= 5;ого процесса ра = 79;работки системы, гд= 077; на протяжении всего процесса создания ПС используетl= 9;я объектно-ор = 80;ентированн&#= 1099;й метод. Этот подход подразумевk= 2;ет выполнение трех этапов:<o:= p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l80 level1 lfo138;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>объектно-о= 088;иентирован&= #1085;ый анализ <span style=3D'font-size:= 14.0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";mso-char-type:symbol;mso-symbol-font-family:Symbol; mso-bidi-font-style:italic'>- созда= ние модели пред = 84;етной области приложения ПС, где объекты отр = 72;жают реальные объекты-сущ = 85;ости, а также определяютl= 9;я операции, выполняемыk= 7; объектами;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l80 level1 lfo138;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>объектно-о= 088;иентирован&= #1085;ое проектироk= 4;ание <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > разработка модел= ;и системы ПС и системной архитектурm= 9; с учетом системных т = 88;ебований, в которой определениk= 7; всех объектов по = 76;чинено решению конкретной задачи;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l80 level1 lfo138;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>объектно-о= 088;иентирован&= #1085;ое программирl= 6;вание <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > реализац= ;ия архитектурm= 9; (модели) системы с помощью объектно-ор = 80;ентированн&#= 1086;го языка прогр = 72;ммирования<s= pan style=3D'mso-spacerun:yes'> (напрl= 0;мер, Java), непосредсm= 0;венно выполняющеk= 5;о отражение определеннm= 9;х объектов и п= 088;едоставляю&= #1097;его средства дл= 03; определениn= 3; классов объ = 77;ктов.<o:p></o:p> Этапы могу = 90; "перетекать= ;" друг в друга, т.е. могут не иметь четки = 93; рамок, приче= 084; на каждом этапе обычн = 86; применяетсn= 3; одна и та же с&= #1080;стема нотации. Переход на следующий этап приводит к усовершенсm= 0;вованию и конкретизаm= 4;ии результатоk= 4; предыдущегl= 6; этапа путем более детал= 00;ного описания определеннm= 9;х ранее класс = 86;в объектов и определениn= 3; новых классов. Так как данные скрыты внутри объектов, детальные решения о содержании данных можн = 86; отложить до этапа реализации системы. В не&#= 1082;оторых случаях можно также не спешить с принятием решений о расположенl= 0;и объектов и о том, будут ли эти объекты последоватk= 7;льными или параллельнm= 9;ми. Если необхо = 76;имы функционалn= 0;ные изменения, они произво = 76;ятся внутри объе = 82;та, что приводи = 90; к незначителn= 0;ным изменениям = 74; оставшейся внешней части его процессов. Для обновления или добавления функций, оставшиеся объекты, под= 076;ерживаются с помощью интерфейсоk= 4;. Объектно-ор = 80;ентированн&#= 1086;е проектировk= 2;ние отображает предметную = 86;бласть задачи и ответственl= 5;ости системы, но задерживаеm= 0; определениk= 7; подробностk= 7;й реализации объектов, переносит и = 93; на более поздний эта = 87; разработки = 80; минимизируk= 7;т влияние изменений в функционалn= 0;ных требованияm= 3;.<o:p></o:p> Пр&#= 1080; ООП основно = 77; внимание уделяется тому, &#= 1095;то следует де = 83;ать, каки = 84; образом до = 73;иться цели, а процесс её достижения целиком зависит от этапа разра = 73;отки. Объектная декомпозицl= 0;я дает возмож = 85;ость создавать программныk= 7; комплексы в = 80;зуально меньшего размера путем испол= 00;зования общих механизмов, обеспечиваn= 2;щих необходимуn= 2; экономию выразительl= 5;ых средств. Использоваl= 5;ие объектного подхода повышает уровень уни = 92;икации разработки = 80; пригодностn= 0; для повторн = 86;го использоваl= 5;ия не только программныm= 3; компонентоk= 4;, но и больших комплексов программ, чт= 086; ведет к созданию унифицировk= 2;нной среды разра = 73;отки и переходу к сборочному созданию пр = 86;граммных продуктов. Системы зачастую по = 83;учаются более компактнымl= 0;, чем их структурныk= 7; эквивалентm= 9;, что означае = 90; не только уменьшение объема программноk= 5;о кода, но и удешевлениk= 7; проекта за счет исполь = 79;ования компонентоk= 4; из предыдущих разработок. Однако, структурнm= 9;й подход сохраняет свою высоку= 02; значимость = 80; широко используетl= 9;я на практике. Взаимосвязn= 0;ю между с&= #1090;руктурным и объектно-о= 088;иентирован&= #1085;ым подходами является общность ря = 76;а категорий и понятий жизненногl= 6; цикла ПС.<o:p></o:p> Объектная декомпозицl= 0;я существеннl= 6; отличается от функцl= 0;ональной, поэтому переход на новую технологию связан как с преодолениk= 7;м психологичk= 7;ских трудностей, так и с дополнителn= 0;ными финансовымl= 0; затратами. Кроме того, диаграммы, о= 090;ражающие специфику о = 73;ъектного подхода, гораздо менее нагля = 76;ны и хуже понимаемы непрофессиl= 6;налами, объектно-ор = 80;ентированн&#= 1099;й подход обыч = 85;о не дает немедленноl= 1; отдачи. Эффект от ег= 086; применения начинает сказыватьсn= 3; после разработки = 85;ескольких проектов и накопления повторно ис = 87;ользуемых компонентоk= 4;, отражающих типовые проектные решения в данной области. <o:p></o:p> В программныm= 3; средствах при ООП реко= 084;ендуется выделять тр = 80; уро-вн= 03;:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l225 level1 lfo130;tab-stops:14.2pt list 48.75= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>уровень интерфейсоk= 4;, который занимается = 74;семи взаимодейсm= 0;виями с другими ча= 089;тями системы и предоставлk= 7;нием внешних инт = 77;рфейсов системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l225 level1 lfo130;tab-stops:14.2pt list 48.75= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>уровень сбора данны = 93;, управляющиl= 1; сбором инфо = 88;мации из внешней среды и обобщающий = 76;анные перед отправкой и = 93; в систему по= 089;троения обобщенных результатоk= 4;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l225 level1 lfo130;tab-stops:14.2pt list 48.75= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>уровень объектов, в котором представлеl= 5;ы и описаны вс= 077; объекты, используемm= 9;е в процессе сбора исход = 85;ых данных.<o:p></o:p> В общем случа = 77; рекомендуеm= 0;ся структурирl= 6;вать систему на части так, чтобы архит = 77;ктура была как можно проще. Согласно хо = 88;ошему практическl= 6;му правилу, модель архи = 90;ектуры должна состоять не более чем из семи-восьми основных объектов. Перед выпол = 85;ением проектировk= 2;ния должны быть сформироваl= 5;ы представлеl= 5;ия относительl= 5;о основных об = 98;ектов проектируеl= 4;ой системы. Вместе с тем &#= 1090;ребуется определить = 80; документирl= 6;вать все другие внешние объекты системы. Опред= ;еления объе = 82;тов на данном этапе проек = 90;ирования отражает класс= 099; объектов</spa= n> и структура системы описываетсn= 3; в терминах этих классо = 74;. Классы объектов, определеннm= 9;е ранее, получают более детальное о = 87;исание, поэтому иногда прих = 86;дится возвращатьl= 9;я на данный этап проект = 80;рования для переопредеl= 3;ения классов. Первый этап = 074; любом процессе пр = 86;ектировани&#= 1103; состоит в выявлении взаимоотноm= 6;ений между проектируеl= 4;ым ПС и его окру&#= 1078;ением. Выявление этих взаимоотноm= 6;ений помогает решать, как обеспечить необходимуn= 2; функционалn= 0;ность системы и ка= 082; структурирl= 6;вать систему, чтобы она могла эффек = 90;ивно взаимодейсm= 0;вовать со своим окр= 091;жением.<o:p></o:p> Язык UML представляk= 7;т набор разработанl= 5;ых инженерных = 79;адач практическl= 6;го профиля, которые успешно исп = 99;таны при моделироваl= 5;ии крупных и сложных систем. Подде= ;рживается метамодель для диаграм = 84; классов и набор семантичесl= 2;их и синтаксич = 77;ских правил, опре= 076;еляющих суть элементов и их отношени = 81;. Модель поддерживаk= 7;тся большим количествоl= 4; автоматизиl= 8;ованных инструментl= 6;в. Основные цели исполь = 79;ования языка UML на этапе разработки проекта ПС:<o:p></o:p= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка на уровне пользоватеl= 3;ей готового к применению, выразительl= 5;ого визуальногl= 6; языка моделироваl= 5;ия, применяемоk= 5;о для разрабо = 90;ки и обмена моделями;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка спецификацl= 0;й, независимыm= 3; от определеннm= 9;х языков прог = 88;аммировани&#= 1103; и процессов разработки;<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка формальногl= 6; базиса для представлеl= 5;ия языка модел = 80;рования;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2p= t; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 86;ддержка высокоуровl= 5;евых понятий, так= 080;х как компоненты, элементы со = 90;рудничеств&#= 1072;, каркасы и шаблоны;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l161 level1 lfo127;tab-stops:15.6pt list 32.2pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>и = 85;теграция наилучшего опыта.<o:p></o:p> &n= bsp; Разработчl= 0;ки UML установили, что даже при использоваl= 5;ии современныm= 3; передовых технологий, при сборе требований, анализе и разработке продолжаетl= 9;я борьба с не адекватнымl= 0; и постоянно = 080;зменяющими&= #1089;я требованияl= 4;и заказчиков (см. лекцию 6). В = 72;рианты использоваl= 5;ия предназначk= 7;ны для уточнения д = 80;намически требований = 80; выработки более четко = 75;о представлеl= 5;ия возможных изменений в = 087;оведении системы. Они позволяют реализоватn= 0; функционалn= 0;ные усовершенсm= 0;вования, которые отражаются = 80; адресуются = 74; организоваl= 5;ной форме. Класс= 099; и объекты языка UML демонстрирm= 1;ют гибкость и управляемоl= 9;ть при использ = 86;вании статично и динамично несовершенl= 5;ых описаний. Дл= 103; оживления общения в команде специалистl= 6;в ООП позволя = 77;т реализоватn= 0; в группе программисm= 0;ов интегрировk= 2;нный подход с помощью общего словаря и языка; инкап= 089;уляция данных и алг= 086;ритмов позволяет членам команды работать на = 76; компонентаl= 4;и в параллельнl= 6;м режиме. Такж= 077; в этом случа= 077; можно ограничить влияние изменчивосm= 0;и требований; наследствеl= 5;ные свойства функций и ат= 088;ибутов являются эффективныl= 4; дополнениеl= 4; к функциона = 83;ьным возможностn= 3;м.<o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102477"></a><a name=3D"_Toc508102250">8.2. Основные понятия и модели объектно-ор = 80;ентированн&#= 1086;го = &nb= sp; проектироk= 4;ания программныm= 3; средств</a></h1> <o:p> </o:p> Класс представляk= 7;т собой абстр = 72;кцию в предметно = 81; области приложения, = 074; общем случа = 77; выраженную существитеl= 3;ьным. Абстракция может быть к= 086;нцептуальн&= #1086;й или физической: она отражае = 90; возможност&= #1080; системы по хранению информации = 86; ней, по взаим&#= 1086;действию с ней или же оба эти фактора. Кла<sp= an class=3DGramE>сс включ = 72;ет: атрибуты (данные, описывающиk= 7; объект, а также тот объем информации об объекте, который хранится в системе); отн&#= 1086;шения с другими классами и о= 087;ерациями (поведение данного объекта, которое и описывает соответствm= 1;ющие ответственl= 5;ости). Диаграмма класса отражает содержимое классов (набор декла= 088;ативных, статичных э = 83;ементов модели), и их взаимоотноm= 6;ения. Класс определяет интерфейсы = 89;оответству&#= 1102;щих экземпляроk= 4; объектов (таблица 8.1). <o:p></o:p>= Классы должны отличаться идентичносm= 0;ью структуры, иметь четко определеннm= 9;е ответственl= 5;ости и поддержив = 72;ть системные функции, взаимодейсm= 0;вуя с другими об= 098;ектами посредствоl= 4; сообщений. Кл= ассы описываютсn= 3; с помощью: атрибутов (д= 072;нные, свойства), операций (сл= 091;жбы, функции, поведение, проце= ;сс, методы), жизненногl= 6; цикла разработки ПС (состояние, идентичносm= 0;ь, независимоl= 9;ть существоваl= 5;ия) и ассоциаци = 81; (отношения, связи, соеди= 085;ения). Классы имеют свойства, структуру, п= 086;ведение и отличаютс= 03; независимоl= 9;тью существоваl= 5;ия. Класс может применятьсn= 3; для определениn= 3; подклассов, которые мог = 91;т быть проилл= 02;стрированы примерами. Однако клас = 89; нельзя проиллюстрl= 0;ровать непосредстk= 4;енно, опираясь только на него самого. Классы обладают по = 74;едением, которое также называется операцией, службой, фун= 082;цией или методом. Эти термины = 080;спользуютс&= #1103; в спецификацl= 0;и UML, где операция оп = 80;сывает класс и объект, а метод -</span= > реализk= 2;цию операции. <o:p></o:p></span= > Существуеm= 0; ряд подходо = 74; к определен = 80;ю классов объектов:<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l266 level1 lfo135;tab-stops:list 14.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 89;пользовани&#= 1077; грамматичеl= 9;кого анализа ест = 77;ственного языкового описания си = 89;темы, объекты и атрибуты = - это существитеl= 3;ьные, операции и сервисы = - глаголm= 9;, такой подхо = 76; реализован = 74; иерархичесl= 2;ом методе объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния, который широко испо = 83;ьзуется;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l266 level1 lfo135;tab-stops:list 14.2pt left = 27.35pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 89;пользовани&#= 1077; в качестве объектов ПС событий, объектов и ситуаций реального мира из области приложения (<sp= an class=3DGramE>например</spa= n> самолетов, ролевых сит = 91;аций менеджера) для реализации таких объек = 90;ов, могут потре = 73;оваться специальныk= 7; структуры хранения данных (абстрактны = 77; структуры д = 72;нных);<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l266 level1 lfo135;tab-stops:list 14.2pt left = 27.35pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>п = 88;именение подхода, основанногl= 6; на сценария = 93;, в котором по очереди определяютl= 9;я и анализируюm= 0;ся различные сценарии использоваl= 5;ия системы; группа, отвечающая за анализ, должна иден = 90;ифицироват&#= 1100; необходимыk= 7; объекты, атрибуты и операции; метод анализа, при котором аналитики и разработчиl= 2;и присваиваюm= 0; роли объектам, отражают эффективноl= 9;ть подхода, основанногl= 6; на сценария = 93;.<o:p></o:p> Дл&#= 1103; описания классов можно испол= 00;зовать информацию, полученную из разных источников. Объекты и оп= 077;рации, первоначалn= 0;но определеннm= 9;е на основе неформальнl= 6;го описания системы, могут служить отп = 88;авной точкой при ООП. Затем для усоверш = 77;нствования и расширени= 03; описания первоначалn= 0;ных объектов можно использоваm= 0;ь дополнителn= 0;ную информацию, полученную из области применения ПС или анализа сце = 85;ариев. Дополнителn= 0;ную информацию также можно получить в ходе обсужд = 77;ния с пользоватеl= 3;ями разрабатывk= 2;емой системы или анализа имеющихся с = 80;стем.<o:p></o:p> Объект является отдельным (о= 089;обенным) экземпляроl= 4; класса. Объекты = - это исполняемыk= 7; сущности с атрибутами = 80; сервисами класса объектов. Об= 098;екты представляn= 2;т собой реализацию класса, на основе одно = 75;о класса можн = 86; создать много различных объектов. Обычно при разработке объектных моделей основное внимание сосредоточk= 7;но на классах объектов и и= 093; отношениях. Во всех случаях применяетсn= 3; общее правило, согласно которому объект инка = 87;сулирует данные о своем внутреннем строении. <o:p></o:p></span= > Объект = - это сущность, способная пребывать в различных с = 86;стояниях и имеющее определеннl= 6;е множество операций. Со= 089;тояние определяетl= 9;я как набор атрибутов о = 73;ъекта. Операции, связанные с объектом, предоставлn= 3;ют сервисы (функционал= 00;ные возможностl= 0;) другим объектам (клиентам) для выполнения определеннm= 9;х вычислений. Объекты создаются в соответствl= 0;и с определениk= 7;м класса объе = 82;тов, которое служит шабл = 86;ном для создани= 03; объектов. В него включе = 85;ы объявления всех атрибутов и операций, св= 103;занных с объектом данного класса. Нота= 094;ия, которая используетl= 9;я для обозначениn= 3; классов объ = 77;ктов, определена = 74; UML<= span style=3D'font-size:14.0pt'>. <o:p></o:p> Все объект = 99; из класса, имеют значе = 85;ия атрибутов, соответствm= 1;ющие атрибутам и = 79; полного дескрипторk= 2; классов. Эти объекты будут также поддерживаm= 0;ь операции, оп= 080;сываемые дескрипторl= 6;м классов. Объек= ;ты являются экземпляраl= 4;и класса и сов= 084;естно используют свойства (ат= 088;ибуты и операции) данного класса. Каждый объе = 82;т отличается собственноl= 1; идентичносm= 0;ью и имеет характерныl= 1; набор значений дл= 03; атрибута. Он является су = 97;ностью, инкапсулирl= 6;ванной в двух воплощенияm= 3; = - состояния и поведения. Состояние представлеl= 5;о с помощью атрибутов и связей; опер= 072;ции и механизмы состояния представляn= 2;т поведение. Состояние сохраняет эффекты от производимm= 9;х некоей сущн = 86;стью операций. Диаграммы объектов отображают объекты, их ассоциации = 80; отношения (связи) в их развитии во времени. Объектом (если он подо&#= 1073;ен сущности) может быть:<o:p></o:p= > <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>м = 72;териальный предмет (или индивидуум);<o:= p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>в = 99;полняемая роль;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>с = 86;бытие;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>в = 79;аимодейств&#= 1080;е (контракт);<o:p></o:p></spa= n> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 87;ерационная процедура (о= 073;зор);<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 88;ганизацион&#= 1085;ая единица;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>м = 77;сто (банк);<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l235 level1 lfo133;tab-stops:13.2pt list 33.4pt;background:wh= ite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>с = 90;руктура.<o:p></o:p> Объект являетс= ;я экземпляроl= 4;, который структурирl= 6;ван и функциони = 88;ует в соответст = 74;ии со своим классом. Все объекты, пор= 086;жденные одним и тем же классом, структурирl= 6;ваны одним спосо = 73;ом, хотя каждый из них имеет свой собственныl= 1; набор связей атрибутов. = 050;аждая связь атриб = 91;та имеет ссылк = 91; на экземпля = 88;, обычно на значение данных. Объект може = 90; порождатьсn= 3; несколькимl= 0; классами. В этом случае объект обладает всеми свойствами, которые объ= 03;влены во всех этих классах, как структурныl= 4;и, так и поведенчесl= 2;ими. К объекту можно добав = 83;ять новые класс = 99;, а старые классы отделять. Эт= 086; значит, что свойства но = 74;ых классов динамическl= 0; добавляютсn= 3; к данному объекту, а свойства, об= 098;явленные ранее в классе, удаляемые и = 79; объекта, динамическl= 0; также удаляются и = 79; объекта.<o:p></o:p> Интерфейс = 86;м называетсn= 3; набор операций, характеризm= 1;ющих поведение элемента. Интерфейсы можно использоваm= 0;ь для установ = 82;и атрибута, возвращениn= 3; значения ат = 88;ибута и для запрос= 072; объекта с целью выпол = 85;ения операции. Важной частью любого проц = 77;сса ООП являетс= 03; специфицирl= 6;вание интерфейсоk= 4; между различными = 82;омпонентам&#= 1080; системы. Инт= 077;рфейсы необходимо определять так, чтобы объекты и другие компоненты можно было проектировk= 2;ть параллельнl= 6;. Определив интерфейс, разработчиl= 2;и других объектов могут считать, что &#= 1080;нтерфейс уже реализо = 74;ан. Один и тот же объект може = 90; иметь неско = 83;ько интерфейсоk= 4;, причем кажд = 99;й из них предполагаk= 7;т свой способ поддержки методов. Проектировk= 2;ние интерфейсоk= 4; объектов связано со спецификацl= 0;ей интерфейса = 74; объекте или группе объе = 82;тов. Интерфейсm= 9; можно определить подобно диаграмме классов. По м&#= 1077;ре усложнения интерфейсоk= 4; такой подхо = 76; оказываетсn= 3; более эффективныl= 4;, так как для о&#= 1073;наружения ошибок и противоречl= 0;й в описании интерфейса можно воспользовk= 2;ться средствами проверки синтаксиса языка прогр = 72;ммирования. <o:p></o:p> </spa= n>Сообщен= ;ия - содержат объект назначения (включающий = 086;перацию, предназначk= 7;нную для выполнения), название выполняемоk= 5;о оператора и параметры, которые нео = 73;ходимы для выполнения операции. Эт= 080; интерфейсы определяют средства взаимодейсm= 0;вия между объектами. Каждому объекту пересылаютl= 9;я сообщения других объектов. Интерфейсы относятся к общедоступl= 5;ым методам, поскольку о = 85;и имеют отношение к другим объектам. Полезно определять = 80;нтерфейсы заранее, т.е. в= начале жизненного цикла ПС. В этом случае команда про = 75;раммистов может быть р= 072;зделена с учетом границ межд = 91; объектами, что может быть предпочтитk= 7;льнее разделения по функционалn= 0;ным границам. После того, как интерфе = 81;сы и набор ответственl= 5;остей четко опред = 77;лены, они могут функционирl= 6;вать независимо, объединяясn= 0; лишь поздне = 77;, в цикле по тестированl= 0;ю модели.<o:p></o:p> Сообщение </sp= an>являетс= ;я спецификацl= 0;ей по транспортиl= 8;овке информации из одного экземпляра объекта в др= 091;гой, причем ожидается, что эта деятельносm= 0;ь имеет резул= 00;тат (сообщение может указывать н = 72; формированl= 0;е сигнала или на вызов операции). Стиму= 083; определяе= т передачу ин = 92;ормации из одного экземпляра объекта в др= 091;гой, например, фо= 088;мирование сигнала или вызов операции; получение с = 86;общения означает обработку стимула, который передается из экземпля = 88;а отправителn= 3;. Получ= 072;тель (объект) является объектом дл= 03; обработки стимула, который передается из экземпля = 88;а отправителn= 3;. Отнош= 077;ние представлn= 3;ет семантичесl= 2;ую связь между элементами модели (примеры отношений включают ассоциации = 80; обобщения). Ответ= 089;твенность является контрактом или обязательсm= 0;вом создателя классов; для пересылки сообщения стимул передается из экземпля = 88;а объекта отправителn= 3; к экземпляр = 91; получателя. <sp= an style=3D'mso-bidi-font-style:italic'>Отпра= 074;итель (объект) представляk= 7;т собой объек = 90;, передающий стимул в объект полу = 95;ателя.<o:p></o:p> </sp= an> Атриб= ут представляk= 7;т собой описа = 85;ие набора значений, ко= 090;орые могут вызыв = 72;ться экземпляраl= 4;и объектов данного кла = 89;са. Эта информа = 94;ия является дл= 03; объекта внутренней = 80; имеет следующие особенностl= 0;:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>п = 88;едставлени&#= 1077; с помощью существитеl= 3;ьного;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 87;исание объекта в терминах реального в = 88;емени;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>в = 86;зможность, служить индикатороl= 4; состояния;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-indent:35.45pt;mso-pagin= ation: none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3pt;background:w= hite; mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]>- = &nb= sp; <![endif]>о = 73;ладание типом данны = 93;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 76;ентичность для объекто = 74; одного класса -</span= > может отличаться по значению, но не по сути;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l158 level1 lfo128;tab-stops:14.65pt list 21.3= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зможность получения значения, определеннl= 6;го с помощью домена пересчета (набор опред= 077;ленных значений).<o:p></o:p></span= > Операция представляk= 7;т собой услуг = 91;, которая может запра = 96;иваться из объекта для оказани= 03; влияния на е= 075;о поведение. Операции можно описывать с = 86;гласно следующим параметрам:<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>инкапсули&#= 1088;ование внутри объекта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 90;клик на стимул (сообщение);<o:p></o:= p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зможность действия, выполняемоk= 5;о объектом с помощью другого объекта;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l241 level1 lfo134;tab-stops:14.65pt list 32.9= pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>в = 86;зможность преобразовk= 2;ния, которому по = 76;вергается объект.<o:p></o:p> Метод является специфичесl= 2;ой реализациеl= 1; операции. Оп= 077;рация (метод) являе&#= 1090;ся средством, с помощью которого объект може = 90; реализоватn= 0; свою ответс = 90;венность. Операция дл= 03; объекта вызывается = 89; помощью соо = 73;щения, пересылаемl= 6;го из другого объекта. Все объекты имеют метод = 99;, применяемыk= 7; для их инициализаm= 4;ии и выявления = 074; рамках моде = 83;и, а также возможностl= 0; для приобретенl= 0;я атрибутов и избавления от них. Метод&#= 1099; представляn= 2;т собой способы вза = 80;модействия объектов между собой, сообщений для вызова (стимулиров = 72;ния) определеннl= 6;й деятельносm= 0;и (поведения) в пределах объекта пол = 91;чателя. В ходе прове= 076;ения анализа для этого к каждому объекту, имеющему ссылку на другие объекты, доб= 072;вляется внешний клю = 95;. Мето = 76; представl= 3;яет реализацию для операци = 80; - указывает алгоритм ил = 80; процедуру, которая ассоциируеm= 0;ся с операцией. <o= :p></o:p> Ассоциациn= 3; отражает важное= соединениk= 7; (связь) между понятиями или классам = 80; (объектами). Рассматривk= 2;емое понятие включает, по крайней мер = 77;, два ассоциа = 90;ивных конца. Свойство множественl= 5;ости для концов ассоциации показывает, = 082;акое число экземпляроk= 4; объектов можно ассоц = 80;ировать с отдельным = 101;кземпляром класса.<o:p></o:p> Процесс инкапсуляцl= 0;и состоит из отделения внешних аспектов объекта от п= 086;следствий внутренней реализации этого объек = 90;а. Другим термином инкапсуляцl= 0;и является сокрыти= 077; информации. </s= pan>Внешние аспекты объекта доступны другим объектами с помощью методов самого объе = 82;та, в то время как внутренние реализации этих методо = 74; скрыты от внешнего объекта, пересылающk= 7;го сообщения. Инкапсуляцl= 0;я важна для получения потенциала или для поддержки объектно-ор = 80;ентированн&#= 1099;х моделей. Поскольку подробностl= 0; реализации скрыты от других объектов, он= 080; содержатся = 74; пределах объекта. Влияние изм = 77;нений, вносимых в р= 077;ализацию метода минимально для всей мод= 077;ли. <o:p></o:p> Потен= циально все объекты являются повторно используемm= 9;ми компонентаl= 4;и, так как они независимо инкапсулирm= 1;ют данные о состоянии и операции. Ар= 093;итектуру ПС можно разрабатывk= 2;ть на базе объе= 082;тов, уже созданн = 99;х в предыдущи = 93; проектах. Такой подхо = 76; снижает стоимость проектировk= 2;ния, программирl= 6;вания и тестированl= 0;я ПС. Кроме того, появля= 077;тся возможностn= 0; использоваm= 0;ь стандартныk= 7; объекты, что уменьшает риск, связан= 085;ый с разработкоl= 1; программноk= 5;о средства. Однако иногда повторное использоваl= 5;ие эффективнеk= 7; всего реализоватn= 0; с помощью коллекций о = 73;ъектов (компоненто = 74; или объектн = 99;х структур), а не через отдельные объекты. <o:p></o:p> </= span> Н = 72;следование определяет совместное использоваl= 5;ие атрибутов и поведение объектов в пределах иерархичесl= 2;ой структуры (с= 091;перклассов и/или подкла= 089;сов). Каждый подкласс наследует все свойств = 72; <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic'>- (атрибуты и операции) суперклассk= 2; (предка) и добавляет свои собств = 77;нные уникальные свойства. К= 083;асс содержит описание всех атрибутов, ассоциаций = 80; операций, входящих в объект, что является обобщением объекта. Каждый клас = 89; имеет набор наследуемыm= 3; свойств = - атрибутов, операций и ассоциаций. Эти структу = 88;ы данных и алг= 086;ритмы немедленно становятся доступными = 76;ля подклассов наследникоk= 4;. Класс может иметь потомков (подклассы), где потомок является специализаm= 4;ией предшествеl= 5;ника. Потомок наследует (включает в с&#= 1077;бя эту структуру и поведение общих предш = 77;ственников), при этом он способен добавлять свои собственныk= 7; атрибуты и операции. Та= 082;ое отношение также известно ка = 82; обобщение (генерализа = 94;ия). Наследованl= 0;е/специализ&#= 1072;ция/обобщен= ;ие является пр = 77;имуществом метода ООП, поскольку поддерживаk= 7;т повторное использоваl= 5;ие классов. Бла= 075;одаря применению этих поняти = 81; свойства суперклассl= 6;в повторяютсn= 3; в каждом объекте подкласса, и таким образом под = 76;ерживается высокий фактор обно = 74;ления. Изменения для атрибут = 86;в или операци = 81; немедленно наследуютсn= 3; всеми подклассамl= 0;. <o:p></o:p> &n= bsp; Модели систем, разрабатывk= 2;емые при формированl= 0;и требований, должны отоб = 88;ажать реальные сущности, принадлежаm= 7;ие классам объ = 77;ктов. Все объекты связаны с ра= 079;личными уровнями в архитектурk= 7; системы. Конкретные решения по а= 088;хитектуре системы можно принимать в процессе её реализации. Когда связи между разработчиl= 2;ами требований, проектировm= 7;иками и программисm= 0;ами не очень тес= 085;ые (например, если систем = 72; проектируеm= 0;ся в одном подразделеl= 5;ии предприятиn= 3;, а реализуетсn= 3; в другом), требуется более детализироk= 4;анная модель. Следователn= 0;но, в процессе п= 088;оектирован&= #1080;я важно решит= 00;, какие требуются модели, и какой должн = 72; быть степен= 00; их детализациl= 0;. Это решение зависит также от тип= 072; разрабатывk= 2;емой системы. <o:p></o:p> &n= bsp; Классы не должны содержать информацию об отдельны = 93; системных объектах. Можно разработатn= 0; различные т = 80;пы объектных моделей, показывающl= 0;е, как классы с= 074;язаны друг с другом, как объекты = 72;грегируютс&#= 1103; из других объектов, ка= 082; объекты взаимодейсm= 0;вуют с другими объектами. Эти модели расширяют понимание разрабатывk= 2;емой системы. Иде= 085;тификация объектов и классов объ = 77;ктов считается наиболее сложной зад = 72;чей в процессе объектно-ор = 80;ентированн&#= 1086;й разработки систем. Определениk= 7; объектов = - это осн = 86;ва для анализа = 080; проектировk= 2;ния системы. <o:p></o:p> Модель окружения системы и модель использоваl= 5;ия системы представляn= 2;т собой две до= 087;олняющие друг друга модели взаимоотноm= 6;ений между данно = 81; системой и е= 105; окружением. = 052;одель окружения системы = - это статическаn= 3; модель, которая описывает другие системы из окружения разрабатывk= 2;емого ПС. Модель использоваl= 5;ия системы = - динамиm= 5;еская модель, кото= 088;ая показывает взаимодейсm= 0;вие данной сист = 77;мы со своим окр= 091;жением. Модель окружения системы можно предс = 90;авить с помощью схемы связе = 81;, которая дае = 90; простую блок-схему общей архитектурm= 9; системы. С помощью пакетов я= 079;ыка UML её можн = 86; представитn= 0; в развернут = 86;м виде как совокупносm= 0;ь подсистем. Такое представлеl= 5;ие показывает, что рабочее окружение системы находится внутри подсистемы, занимающейl= 9;я сбором данных. При моделироваl= 5;ии взаимодейсm= 0;вия проектируеl= 4;ой системы с её окружением при ООП применяетсn= 3; абстрактныl= 1; подход, который не требует больших объемов дан = 85;ых для описани= 03; этих взаимо = 76;ействий. Подход, применяемыl= 1; в UML, состои = 90; в том, чтобы разработатn= 0; модель вари = 72;нтов использоваl= 5;ия, в которой каждый вариант пре = 76;ставляет собой определеннl= 6;е взаимодейсm= 0;вие с системой. <o:p></o:= p> Объек= тные модели, разработанl= 5;ые для формиро = 74;ания требований, могут использоваm= 0;ься как для представлеl= 5;ия данных, так и &= #1076;ля процессов и = 93; обработки. В этом отноше = 85;ии они объединяют модели потоков дан = 85;ых и семантичесl= 2;ие модели данных. Они также полезны для классификаm= 4;ии системных сущностей и = 084;огут представляm= 0;ь сущности, состоящие и = 79; других сущностей. Для некоторых классов сис = 90;ем объектные модели <span style=3D'font-size:= 14.0pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";mso-char-type:symbol;mso-symbol-font-family:Symbol; mso-bidi-font-style:italic'>- ес = 90;ественный способ отображениn= 3; реально сущ = 77;ствующих объектов, которые находятся под управле = 85;ием системы. Например, дл= 103; систем, обрабатываn= 2;щих информацию относительl= 5;о конкретных объектов (таких, как автомобили, самолеты, книги), котор&#= 1099;е имеют четко определеннm= 9;е атрибуты. Более абстрактныk= 7; высокоуровl= 5;евые сущности (например, библиотеки, медицинскиk= 7; регистрируn= 2;щие системы или текстовые редакторы) труднее мод = 77;лировать в виде классов объектов, поскольку о = 85;и имеют достаточно сложный инт = 77;рфейс, состоящий и = 79; независимыm= 3; атрибутов и = 084;етодов.<o:p></o:p> Объектные модели, разработанl= 5;ые во время анализа требований, упрощают пе = 88;еход к объектно-о= 088;иентирован&= #1085;ому проектировk= 2;нию и программи = 88;ованию. Однако коне = 95;ные пользоватеl= 3;и часто считают объектные модели неестествеl= 5;ными и трудными д= 083;я понимания. Часто они предпочитаn= 2;т функционалn= 0;ные представлеl= 5;ия процессов обработки данных. Поэт= 086;му полезно дополнить и = 93; моделями потоков данных, чтоб= 099; показать сквозную обработку данных в системе.<o:p></o:p> Модели данных -</span= > больших программныm= 3; систем используют = 80;нформацион&#= 1085;ые базы данных. В одних случаях эта база данных = 089;уществует независимо от программноl= 1; системы, в других <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic'>- специально создается для разрабатывk= 2;емой системы. Важной частью моделироваl= 5;ия систем является определениk= 7; логической формы данны = 93;, обрабатываk= 7;мых системой. Наиболее широко используемl= 6;й методологиk= 7;й моделироваl= 5;ия данных явля = 77;тся моделироваl= 5;ие типа "сущность = - = 89;вязь - атрибут", которое показывает структуру д = 72;нных, их атрибуты = 080; отношения между ними. <o= :p></o:p> Д&= #1083;я описания структуры обрабатываk= 7;мой информации модели данн = 99;х часто испол= 00;зуются совместно с моделями потоков дан = 85;ых. Проекты структуры П = 57; представляn= 2;тся ориентировk= 2;нными графами. Они состоят из набора узло = 74; различных типов, соеди= 085;енных дугами, отображающl= 0;ми связи между структурныl= 4;и узлами. В системе проектировk= 2;ния присутствуn= 2;т средства вывода на дисплей этого графа (т.е. структурноl= 1; диаграммы) и его преобразовk= 2;ния к виду, удобному дл= 03; хранения в базе данных проектов. Система редактировk= 2;ния выполняет преобразовk= 2;ния струк= ;турной диаграммы и = 79; формата баз = 99; данных в фор= 084;ат, позволяющиl= 1; отобразить её на экране монитора в виде блок-сх= 077;мы. Информация, предоставлn= 3;емая редактором другим средствам анализа проекта, дол= 078;на включить ло = 75;ическое представлеl= 5;ие графа проекта. Эти средства работают с объектами, и= 093; логическимl= 0; атрибутами = 80; связями меж = 76;у ними.<o:p></o:p> С&= #1091;щность <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-style:italic'>-</span= > реальный ил = 80; абстрактныl= 1; объект, имеющий опр = 77;деляющее значение дл= 03; рассматривk= 2;емой системы (это может быть объект, как самой систе = 84;ы, так и её окру&#= 1078;ения). Каждая сущность должна имет= 00; уникальное имя и обладать одним или несколькимl= 0; атрибутами, которые либ = 86; принадлежаm= 0; сущности, либо наследуютсn= 3; через связь. Сущность соответствm= 1;ет классу (или типу) объектов, а не конкретн = 86;му экземпляру класса. Поим= 077;нованная связь (ассоциация) между двумя сущностями осуществляk= 7;тся с помощью гл= 072;голов (например, имеет, определяет, принадлежиm= 0;). Атри = 73;ут = - любая характерисm= 0;ика сущности (предназнач = 72;ется для идентиф = 80;кации, классификаm= 4;ии, численной параметризk= 2;ции или описани= 03; состояния сущности). Значения атрибутов однозначно идентифициl= 8;уют экземпляр сущности. <o:p></o:p> Я&= #1079;ык моделироваl= 5;ия UML не имеет определеннm= 9;х обозначениl= 1; для типа моделей данных, что желательно для объектно-ор = 80;ентированн&#= 1086;го процесса ра = 79;работки ПС, где для описания систем используютl= 9;я объекты и их отношения. Если сущностям поставить в = 089;оответстви&= #1077; простейшие классы объектов (бе= 079; ассоциировk= 2;нных методов), тогда в качестве мо = 76;елей данных можн = 86; использоваm= 0;ь модели клас = 89;ов UML совместно с именованн = 99;ми ассоциацияl= 4;и между класс = 72;ми. <o:p></o:p> Модели наследованl= 0;я. Важны= м этапом объектно-ор = 80;ентированн&#= 1086;го моделироваl= 5;ия является определениk= 7; классов объ = 77;ктов, которые затем систематизl= 0;руются. Это подразу = 84;евает создание схемы классификаm= 4;ии, которая показывает, как классы объектов св= 03;заны друг с друго= 084; посредствоl= 4; общих атрибутов и сервисов. Схема класс = 80;фикации организоваl= 5;а в виде иерархии наследованl= 0;я, на вершине которой пре = 76;ставлены наиболее об = 97;ие классы объектов. Более специ = 72;лизированн&#= 1099;е объекты наследуют и = 93; атрибуты и сервисы. Эти объекты могут иметь собственныk= 7; атрибуты и сервисы. В нотации UML наследl= 6;вания показываютl= 9;я сверху-вниз, как принято = 074; других объектно-ор = 80;ентированн&#= 1099;х нотациях. Стрелка выходит из класса, который наследует атрибуты и операции, и направлена = 82; родительскl= 6;му классу. В UML вместо термина "наследован= ;ие" чаще используетl= 9;я термин "обобщение". В моделях мн= 086;жественног&= #1086; наследованl= 0;я классы могу = 90; иметь нескольких родителей. Тогда насле = 76;уются атрибуты и сервисы от каждого родительскl= 6;го класса. <o:p></o:p> Упрощения моделей при ООП может вызывать некоторые затруднениn= 3; специалистl= 6;в в понимании следующего:<o:p= ></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l34 level1 lfo136;tab-stops:14.2pt list 25.1pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>о = 76;ни и те же динамическl= 0;е и статическиk= 7; модели опис = 99;вают в разработк = 77; только "споl= 9;обы" взаимодейсm= 0;вия с объектами;<o:= p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l34 level1 lfo136;tab-stops:14.2pt list 25.1pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>и = 85;капсуляция скрывает внутреннее содержание объекта, поз= 074;оляя разработчиl= 2;у уделять больше вним = 72;ния методам использоваl= 5;ия объектов = - их суще = 89;твенных, неотъемлемm= 9;х характерисm= 0;ик; позволяет разделять статус, функцию, пов= 077;дение; ограничиваk= 7;т доступ к переменным, которые функционирm= 1;ют внутри алго = 88;итма;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l34 level1 lfo136;tab-stops:14.2pt list 25.1pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>а = 75;регация позволяет создавать крупный объ = 77;кт из небольши = 93;, упрощать вид объекто = 74;, позволяя выполнять обработку сложных состояний. <o:p></o:p= > <o:p> </o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102478"></a><a name=3D"_Toc508102251">8.3. Варианты представлеl= 5;ия моделей и ср= 077;дства объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния программныm= 3; средств</a> </h1> <o:p> </o:p> Сущес= твует два типа объектно-ор = 80;ентированн&#= 1099;х моделей сис = 90;емной архитектурm= 9;:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l45 level1 lfo131;tab-stops:14.2pt list 49.0pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>статиче= ;ские модели, которые описывают с = 90;руктуру системы в терминах классов объектов и взаимоотноm= 6;ений между ними, которые док = 91;ментируютс&#= 1103; на данном этапе, являю= 090;ся отношениямl= 0; обобщения, о= 090;ношениями "использ= уют - используютl= 9;я" и структурн = 99;ми отношениямl= 0;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l45 level1 lfo131;tab-stops:14.2pt list 49.0pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>динамич= ;еские модели, которые описывают с = 90;руктуру системы и показывают динамическl= 0;е взаимодейсm= 0;вия между объектами системы (но не классами объектов), = - докумеl= 5;тируемые взаимодейl= 9;твия соде= ржат последоваm= 0;ельность соста= ;вленных объектами з = 72;просов к сервисам и описывают реакцию системы на взаимодейсm= 0;вия между объек = 90;ами.<o:p></o:p> В языке моделироваl= 5;ия UML поддерживаk= 7;тся ряд возможн = 99;х статическиm= 3; и динамичес = 82;их моделей: <o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l10 level1 lfo132;tab-stops:14.2pt list 51.4pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>м = 86;дели подсистем, которые показывают логически сгруппировk= 2;нные объекты, они представлеl= 5;ы с помощью диаграммы классов, в ко&#= 1090;орой каждая подс = 80;стема обозначаетl= 9;я как пакет, и является статическиl= 4;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l10 level1 lfo132;tab-stops:14.2pt list 51.4pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>м = 86;дели последоватk= 7;льностей, которые показывают = 74;заимодейст&#= 1074;ия между объек = 90;ами, они представляn= 2;тся в UML с помощью диаграмм последоватk= 7;льности или коопера = 90;ивных диаграмм = - динамиm= 5;еские модели;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l10 level1 lfo132;tab-stops:14.2pt list 51.4pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = <![endif]>м = 86;дели конечного автомата, которые показывают изменение с = 86;стояния отдельных о = 73;ъектов в ответ на определеннm= 9;е события, в UML<= span style=3D'font-size:14.0pt'> они представлеl= 5;ы в виде диаграмм со = 89;тояния - динамическl= 0;е модели.<o:p></o:p> Модель подсистемы является од = 85;ой из наиболее важных и пол= 077;зных статическиm= 3; моделей, поскольку показывает, как можно организоваm= 0;ь систему в виде логически связанных групп объек = 90;ов. В UML пакеты являются структурамl= 0; инкапсуляцl= 0;и и не отображ= 072;ются непосредстk= 4;енно в объектах разрабатывk= 2;емой системы. Существует несколько способов со = 79;дания, применения = 80; введения новых опред = 77;лений для моделей ООП с исполь= 079;ованием диаграмм вариантов использоваl= 5;ия сценариев, д= 080;аграмм действий, ди= 072;грамм класс / объект, а также диаграмм сотрудничеl= 9;тва, взаимодейсm= 0;вия, перехода состояния, контекста данных и сло= 074;аря данных. Некоторые вводятся сверху-вниз,<sp= an style=3D'mso-spacerun:yes'> другие = - снизу-в = 74;ерх, и все они итеративно определяютl= 9;я заново с помощью сотрудничеl= 9;тва. <o:p></o:p> Статическl= 6;е представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;го анализа <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-weight:bold'>- представля= ;ет собой диаграмму класса, а так&#= 1078;е диаграмму объекта для представлеl= 5;ия определеннl= 6;го экземпляра класса, куда входят комп = 86;ненты атрибутов, служб и отношений наряду с понятиями, взятыми из иерархии, абстракции, инкапсуляцl= 0;и и наследованl= 0;я. Идентифициl= 8;уются ответственl= 5;ости классов, затем обработка идет наверх, а для достоверноl= 9;ти применяютсn= 3; сценарии вариантов использоваl= 5;ия. В этом случа= 077; реализуетсn= 3; подход снизу-вверх.<sp= an style=3D'mso-spacerun:yes'> Подоб= ;ный способ достаточно хорош, но сущ&#= 1077;ствует еще путь сверху-вниз,<sp= an style=3D'mso-spacerun:yes'> когда при идентиф = 80;кации классов начинают с практическl= 0;х примеров, а затем продолжаетl= 9;я обработка вниз, доходя до сценарие = 74;. Если начать = 089; классов можно сначала иде = 85;тифицирова&#= 1090;ь их через абстракции. Затем для каждого = 082;ласса перечисляюm= 0;ся ответственl= 5;ости, идентифициl= 8;уются атрибуты и операции (поведение <sp= an style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - снова через абстр = 72;кцию) и, наконец, обращаются = 82; сценариям вариантов и = 89;пользовани&#= 1103; для подтверждеl= 5;ия диаграммы класса. Однако сначала рас = 89;матриваетс&#= 1103; описание диаграмм кл = 72;ссов.<o:p></o:p> Статическl= 6;е представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;й разработки проекта = - k= 6;иаграммы взаимодейсm= 0;вия и сотрудничеl= 9;тва - отобр= ;ажают взаимодейсm= 0;вия, которые пространстk= 4;енно ориентировk= 2;ны на окружени = 77; модели и характеризm= 1;ют классы и асс= 086;циации (экземпляры = 080; связи). Целью сотрудничеl= 9;тва является определениk= 7; способов реализации вариантов использоваl= 5;ия. Диаграмма сотрудничеl= 9;тва отображает отношения между экземпляраl= 4;и объектов. Поведение р = 77;ализуется с помощью набора объектов, обменивающl= 0;хся входными сигналами в рамках общего взаи = 84;одействия, что позволяет достичь пос = 90;авленной цели. Для представлеl= 5;ия механизмов, применяемыm= 3; при разработке, = 074;ажно обращать вн = 80;мание только на определеннm= 9;е объекты и из= 091;чать взаимодейсm= 0;вие между ним. Ра&#= 1089;сматриваем= ые объекты всегда выделяются = 80;з большей системы, в которой данные объекты являются лишь компон = 77;нтами.<o:p></o:p> Сотрудничk= 7;ство уточняет ко = 85;текст, который позволяет в = 99;разить поведение р = 77;ализуемого элемента в терминах, единых для в= 089;ех участников сотрудничеl= 9;тва. Таким образ = 86;м, в то время как модель представляk= 7;т систему в целом, сотрудничеl= 9;тво является ли = 96;ь частичным отображениk= 7;м данной модели. Имен= 085;о сотрудничеl= 9;тво определяет = 01;ффективнос&#= 1090;ь применения подмножестk= 4;а содержимогl= 6; модели. Сотрудничеl= 9;тво можно охара = 82;теризовать на двух различных уровнях: на уровне спецификацl= 0;и или на уровн= 077; экземпляра. Диаграмма, представляn= 2;щая сотрудничеl= 9;тво на уровне спецификацl= 0;и, характеризm= 1;ет роль классо = 74; и ассоциаци = 81;. В то же время диаграмма н = 72; уровне экземпляра отображает = 01;кземпляры и связи, которые сог = 83;асуются с ролями в сотрудничеl= 9;тве. При отображ = 77;нии сотрудничеl= 9;тва указываетсn= 3;, какие экземпляры свойств должны принимать участие в со= 090;рудничеств&= #1077;, т.е. каждый участник указывает необходимыk= 7; свойства, ко= 090;орыми должен обла = 76;ать согласуемыl= 1; экземпляр.<o:p></o:p>= Динамичесl= 2;ое представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;го проектировk= 2;ния - диаграммы взаимодейсm= 0;вия и последоватk= 7;льные диаграммы </sp= an>= - демонст= ;рируют взаимодейсm= 0;вие, отображеннl= 6;е в динамике. В ней отображ = 72;ются экземпляры, участвующиk= 7; во взаимоде = 81;ствии с помощью соответствm= 1;ющих линий жизни, а также входные сиг = 85;алы, которыми он = 80; обмениваютl= 9;я. Эти сигналы собраны во временную п = 86;следовател&#= 1100;ность. В отличие от диаграммы сотрудничеl= 9;тва, последоватk= 7;льная диаграмма включает временные последоватk= 7;льности, но не содержит объектных отношений. П= 086;следовател&= #1100;ная диаграмма может сущес = 90;вовать в общей форм= 077; (описывать все возможные сценарии) и в форме экзем = 87;ляра (описывать один действ = 80;тельный сценарий). Последоватk= 7;льные диаграммы и диаграммы с = 86;трудничест&#= 1074;а выражают подобную информацию, однако, используют различные способы. Последоватk= 7;льная диаграмма имеет две размерностl= 0;: размерностn= 0; по вертикал = 80; представляk= 7;т время; размерностn= 0; по горизонт = 72;ли представляk= 7;т различные объекты. <o:p></o:p> Динамичесl= 2;ое представлеl= 5;ие объектно-ор = 80;ентированн&#= 1086;й разработки проекта = - диаграммы переходов между состояниямl= 0; = - представлn= 3;ют, основанное на состояни = 80;, поведение класса экземпляроk= 4; объектов дл= 03; всех сценар = 80;ев. Обычно моделируютl= 9;я лишь классы = 089; объектами, к= 086;торые, как ожидается, проходят через набор = 99; состояний. Состо= 103;ние представлn= 3;ет условие или ситуацию во время жизни объекта, при которой удо = 74;летворяетс&#= 1103; определеннl= 6;е условие, реа= 083;изуется некоторая д = 77;ятельность или же ожидается какое-либо событие. Диаграмма состояния = 86;тображает механизм состояния = - поведение, определяющk= 7;е последоватk= 7;льности состояния, которые проходит объект или взаимодейсm= 0;вие во время своей жизни при отклике на события, вместе с соответствm= 1;ющими откликами и действиями.<o:p= ></o:p> Механизм состояния определяет набор понятий, которые могут использоваm= 0;ься для моделироваl= 5;ия дискретногl= 6; поведения с помощью кон = 77;чных систем переходных = 89;остояний. Экземпляры событий генерируютl= 9;я в результат = 77; определеннl= 6;го действия в п= 088;еделах системы или её окружени= 03;. Затем событие ори = 77;нтируется на одну или несколько ц = 77;лей. Средства, с помощью которых экземпляры событий транспортиl= 8;уются к месту назн= 072;чения, зависят от типа действия, це= 083;и, свойств среды коммуникацl= 0;и и многих других факт = 86;ров. В некоторых случаях это происходит = 87;рактически мгновенно и вполне надежно, в то время как в других случаях могут происходитn= 0; периодичесl= 2;ие задержки передачи, по= 090;еря событий, переупорядl= 6;чивание или дублированl= 0;е. Поддерживаk= 7;тся полная гибк = 86;сть при моделир = 86;вании различных типов коммуникацl= 0;онных возможностk= 7;й. Событие получено, &#= 1077;сли оно размещено в очереди событий по ц= 077;левому назначению. Событие отправлен = 86;, если оно извлечено и = 79; очереди событий и до= 089;тавлено к механизму состояния для обработ = 82;и. С этой точки зрения на не= 075;о ссылаются как на текущее событие. На= 082;онец, событие поглощено, </= span>если завершена его обработка. Поглощенноk= 7; событие ста = 85;овится недоступныl= 4; для обработки. Никакие тре = 73;ования не предъявляюm= 0;ся к интервала = 84; времени между получ = 77;нием события, отправлениk= 7;м и поглощениеl= 4;. <o:p></o:p> Состояние становится актив= 085;ым, если оно вводится ка = 82; результат некоторого перехода, а неакт= 080;вным, если завершаетсn= 3; как результат перехода. Со= 089;тояние может быть завершено и начато как р= 077;зультат одного и тог= 086; же перехода. Диаграммы состояния представляn= 2;т объекты, способных к динамическl= 6;му поведению, путем указания соответствm= 1;ющего отклика на получение экземпляроk= 4; события. Обычно они применяютсn= 3; при описани = 80; поведения классов. Сос= 090;ояние представляk= 7;т собой условие во время жизни объекта или взаимодейсm= 0;вие, во время которого он = 86; удовлетворn= 3;ет некоторое условие, выполняет определеннl= 6;е действие ил = 80; ожидает некоторое событие. Кон= 094;ептуально объект остается в состоянии в = 86; время некоторого = 80;нтервала времени. <o:p></o:p> Инструменm= 0;альные средства анализа и проектировk= 2;ния ПС созданы для поддерж = 82;и моделироваl= 5;ия систем на этапах жизн = 77;нного цикла программнm= 9;х средств. Они поддерживаn= 2;т создание, редактировk= 2;ние и анализ графическиm= 3; нотаций, используемm= 9;х в структурныm= 3; методах. Инс= 090;рументальн&= #1099;е средства анализа и проектировk= 2;ния часто подде = 88;живают только определеннm= 9;е методы прое = 82;тирования и анализа, например об = 98;ектно-ориен&= #1090;ированные. Другие инструментk= 2;льные средства являются универсальl= 5;ыми системами редактировk= 2;ния диаграмм многих типо = 74;, которые используютl= 9;я разными методами пр = 86;ектировани&#= 1103; и анализа. Ин&#= 1089;трументаль= ные средства, ориентировk= 2;нные на определе = 85;ные методы, обычно автоматичеl= 9;ки поддерживаn= 2;т правила и базовые принципы этих методо = 74;, что позволя = 77;т выполнять автоматичеl= 9;кий контроль ди = 72;грамм.<o:p></o:p> Инструменm= 0;альные средства об = 99;чно объединяютl= 9;я через общий ре= ;позиторий, стру = 82;тура которого является собственноl= 9;тью разработчиl= 2;а пакета инст = 88;ументальны&#= 1093; средств. Центральн = 99;й репозитl= 6;рий позволяет проектировm= 7;ику найти нужны = 81; проект, компонент и соответствm= 1;ющую проектную информацию. = 054;бычно для создани= 03; общего р = 77;позитория инструментl= 6;в используютl= 9;я системы баз данных типа </s= pan>Sybase</spa= n> или Oracle. Эти пакеты инструментk= 2;льных средств сод = 77;ржат большое количество средств языков программирl= 6;вания четвертого поколения, предназначk= 7;нных для генерироваl= 5;ия программноk= 5;о кода на основе сист = 77;мной архитектурm= 9;, они также могут генер = 80;ровать базы данных. Пакеты инструментk= 2;льных средств обычно закрыты, т.е. не рассчита = 85;ы на добавлениk= 7; пользоватеl= 3;ями собственныm= 3; инструментl= 6;в или на измен= 077;ние средств пакета, в который входят:<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>редакторы диаграмм, предназ= ;наченные для создани= 03; диаграмм потоков дан = 85;ых, иерархий объектов, диаграмм "сущность-сk= 4;язь", эти редакто = 88;ы не только имеют средства рисования, н= 086; и поддерживаn= 2;т различные типы объект = 86;в, используемm= 9;х в диаграмма = 93;;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt list 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства проектировk= 2;ния, анализа и проверки выполня= ;ют проектировk= 2;ние ПС и создают отчеты об ошибках и дефектах в системной а = 88;хитектуре, они могут работать со = 74;местно с системой редактировk= 2;ния, поэтому обнаруженнm= 9;е ошибки можн = 86; устранять н = 72; ранней стадии процесса проектировk= 2;ния;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>словарь данных хранит информацию об объектах, которые исп = 86;льзуются в структуре системы;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства генерироваl= 5;ия отчетов на основе информации из централь = 85;ого репозитl= 6;рия автоматичеl= 9;ки генерируют системную документацl= 0;ю;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства создания форм определяют форматы документов = 80; экранных фо = 88;м;<o:p></o:p> <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>средства импортировk= 2;ния и экспортироk= 4;ания позво= ляют обмениватьl= 9;я информациеl= 1; из центральноk= 5;о репозитl= 6;рия различным инструментk= 2;льным средствам;<o:p></o:p>= <p class=3DMsoNormal style=3D'margin-left:0cm;text-align:justify;text-inden= t:35.45pt; mso-pagination:none;mso-list:l92 level1 lfo139;tab-stops:14.2pt 28.8pt list= 32.2pt; background:white;mso-layout-grid-align:none;text-autospace:none'><![if !sup= portLists]>- = &nb= sp; <![endif]>генератор = 99; программноk= 5;о кода а= ;втоматичес = 82;и генерируют программы н = 72; основе проектов компонентоk= 4;, хранящихся = 74; центральноl= 4; репозито = 88;ии.<o:p></o:p> В некоторых случаях возможно генерироваm= 0;ь программы и = 83;и фрагменты п = 88;ограмм на основе информации, представлеl= 5;ной в системной модели. Поск= 086;льку в моделях не предусмотрk= 7;на детализациn= 3; низкого уровня, генератор программноk= 5;о кода не в состоянии сгенерировk= 2;ть законченныl= 1; комплекс программ. Обычно необходимы программисm= 0;ы для заверше = 85;ия автоматичеl= 9;ки сгенерировk= 2;нных программ.<o:p></o:p>= <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102479"></a><a name=3D"_Toc508102252">Лекция 9. Управление ресурсами в жизненном цикле &= nbsp; программнm= 9;х средств</a></h1> <h1><a name=3D"_Toc508102480"></a><a name=3D"_Toc508102253">9.1. Основные ресурсы для обеспечениn= 3; жизне= ;нного цикла = &nb= sp; сложных программныm= 3; средств</a></h1> <o= :p></o:p> = Общее= понятие = - доступные ресурсы обеспечениn= 3; жизненного цикла ПС включает реальные финансовые, временные, кадровые и аппаратурнm= 9;е ограничениn= 3; затрат, в условиях которых происходит создание и с= 086;вершенство&= #1074;ание комплексов программ. В з&#= 1072;висимости от характерисm= 0;ик объекта разработки на её выполнение выделяются ресурсы раз = 83;ичных видов и разм= 077;ров. Эти факторы проявляютсn= 3; как дополни = 90;ельные характерисm= 0;ики процессов Ж = 62; и программныm= 3; продуктов, а также их рентабельнl= 6;сти, которые сле = 76;ует учитывать и оптимизироk= 4;ать. В результат = 77; доступные ресурсы становятся косвенными критериями или факторами, в= 083;ияющими на выбор методов разработки, на достигае = 84;ые качество и эффективноl= 9;ть применения программныm= 3; продуктов. М= 085;огие проекты систем терп = 77;ли и терпят неудачу из-з= 072; отсутствия = 91; разработчиl= 2;ов и заказчико = 74; при подготовке = 82;онтракта четкого представлеl= 5;ия о реальных финансовых, трудовых, временных и иных ресурсах, необходимыm= 3; для их реализации. Поэто= ;му одной из основных задач при проектировk= 2;нии ПС является экономичесl= 2;ий анализ и определениk= 7; необходимыm= 3; ресурсов для создания и обеспечениn= 3; всего ЖЦ ПС в соответствl= 0;и с требованияl= 4;и контракта и техническоk= 5;о задания. <o:p></o:p> Наиболее общим видом ресурсов, используемm= 9;х в жизненном цикле ПС, явл&#= 1103;ются допустимые финансово-э = 82;ономически&#= 1077; затраты или эквивалентl= 5;ые им величины = 090;рудоемкост&= #1080; соответствm= 1;ющих работ (см. лекцию 5). При разработке, тестированl= 0;и и анализе ка= 095;ества этот показа = 90;ель может применятьсn= 3; или как вид ресурсных ограничениl= 1;, или как опти= 084;изируемый критерий, определяющl= 0;й целесообраk= 9;ную функционалn= 0;ную пригодностn= 0; ПС. При этом необходимо также учитывать з = 72;траты на разработку, закупку и эксплуатацl= 0;ю системы качества, на технологию = 80; комплекс автоматизаm= 4;ии проектировk= 2;ния программ и баз данных, которые могут составлять существеннm= 1;ю часть совокупной стоимости и трудоемкосm= 0;и разработки = 80; всего ЖЦ ПС.<o:p></o:= p> Затраты = в ж= изненном цикле ПС опр= ;еделяются не только n= 1;та- пами разработки, </s= pan>но и этапами </spa= n>эксплуат= ;ации и сопровож= ;дения. За- траты= на этих этапах могут значител= ;ьно превы= шать затра= ты при разра= ботке и характеризm= 1;ются своим= и особы= ми закон= омерностямl= 0; . Однако э= ;ффек-тиk= 4;ность проце= сса разра= ботки ПС невозмож= ;но опред= елять без у= ;чета эm= 2;фек- тивно= сти после= дующей эксплуатацl= 0;и, а, для, долг= о модифици= ;руемых про грамм= , <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic;mso-no-proof:yes'>- бе&= #1079; оценки n= 1;ффектив= ;ности их соп= ;ровождения. Ряд ф= ;акто ров в= ;лияет l= 5;а затраты при р= ;азработ= ;ке сложн= ых ПС не </spa= n>только l= 5;е- посре= дственно, но и ч= ерез возмо= жное измен= ение затра= т в дальней- шем п= ;ри сопровождеl= 5;ии или эк= ;сплуатации.<sp= an style=3D'mso-spacerun:yes'> Каждый из этапов: разра= ботка, сопро= вождение и экспл= 091;ата- ция= <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol;mso-bidi-font-style:italic;mso-no-proof:yes'>- мо&= #1078;ет быть достаточно длите= льным. В пределах= ; этапов l= 8;аз- личны= е групп= ы затра= т могут быть н&= #1077;одновремен= ;ными и раз= ;делять- ся интервал= ;ами времени, исчисляемым= и годами. = 54;днако, = 88;азновремен&#= 1085;ость затра= т трудн= о учиты= вать в общем виде, и при су = 97;ествующих ме- тодик= ах, имеется некотора= ;я услов= ность при о= ;ценке влиянии- времени на совокупные </sp= an>затраты проекта. <o:p></o:p= > В соотв= ;етствии с этапами </spa= n>жизненно= ;го цикла ПС осн= ;овные за- траты= С S , снижающие ид&= #1077;альную эффек= тивность за цикл жизни t ж , = мо&= #1078;но пред-с= ;тавить с= ;ледующими составля= ;ющими (рис.9.1): <o:p></o:p> С Р — с= овокупные затра= ты на разработ= ;ку прогр= амм и обе= ;спече- ние решения заданных= ; функцион= ;альных задач= , в т= ом числе= на тех- нолог= ическое обеспечениk= 7; и а= ппаратуру ЭВМ при разра= ботке ПС, в течение </spa= n>времени </spa= n>t Р ; <o:p><= /o:p> &nb= sp; С С= </= span>— з= атраты на сопровож= ;дение ПС за </spa= n>время t с , вклю= чающие затра= ты на хранение и к= онтроль их состояни= ;я, прове= дение модер- низац= ий и исправле= ;ние ошибок, тиражиро= ;вание верси= й; <o:p></o:p> С Э — з= атраты на эксплуат= ;ацию прогр= амм и аппаратн= ;ые средст- ва ЭВ= ;М, реализующиm= 3; ПС, а = 90;акже совокупн= ;ые потер= и эффектив- ности= за время t Э , </s= pan>всле= 076;ствие ограниченны= х харак= теристик ЭВМ и= ; н е идеально = 89;ти п= рограмм. <o:p></o:p> В ре&= #1079;ультате совок= упные затраты ресурсов на программноk= 7; средство - за вес= ;ь жизне= нный цикл </span= >длительн= ;остью t = ж<= span style=3D'font-size:14.0pt;mso-bidi-font-style:italic'> мо&= #1078;но предс= тавить в виде суммы: С Р + С С + С Э . В зависимо= ;сти от назначен= ;ия и области </spa= n>использо= ;вания про- грамм экономичесl= 2;ую эффек= тивность целес= ообразно анализиро- вать </span= >интеграл= ;ьно за весь период жизни= , либо дифферен= ;циально за едини= цу време= ни (месяц= ;, год). Для &#= 1089;овместн= ;ого анали= за составл= ;я- ющих= , определяющи = 93; эффек= тивность, необходимl= 6; унифицир= ;овать метод= ы време= нного анали= за и единицы </spa= n>измерени= ;я составляющl= 0;х затра= т. При п= ;оследую= ;щем излож= ении затра= ты рассм= атриваются на длительн= ;ости цикла= жизни или на соо&= #1090;ветствующи= ;х интер= валах време= ни: разработкl= 0;, эксплуатаци= и и сопровож= ;дения . <o:p></o:p> Разработкk= 2; сл&= #1086;жного ПС тре= ;бует во мн= ;о- го раз болn= 0;ших з= атрат, чем п= ;роизвод= ;ство каждо= го экзем= пляра при массо= вом тиражироваl= 5;ии. Поэто= му далее= производ= ;ство базового образ= ца прогр= амм не выделяется </sp= an>в самосто-ят = 77;льный этап, </spa= n>а рас= ;- сматр= ивается с= овместно с процессом = 88;азработ= ;ки ПС. Производ= ;ство серий= ных образ= цов программноk= 5;о продукта включает= ;ся в этап= ; эксплуат= ;ации. Экономичеl= 9;кая- &n= bsp; эффе= ктивность разра= ботки и распре-деле = 85;ие ресур= сов на ее выпол= нение могут= значител= ;ьно измен= яться в зави-симост = 80; от того, являе= тся ПС уни= ;кальным или б= ;удет изготовл= ;ен в сотнях n= 1;кземпля- ров= . Это обст&= #1086;ятельство приве= ло к целесооб= ;разности оценк= и затрат на разработ= ;ку ПС не </spa= n>только k= 4; а= бсолютных значе= ниях для о= ;пытно- го или базового образца, но и в о= тносительнm= 9;х величинах д&= #1086;ли затра= т на<= /span> про= ;- грамм= ы в каждом экземпля= ;ре реали= зующей (целевой) ЭВ&#= 1052; п= ри серий= ном произ= водстве систе= м. <o:p></o:p> Пр&= #1080; выделени= ;и с&#= 1086;ставляющих затрат на раз&= #1088;аботку прогр= амм </s= pan>целесооб= ;разно учиты= вать их относительl= 5;ый вес в= ; сумма= рных затра= тах и возм= ;ожность локал= изации групп= специали- стов, влияющих на </s= pan>величину= ; этих затрат. Разработ= ;ка прогр= амм являе= тся облас= тью с малой м= ;атериал= ;о- и энергоемкоl= 9;тью, и основ- ные з= ;атраты </spa= n>связаны </spa= n>с н= епосредствk= 7;нным или овеществлеl= 5;ным трудо= м специ= алистов разли= чных катег= орий. Поэто= му для и= ;змере- ния з= ;атрат l= 5;аиболее= ; универса= ;льной едини= цей стала= трудоемк= ;ость в челов= еко-месяцах или ч= ;еловеко= ;-годах. При э= ;том учитываю= ;тся все к= ;атегори= ;и специ= алистов, участ= вующих непос= редственно или косвенно в с= оздании да&= #1085;ного ПС. <o:p></o:p> Время или допустимая длительносm= 0;ь разработки определеннm= 9;х компонентоk= 4; и версий ПС является невосполниl= 4;ым ограниченнm= 9;м ресурсом реальных проектов. Этот ресурс все больше определяеm= 0; достижимое качество сложных комплексов программ в процессе их разработки = 80; сопровождеl= 5;ия. Высокие тре = 73;ования заказчиков к сжатым срок = 72;м реализации проектов, естественl= 5;о, ограничиваn= 2;т разработчиl= 2;ов и испытателеl= 1; в продолжит = 77;льности и объеме возможного системного анализа и проектировk= 2;ния, разработки = 80;, особенно, тестированl= 0;я программ. Увеличение числа, привлекаемm= 9;х для этого специалистl= 6;в, при опытной эксплуатацl= 0;и или бета- = 90;естировани&#= 1080;, только в некоторых пределах позволяет у = 89;корять разработку = 80; увеличиватn= 0; совокупное число тесто = 74; при проверках, для повышен = 80;я качества программ. <o:p></o:p></span= > Доступн= ;ые разработчиl= 2;ам ПС вычислителn= 0;ные ресурсы объ = 77;ктных и технологи = 95;еских ЭВМ являютс= 03; одним из важнейших факторов, определяющl= 0;м достижимое качество сложных ПС. В процессе пр = 86;ектировани&#= 1103; целесообраk= 9;но выделять определеннm= 9;е ресурсы ЭВМ на оперативноk= 7; обеспечениk= 7; качества, по= 074;ышение защищенносm= 0;и, безопасносm= 0;и и надежност = 80; функционирl= 6;вания. Допустимая величина и рациональнl= 6;е распределеl= 5;ие ресурсов ЭВ = 52; на отдельны = 77; методы улучшения о = 87;ределенных конструктиk= 4;ных характерисm= 0;ик качества ПС, оказывают существеннl= 6;е влияние на достигаемыk= 7; их значения. <o= :p></o:p> <s= pan style=3D'mso-spacerun:yes'> = Обобщенныl= 4;и ресурсами Ж = 62; проекта ПС являются до = 89;тупные стоимость или совокупные трудовые, временные и материальнm= 9;е затраты, необходимыk= 7; для приобре = 90;ения, создания, модификациl= 0; и эксплуата = 94;ии компонентоk= 4; и всего комплекса программ. Эт= 080; характерисm= 0;ики непосредстk= 4;енно влияют прак = 90;ически на все показатели качества и определяют рентабельнl= 6;сть покупки или создания заново конк = 88;етного программноk= 5;о продукта. Эт= 086; означает, чт= 086; качество яв = 83;яется относительl= 5;ым понятием, ко= 090;орое зависит от ресурсов и субъектов, осуществляn= 2;щих его оценку с позиции эффективноl= 9;ти использоваl= 5;ия, а также от сос= 090;ояния рынка соотв = 77;тствующей продукции, е= 105; производитk= 7;лей и технологи = 81;. Ориентациn= 3; на потребителk= 7;й подразумевk= 2;ет анализ их нужд и определениk= 7; возможност&#= 1077;й рынка удовлетворl= 0;ть эти потребн = 86;сти. При этом следует учитывать р = 99;ночную конкуренциn= 2; двух видов: между поста = 74;щиками готовых к применению программныm= 3; средств l= 9; фиксироваl= 5;ным качеством и между разра = 73;отчиками, способными обеспечить жизненный цикл ПС или его существ = 77;нную часть, с хара&#= 1082;теристикам= и качества, требующимиl= 9;я конкретномm= 1; заказчику. В последнем случае на требуемое качество могут оказывать влияние не только заказчик и непосредстk= 4;енные пользоватеl= 3;и, но и различн= 099;е посредники, организациl= 6;нные и торговые структуры, а также испол = 85;ители проекта. <o:p></o:p> В начале проектировk= 2;ния ПС всегда возникает задача оцен = 80;вания ресурсов, ко= 090;орые необходимы = 80; доступны дл= 03; создания и о= 073;еспечения всего ЖЦ ПС, а также возмо = 78;ной экономичесl= 2;ой эффективноl= 9;ти последующеk= 5;о применения комплекса программ по назначению при условии = 088;еализации требуемых характерисm= 0;ик качества. Экономичесl= 2;ая эффективноl= 9;ть и затраты имеют самостоятеl= 3;ьное значение и методологиn= 2; при анализе ЖЦ ПС. При планированl= 0;и проектов пр = 86;граммных средств, часто инициатороl= 4; разработки является разработчиl= 2;-поставщик, который сам = 86;стоятельно принимает все решения о про= ектированиl= 0; за счет собственныm= 3; ресурсов и предполагаk= 7;т возместить затраты при = 088;еализации программноk= 5;о продукта на рынке. В других случаях име = 77;тся определеннm= 9;й заказчик-по = 90;ребитель, который способен задать основные цели, характерисm= 0;ики качества и обеспечить ресурсы для реализации проекта. Так= 080;м образом, при экономичесl= 2;ом анализе ресурсов проектов П = 57; возможны два сценари= 03; (см. лекцию 5): <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 86;здание и весь жизненный цикл комплекса п = 88;ограмм и/или базы данных орие = 85;тируется разработчиl= 2;ом на массовое тиражироваl= 5;ие и распростраl= 5;ение на рынке, для заранее не известных покупателеl= 1;-пользовате&#= 1083;ей в различных сферах прим = 77;нения, при этом отсутствуеm= 0; приоритетнm= 9;й внешний потребителn= 0;-заказчик, который определяет = 80; диктует основные требования, = 072; также финан = 89;ирует проект;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 72;зработка проекта ПС и/или БД предполагаk= 7;тся поставщикоl= 4;-разра-ботчиком для конкретногl= 6; потребителn= 3;-заказчика, задающего требования, который его финансируеm= 0;, с определеннm= 9;м, необходимыl= 4; ему тиражом и известной, ограниченнl= 6;й областью применения результатоk= 4; разработки. <o:= p></o:p> Разработкk= 2; ПС характеризm= 1;ется высокой долей творческогl= 6; труда, особенно н = 72; начальных и завершающиm= 3; этапах. Поэтому тру = 76;оемкость и длительно = 89;ть отдельных опера= ;ций, частных раб = 86;т и качество результатоk= 4; при проектировk= 2;нии существеннl= 6; зависят от индивидуалn= 0;ных особенностk= 7;й относительl= 5;о небольшого числа руков = 86;дителей и исполните = 83;ей, а также от характерисm= 0;ик конкретногl= 6; проекта. Отсюда принципиалn= 0;ной особенностn= 0;ю создания сложных ком = 87;лексов программ является необходимоl= 9;ть активного участия руководитеl= 3;ей и заказчико = 74; проекта в системном анализе, итерационнl= 6;м экономичесl= 2;ом оценивании затрат ресу = 88;сов и уточнении планов на базе протот = 80;пов завершеннm= 9;х разра= ;боток ПС и их личного опыта. <o:p></o:p> На рис. 9.1 отражены затраты на технологию, инструментk= 2;льные средства автоматизаm= 4;ии разработки = 80; ЖЦ ПС, а также затраты на аппаратуру вычислителn= 0;ных систем, необ= 093;одимую при обеспечениl= 0; жизненного цикла комплексов программ. Эти затраты тол= 00;ко обозначены = 74; данной лекции, а их описания и оценки отнесены к лекции 16. <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102481"></a><a name=3D"_Toc508102254">9.2. Ресурсы специалисm= 0;ов для обеспеч = 77;ния жизненногl= 6; цикла &= nbsp; сложных программныm= 3; средств</a></h1> <o:p> </= o:p> Ва= ;жнейшим ресурсом пр = 80; создании программныm= 3; средств являются люди – специ= алисты, с их уровнем профессионk= 2;льной квалификацl= 0;и, а также с многообразl= 0;ем знаний, опыта, стимулов и потребностk= 7;й. Быстрый рос = 90; сложности и повышение о = 90;ветственно&#= 1089;ти за качество комплексов = 87;рограмм привели к = появлению новых требований = 82; специалистk= 2;м программноl= 1; инженерии,</sp= an> обеспечиваn= 2;щим все этапы жизненного цикла ПС. Эти требования отражены, в частности, в восьми совр = 77;менных принципах управления качеством п = 88;одукции и технологи = 80; (см. лекцию 1). Теперь недо = 89;таточно навыков процедурноk= 5;о программирl= 6;вания небольших компонентоk= 4;, а необходим = 99; глубокие знания системотехl= 5;ики, технологии проектировk= 2;ния, методов обеспечениn= 3; и контроля к= 072;чества сложных ком = 87;лексов программ в определеннl= 6;й области при = 84;енения. Эти специалистm= 9; должны владеть нов = 86;й интеллектуk= 2;льной профессией, обеспечиваn= 2;щей высокое кач = 77;ство ЖЦ программныm= 3; средств, а также контр = 86;ль, испытания и удостовереl= 5;ие реального д = 86;стигнутого качества на каждом этап = 77; разработки = 80; совершенстk= 4;ования программ. Крупномасшm= 0;абное проектировk= 2;ние ПС различны = 93; классов, раз= 076;еление труда специалистl= 6;в по квалификацl= 0;и при разрабо = 90;ке программ и д= 072;нных, организациn= 3; коллективоk= 4; и экономика таких разра = 73;оток стали важне = 81;шей частью выбора, обучения и подготовки специалистl= 6;в для обеспечениn= 3; всего ЖЦ ПС.<o:p></o:= p> При проектировk= 2;нии и создании в= 099;сококачест&= #1074;енных комплексов программ, прежде всег = 86;, необходима организациn= 3; и тесное взаимодейсm= 0;вие представитk= 7;лей заказчика и разработчиl= 2;ов проекта. Взгляды и требования = 79;аказчика, в основном, отражаются = 74; функционалn= 0;ных и потребите = 83;ьских характерисm= 0;иках ПС. Устремлениn= 3; разработчиl= 2;ов направлены на способы и= 093; реализации = 89; требуемым качеством. Эти различи= 03; исходных точек зрени= 03; на проект пр= 080;водят к тому, что некоторые неформализl= 6;ванные представлеl= 5;ия тех и других имеют зоны неоднозначl= 5;ости и взаимного непониманиn= 3;, что может приводить к конфликтам. Организациn= 3; четкого взаимодейсm= 0;вия и сокращени = 77; этих зон тре= 073;ует проведения определеннm= 9;х мероприятиl= 1; и контактов п = 86; обмену знан = 80;ями, взаимному повышению к = 74;алификации и обучению. <o:p></o:= p> Представиm= 0;ели заказчика, участвующиk= 7; в проектировk= 2;нии, должны обучаться ф = 86;рмализации автоматизиl= 8;уемых технологичk= 7;ских процессов, для которых предназначk= 7;ны соответствm= 1;ющие ПС, и иметь представлеl= 5;ие об эффектив = 85;ых путях их реализации. = 057; другой стороны, разработчиl= 2;и должны имет= 00; в своем сост= 072;ве квалифицирl= 6;ванных менеджеров, проблемно-о = 88;иентирован&#= 1085;ых системных архитекторl= 6;в (рис. 9.2), способных переводить функционалn= 0;ные требования = 79;аказчика в конкретны = 77; спецификацl= 0;и и техническиk= 7; требования = 82; комплексу программ и его компонентаl= 4;. Специалистm= 9; по проектир = 86;ванию сложных ПС (системные архитекторm= 9;) должны имет= 00;, прежде всег = 86;, хорошую подготовку по системному анализу алгоритмов = 80; пакетов прикладных программ, по методам оценки эффе = 82;тивности проектов, организациl= 0; и планирова = 85;ию крупномасшm= 0;абных разработок программ и баз данных. Им необходима высокая квалификацl= 0;я по архитект = 91;рному построению, комплексноl= 1; отладке и испытаниям ПС определеннm= 9;х классов, умение орга = 85;изовать коллектив для решения общей целевой задачи сист = 77;мы. Это позволи = 90; на ранних этапах искл= 02;чать или сокращать дефекты, обусловленl= 5;ые различием представлеl= 5;ия ими целей и задач проектов, а также их пок= 072;зателей качества.<o:p></o:p>= = Крупномасm= 6;табные ПС являются одними из наиболее сложных объектов, со= 079;даваемых человеком, и в процессе и= 093; разработки </sp= an>= - творчеl= 9;тво как поиск новых методов, альтернатиk= 4;ных решений и способов ос = 91;ществления заданных требований, = 072; также форми = 88;ование и декомпози = 94;ия этих требований составляют = 79;начительну&#= 1102; часть всех трудозатраm= 0;. Индустриалl= 0;зация разработки ПС позволяе = 90; автоматизиl= 8;овать нетворческl= 0;е, техническиk= 7; и рутинные операции и этапы, а также облег = 95;ает творческий процесс за счет селекц = 80;и, обработки и подготовки информации, необходимоl= 1; для приняти= 03; творческих решений. Следствием этого является значительнl= 6;е сокращение доли k= 9;атрат на творческий труд в непосредстk= 4;енных затратах на разработку комплексов программ. <o:p></o:p></span= > = Однако в программноl= 1; инженерии неуклонно повышается сложность с = 86;здаваемых ПС, что вызывает возрастаниk= 7; затрат твор = 95;еского труда на еди= 085;ицу размера про = 75;рамм. В перспекти = 74;е, не смотря на автоматизаm= 4;ию и повышение инструментk= 2;льной оснащенносm= 0;и технологии разработки программ, доля творческогl= 6; труда при создании полностью н = 86;вых крупномасшm= 0;абных ПС возрастает. Даже при сокращении суммарных з = 72;трат на разработку программныm= 3; компонентоk= 4; за счет автоматизаm= 4;ии нетворческl= 6;го труда, все бо&#= 1083;ее определяющk= 7;й для технико-эко = 85;омических показателеl= 1; (ТЭП) создания ПС становится доля затрат на творческий труд и возрастают требования = 82; творческим способностn= 3;м специалистl= 6;в. <o:p></o:p> = Необходимl= 6;сть всегда выполнять значительнm= 1;ю долю творче = 89;ких работ, которые даже для высококвалl= 0;фицированн= 099;х коллективоk= 4; требуют опр = 77;деленных затрат, приводит к пониманию наличия потенциальl= 5;ых предельных значений ТЭ = 55; для новых ра= 079;работок. По мере повы= 096;ения квалификацl= 0;и коллектива = 80; автоматизаm= 4;ии творческой части труда следует ожидать асимптотичk= 7;ского приближениn= 3; к предельны = 84; значениям ТЭП. Эти предельные значения определяютl= 9;я интеллектуk= 2;льными возможностn= 3;ми человека по интенсивноl= 9;ти принятия творческих = 88;ешений. Они позволили выявить предельные значения производитk= 7;льности труда и длительносm= 0;и разработки сложных комплексов программ (см. лекцию 5). Р&= #1077;альным путем их оценки, является и = 79;учение и экстраполяm= 4;ия прецедентоk= 4; и эксперименm= 0;альных данных реальных ра = 79;работок ПС с наилучшими ТЭП, с учетом возр = 72;стания квалификацl= 0;и специалистl= 6;в и уровня автоматизаm= 4;ии разработок.</sp= an> Эти факторы способствуn= 2;т эволюционнl= 6;му, относительl= 5;о медленному приближениn= 2; к пределn= 0;ным значений ТЭ = 55; для новых ПС. Вряд ли можн= 086; ожидать в ближайшие годы повыше = 85;ия производитk= 7;льности труда на порядок при создании по = 83;ностью новых, сложных про = 75;раммных продуктов. Еще более консерватиk= 4;на длительносm= 0;ь таких разра = 73;оток.<o:p></o:p> Принципиаl= 3;ьным путем улучш = 77;ния ТЭП при разработке сложных ПС является исключение творчества на тех этапах, где возможны ти = 87;овые, стандартныk= 7; решения и апробироваl= 5;ные заготовки, н= 077; требующие при их применении высококвалl= 0;фицированн= 086;го творческогl= 6; труда. Основ= 086;й такого подхода является применение = 91;нифицирова&#= 1085;ной технологии, готовых исп = 99;танных компонентоk= 4; и стандартизl= 0;рованной архитектурm= 9; определеннm= 9;х классов ПС. Использоваl= 5;ие готовых апр = 86;бированных модулей почти исключает творческий труд по их пр&#= 1086;граммирова= нию, автономной отладке и документирl= 6;ванию. На этих этап= 072;х творческие усилия необ = 93;одимы только для отбора готовых компонентоk= 4; и разработк = 80; новых, отсут= 089;твующих среди апробироваl= 5;ных. Однако практическl= 0; полностью с = 86;храняется творческий труд при системном анализе, при комплексирl= 6;вании компонентоk= 4; и их комплек= 089;ной отладке, а также во вре= 084;я испытания П = 57; в целом (см. лекцию 14). <o:p></o:p> Для реализации сложных проектов ПС наиболее часто приме = 85;яются две схемы ор= 075;анизации коллективоk= 4; специалисm= 0;ов:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>ф = 86;рмирование для выполнения каждого про = 77;кта жесткой орг = 72;низационно&#= 1081; структуры целостного коллектива = 89; полным составом не = 86;бходимых специалистl= 6;в под единым, централизоk= 4;анным руководствl= 6;м лидера прое = 82;та; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 99;деление руководитеl= 3;я (главного конструктоl= 8;а) и небольшой группы инте = 75;раторов, по заданиям которых выполняютсn= 3; частные работы узкими специалистk= 2;ми по компонен = 90;ам, не входящим = 80; организациl= 6;нно в единый коллектив для реализа = 94;ии каждого конкретногl= 6; крупного проекта.<o:p></o:p> Первая схема предпочтитk= 7;льна, когда фирма реализует небольшое число особенно кр = 91;пных проектов-за = 82;азов и имеет возможностn= 0; для каждого из них скомплектоk= 4;ать полноценнуn= 2;, организациl= 6;нно замкнутую, “команду”. Она полностью реализует проект и нес= 077;т ответственl= 5;ость за его качество. Однако при этом возможны простои отдельных с = 87;ециалистов из-за несинхроннl= 6;го ожидания за = 76;аний или результатоk= 4; последоватk= 7;льных этапов проектировk= 2;ния компонентоk= 4; другими специалистk= 2;ми. Вторая схем = 72; для фирмы может иметь преимущестk= 4;а при большом числе относительl= 5;о небольших проектов, бл= 080;зких по содержанию = 80; функционалn= 0;ному назначению компонентоk= 4;. В этом случа= 077; большинствl= 6; специалистl= 6;в одновременl= 5;о участвуют в нескольких заказах по локальным заданиям лидеров и интеграторl= 6;в различных проектов, и может использоваm= 0;ься более полно. Однако задачи интеграторl= 6;в при этом усложняютсn= 3; и требуют бо= 083;ее высокой квалификацl= 0;и. Хотя за качество проекта в целом также несут ответ = 89;твенность руководитеl= 3;ь – лидер и группа инте = 75;раторов, усложняетсn= 3; взаимодейсm= 0;вие с поставщик = 72;ми компонентоk= 4; и руководст = 74;о их качество = 84;. <o:p></o:p> Для реализации мероприятиl= 1; по планиров = 72;нию и управлени= 02; жизненным циклом= концептуаl= 3;ьно целостных, крупных ПС и обеспечениn= 3; их качества, необходимы организациl= 6;нные действия системных архитекторl= 6;в, направленнm= 9;е на подбор и обучение ко = 83;лектива специалистl= 6;в разных категорий и специализаm= 4;ий (см. рис. 9.2). Концепция – ключевой, исходный документ сложного жизненного цикла ПС. Он непосредстk= 4;енно ориентировk= 2;н на решение проблемы ко = 84;плексной реализации требований = 80; является документом, = 082; которому можно обратиться = 74; любой момен = 90;, чтобы увиде = 90;ь, что продукт или система должны дела = 90;ь. <o:p></o:p> Практич= ;ески в каждом усп= 077;шном проекте должен быть или был лиде= 088;. Лидером продукта может быть: менеджер пр = 86;дукта, менеджер проектировk= 2;ния, руководитеl= 3;ь проекта. Лидер долже = 85;:<o:p></o:p>= <![if !supportLists]>-&nb= sp; = <![endif]>р = 91;ководить процессом выявления и формированl= 0;я требований заказчика; <o:p></o:p= > <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;ссматриват&#= 1100; конфликтуюm= 7;ие пожелания, поступающиk= 7; от различны = 93; участников проекта и находить компромиссm= 9;, необходимыk= 7; для определениn= 3; набора функций, пре= 076;ставляющих наибольшую ценность дл= 03; максимальнl= 6;го числа участников;<o:p= ></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 77;сти переговоры = 89; заказчиком, руководствl= 6;м, пользоватеl= 3;ями и разработч = 80;ками и поддерживаm= 0;ь равновесиk= 7; между тем, чего хочет з= 072;казчик, и тем, что может предо = 89;тавить команда разработчиl= 2;ов за ресурсы и время, отведенные заказчиком для реализа = 94;ии проекта;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 89;уществлять проверку спецификацl= 0;й программноk= 5;о средства, чтобы удостовериm= 0;ься, что они соответствm= 1;ют реальной ко = 85;цепции, предс= ;тавленной детальными функциями; <o:p></o:p> <![if= !supportLists]>-&nb= sp; = <![endif]>осущест= ;влять управление изменением приоритетоk= 4; задач, а также добав = 83;ением и исключениеl= 4; функций.<o:p></o:p> История развития разработок = 87;рограммных продуктов – это история роста их масштабов. Крупные проекты, как правило, требуют коо = 88;динированн&#= 1086;й работы больших коллективоk= 4; и многих команд. Возр= 072;стание сложности снижает способностn= 0; человека решать задачи интуитивно по мере их возникновеl= 5;ия. Чтобы добиться успеха в большом проекте, нео= 073;ходима четкая координациn= 3; действий “команды”, которая должна рабо = 90;ать по общей методологиl= 0;, чтобы решит= 00; проблему комплекса требований = 80; качества. Успешное управление требованияl= 4;и заказчика м = 86;жет осуществляm= 0;ься только эффективно организоваl= 5;ной командой разработчl= 0;ков. <o:p></o:p> &nb= sp; Одним из наиболее важных факторов является то, что члены ко= 084;анды имеют разли = 95;ные, профессионk= 2;льные навыки и квалификацl= 0;ю. Поэтому трудно ожидать, что некий универсальl= 5;ый способ организациl= 0; команды будет во все= 093; случаях предпочтитk= 7;льнее, чем альтернатиk= 4;ные варианты. Те= 084; не менее, определеннm= 9;е общие элементы присутствуn= 2;т во многих успешных командах. Поэтому важно рассм = 86;треть некую гипотетичеl= 9;кую структуру команды. <o:p></o:p> Руковод= ;ство крупным проектом ПС должны осущ = 77;ствлять один или два лидера – менеджера (см. рис. 9.2): <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>м = 77;неджер проекта = - этот специалист, обеспечиваn= 2;щий коммуникацl= 0;ю между заказчиком = 80; проектной командой, ег= 086; задача -</span= > опредеl= 3;ить и обеспечит= 00; удовлетворk= 7;ние требований = 79;аказчика; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>м = 77;неджер-архи&= #1090;ектор комплекса программ = - управляет коммуникацl= 0;ями и взаимоотн = 86;шениями в проектной команде, явл= 103;ется координатоl= 8;ом создания компонентоk= 4;, разрабатывk= 2;ет базовые, фун= 082;циональные спецификацl= 0;и и управляет = 080;ми, ведет графи = 82; проекта и отчитываетl= 9;я за его состояние, инициирует принятие кр = 80;тичных для хода про= 077;кта решений. <o:p></o:p> В реализации крупного проекта можно выдел = 80;ть две категории с = 87;ециалистов: разрабатывk= 2;ющих компоненты = 80; ПС в целом и обеспечиваn= 2;щие технологию = 80; качество пр = 86;граммного продукта. Организациl= 6;нное разделение специалистl= 6;в, осуществляn= 2;щих разработку ПС (первая категория), и специалистl= 6;в, контролируn= 2;щих и управляющиm= 3; его качеств = 86;м в процессе разработки = 80; всего ЖЦ (вто&#= 1088;ая категория), должно обеспечиваm= 0;ь независимыl= 1;, достоверныl= 1; контроль качества ре = 79;ультатов разработки = 80; эффективноk= 7; достижение заданных характерисm= 0;ик.<o:p></o:p> Специал= ;исты первой категории непосредстk= 4;енно создают компоненты = 80; ПС в целом с заданными показателяl= 4;и качества. В процессе разработки их функции заключаютсn= 3; в тщательно = 84; соблюдении принятой в фирме технологии и в формированl= 0;и всех предпи = 89;анных руководствk= 2;ми исходных и отчетных документов. При этом предполагается, что выбранн = 72;я технология способна обеспечить необходимыk= 7; значения конструктиk= 4;ных показателеl= 1; качества, а достижение заданных фу = 85;кциональны&#= 1093; характерисm= 0;ик гарантируеm= 0;ся тематическl= 6;й квалификацl= 0;ей соответствm= 1;ющих специалистl= 6;в и регулярны = 84; контролем этих характерисm= 0;ик в процессе р= 072;зработки. Система стандартизl= 0;рованного документирl= 6;вания частных работ должн = 72; обеспечить объективноk= 7; отражение качества компонентоk= 4; и процессов и = 93; создания на всех этапах ЖЦ ПС (см. лекц= ию 17). <o:p></o:p></span= > Разделе= ;ние труда специалистl= 6;в этой катего = 88;ии в крупных пр= 086;ектных коллективаm= 3; приводит к необходимоl= 9;ти их дифференциk= 2;ции по квалифик = 72;ции и областям деятельносm= 0;и:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>с = 87;ецификатор&#= 1099; подготавлиk= 4;ают описания функций соответствm= 1;ющих компонентоk= 4; с уровнем детализациl= 0;, доста= ;точным для коррект = 85;ой разработки текстов программ пр = 86;граммистам&#= 1080; и их интерфе= 081;сов;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>р = 72;зработчики программныm= 3; компонентоk= 4; = - программисm= 0;ы создают компонентm= 9;, удовлетворn= 3;ющие спецификацl= 0;ям, реал= изуют возможностl= 0; продукта, отслеживаn= 2;т и исправляю = 90; ошибки, при разработке сложных систем это требует детального знания высо = 82;оуровневых языков программирl= 6;вания, визуальногl= 6; программирl= 6;вания, сетевых тех = 85;ологий и проектировk= 2;ния баз данных; <o:p></o:= p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>с = 80;стемные интеграторm= 9; сложных проблемно-о = 88;иентирован&#= 1085;ых ПС работают над проектами в значительнl= 6;й степени отличными о = 90; программисm= 0;ов методами, на разных языках прое = 82;тирования, используют различные средства автоматизаm= 4;ии и имеют на вы&#= 1093;оде различные результаты крупных ком = 87;онентов и комплексо = 74; программ;<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>тестировщ&#= 1080;ки обеспечиваn= 2;т проверку функционалn= 0;ных спецификацl= 0;и, систем обеспечениn= 3; производитk= 7;льности, пользоватеl= 3;ьских интерфейсоk= 4;, разрабатывk= 2;ют стратегию, планы и выполняют тестированl= 0;е для каждой и= 079; фаз и компон= 077;нта проекта, должны быть администраm= 0;ивно независимыl= 4;и от программ = 80;стов и специфика = 90;оров; <o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>у = 87;равляющие сопровождеl= 5;ием и конфигура = 94;ией, инструкторm= 9; интерфейсоk= 4; отвечают за снижение затрат на модификациn= 2; и сопровождеl= 5;ие продукта, обеспечениk= 7; максимальнl= 6;й эффективноl= 9;ти работы разр = 72;ботчиков по взаимодейсm= 0;вию компонентоk= 4; и реализации версий ПС, пр&#= 1080;нимают участие в обсужденияm= 3; пользоватеl= 3;ьского интерфейса = 80; архитектурm= 9; продукта;<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>д = 86;кументатор&#= 1099; процессов и объектов ЖЦ ПС обеспечи = 74;ают подготовку = 80; издание сводных технологичk= 7;ских и эксплуатацl= 0;онных документов = 74; соответствl= 0;е с требовани= 03;ми стандартов.<o:p= ></o:p> Успех и качество пр = 80; разработке сложных про = 75;раммных комплексов все больше з= 072;висит от слаженностl= 0; работы и профессионk= 2;лизма коллектива этой катего = 88;ии специалистl= 6;в на всех этапах и уровнях создания таких проектов. Пр= 080; выборе заказчиком надежного поставщика- = 88;азработчик&#= 1072; проекта необходима оценка тема = 90;ической и технологичk= 7;ской квалификацl= 0;и возможного коллектива специалистl= 6;в, а также его способностl= 0; реализоватn= 0; проект с заданными требованияl= 4;и и качеством. Тематическm= 1;ю квалификацl= 0;ю специалистl= 6;в в области создания ПС определеннl= 6;го функционалn= 0;ного назначения приближеннl= 6; можно харак = 90;еризовать средней про = 76;олжительно&#= 1089;тью работы в данной проблемной области осн = 86;вной части команды, непосредстk= 4;енно участвующеl= 1; в разработк = 77; алгоритмов, = 089;пецификаци&= #1081;, программ и баз данных. Важнейшую роль при это= 084; играет квал = 80;фикация руководитеl= 3;ей – лидеров разработкl= 0; и системных аналитиков функционалn= 0;ных компонентоk= 4; и в меньшей степени непосредстk= 4;енных разработчиl= 2;ов программ в конкретной прикладной области. Особенно важна не индивидуалn= 0;ная характерисm= 0;ика каждого специалистk= 2;, а, прежде всего, интегральнm= 9;й показатель квалификацl= 0;и “команды”, реализующеl= 1; некоторую, достаточно крупную функционалn= 0;ную задачу или весь проект. При низкой тематическl= 6;й квалификацl= 0;и допускаютсn= 3; наиболее гр = 91;бые системные ошибки, требующие больших затрат при доработке программ ил = 80; даже делающие проект практическl= 0; не реализуе = 84;ым.<o:p></o:p> Техноло= ;гическая квалификацl= 0;я коллектива характеризm= 1;ется опытом и дли= 090;ельностью работы с регламентиl= 8;ованными технологияl= 4;и, инструментk= 2;льными комплексамl= 0; автоматизаm= 4;ии разработки, языками проектировk= 2;ния, программирl= 6;вания и тестированl= 0;я ПС. Особое значение имеет коллективнm= 9;й опыт органи = 79;ации и выполнени= 03; сложных проектов на = 073;азе современныm= 3; автоматизиl= 8;ованных технологий = 80; инструментk= 2;льных средств. Опы= 090; применения конкретногl= 6; комплекса автоматизаm= 4;ии и языков проектировk= 2;ния ПС может являться су = 97;ественным фактором пр = 80; выборе технологии для создани= 03; новых компо = 85;ентов и обеспечен = 80;и качества ПС.<o:= p></o:p> В детальной<sp= an style=3D'mso-spacerun:yes'> модели СОСОМО (см. лекцию 5)значительн= 086;е внима-ние уделено влиянию организациl= 0; и взаимодейсm= 0;вия коллектива разра-ботчи = 82;ов на трудоемкосm= 0;ь создания сложных программныm= 3; средств – таблица 9.1. В составе организациl= 6;нных характерисm= 0;ик коллектива реко-мендуе = 90;ся учитывать согласованl= 5;ость целей специалистl= 6;в, участвующиm= 3; в проекте, их психологичk= 7;скую совместимоl= 9;ть и способностn= 0; к дружной коллективнl= 6;й работе, наличие опыта работ = 99; в данном коллективе = 80; другие объективныk= 7; и субъектив = 85;ые свойства участников проекта. При этом большо = 77; значение может иметь личная моти = 74;ация и психологичk= 7;ские особенностl= 0; поведения разных специалистl= 6;в при комплек = 89;ной работе над сложным проектом. Эт= 080; характерисm= 0;ики могут быть обобщены в качес-твенн = 99;й показатель влияния сложности взаимодейсm= 0;вия специалистl= 6;в в коллектив = 77;, которому сопоставлеl= 5;ы коэффициенm= 0;ы изменения трудо= ;ем-кости разработки ПС (последня= 103; строка в таблице 9.1). Наилучшим счита-ется непрерывноk= 7; корректное взаимодейсm= 0;вие организоваl= 5;ных специали-ст = 86;в с большим опытом работы в данном колл = 77;ктиве при полной согласо-ван = 85;ости их целей, планов и методов работы. В остальных случаях в то= 081; или иной степени (даж= 077; в 3 – 5 раз) може = 90; возрастать трудоемкосm= 0;ь разра-ботки ПС, что нельзя не учитывать при прогноз = 80;ровании ТЭП и обоснова-ни = 80; разработки крупных проектов. <o:p></o:p> Специ= алисты второй категории = - технологи, обслуживаюm= 7;ие и сопровожд = 72;ющие технологичk= 7;ский инструментk= 2;рий, который при = 84;еняется специалистk= 2;ми первой категории, о= 073;еспечивают применение системы кач = 77;ства проекта или предприятиn= 3;, контролируn= 2;т и инспектир = 91;ют ее использо = 74;ание (см. рис. 9.2). Осно&= #1074;ные задачи второй категории специалистl= 6;в должны быть сосредоточk= 7;ны на контроле процессов и результатоk= 4; выполнения работ и на принятии организациl= 6;нных и технологи = 95;еских мер для достижения их необходимоk= 5;о качества, обеспечиваn= 2;щего выполнение всех требов = 72;ний техническоk= 5;о задания на ПС.<o:p></o:p> Технологи должны выбирать, пр= 080;обретать и осваивать наиболее эффективныl= 1; инструментk= 2;рий для проекто = 74;, реализуемыm= 3; конкретной фирмой с уче= 090;ом особенностk= 7;й создаваемыm= 3; ПС требуемо = 75;о качества и рентабельнl= 6;сти технологичk= 7;ских средств. Они должны разрабатывk= 2;ть регламентиl= 8;ованный технологичk= 7;ский процесс и систему качества, поддерживаn= 2;щие весь ЖЦ ПС и обучать разработчиl= 2;ов ПС квалифицирl= 6;ванному применению соответствm= 1;ющих инструментk= 2;льных средств и технологий. <o:= p></o:p> Специал= ;исты, управляющиk= 7; обеспечениk= 7;м качества ПС, должны овладеть стандартамl= 0; и методикам = 80; фирмы, поддерживаn= 2;щими регистрациn= 2;, контроль, документирl= 6;вание и воздейств = 80;я на показатели качества на всех этапах ЖЦ программ. Они должны обеспечиваm= 0;ь эксплуатацl= 0;ю системы качества проекта, выя= 074;ление всех отклонений от заданных = 087;оказателей качества объектов и процессов, а также от предписаннl= 6;й технологии на промежут = 86;чных и заключителn= 0;ных этапах разработки. Эти же специ= 072;листы должны анализировk= 2;ть возможные последствиn= 3; выявленных = 86;тклонений от требований техническоk= 5;о задания или спецификацl= 0;и на ПС. В результате должны приниматьсn= 3; меры либо по устранению отклонений, либо по корректироk= 4;ке требований, если устранение отклонений требует чре = 79;вычайно больших ресурсов. <o:p></o:p></span= > Инспекторm= 9;-испытатели по проверке систем качества пр = 77;дприятия и качества п= 088;ограммных продуктов должны пройти обуч = 77;ние, дающее им знания и квалификацl= 0;ю, необходимыk= 7; для проведения испытаний, оценки их результатоk= 4; и эффективноl= 9;ти применения систем каче = 89;тва. Для них (см. ISO 10011-2) необх= 086;димыми считаются знание и понимание стандартов = 80; нормативныm= 3; документов, = 074; соответствl= 0;и, с которыми должны осуществляm= 0;ься оценки применения = 89;истем качества, а также обследованl= 0;е, анкетироваl= 5;ие и составлен = 80;е отчетов по испытаниям. Инспектор-э = 82;сперт, в соответст = 74;ии со стандартом, должен быть непредубежk= 6;енным; обладать зд = 88;авым смыслом; иметь аналитичесl= 2;ий склад ума и твердость воли; обл = 72;дать способностn= 0;ю реально оценивать сложные действия с точки зрени= 03; их дальнейшей перспективm= 9; в рамках общ= 077;й организациl= 6;нной структуры:<o:p></o:p>= <![if= !supportLists]>-&nb= sp; = <![endif]>получат= ;ь и справедливl= 6; оценивать объективныk= 7; данные испы = 90;аний характерисm= 0;ик продуктов и систем качества пр = 80; незаинтереl= 9;ованном проведении = 87;роверок;<o:p></o:p> <![if= !supportLists]>-&nb= sp; = <![endif]>относит= ;ься к персоналу системы качества, по= 076;вергающему&= #1089;я проверке, таким образом, что= 073;ы получить наилучшие результаты;<o:p= ></o:p> <![if= !supportLists]>-&nb= sp; = <![endif]>приходи= ;ть к приемлемы = 84; для разработчиl= 2;ов и заказчика выводам, основанным на реальных наблюденияm= 3; в процессе испытаний характерисm= 0;ик качества ПС.<o:= p></o:p> Пере = 95;исленные выше специализаm= 4;ии и квалифика = 94;ии персонала, участвующеk= 5;о в крупных проектах ПС, требуют соответствm= 1;ющей их подготов = 82;и, отбора и непрерывноk= 5;о обучения, которые являются самостоятеl= 3;ьной, важной проблемой проектировk= 2;ния и всего ЖЦ комплексов программ. Обучение представляk= 7;т собой процесс и требует организациl= 0; и сопровожд = 77;ния обучаемого персонала. Должны быть разработанm= 9; и документи = 88;ованы планы, требования = 80; цели обучения, а также разработанm= 9; руководствk= 2;, включая материалы, используемm= 9;е для обучения (см. ше= 089;тую часть стандарта ISO<= span style=3D'font-size:14.0pt'> 15504). Персонал, ответственl= 5;ый за выполнен = 80;е конкретных задач, если это необход = 80;мо, должен быть аттестован на основе соответствm= 1;ющего образованиn= 3;, подготовки и/или опыта работы. Може= 090; также стать необходимыl= 4; включение в подготовку, ознакомленl= 0;е со специфич = 77;ской (проблемно-о= 088;иентирован&= #1085;ой) областью, в которой будет работ = 72;ть данное прог = 88;аммное средство, и повышение квалификацl= 0;и в этой области. Требования = 82; квалификацl= 0;и, обучению персонала и их реализац = 80;и должны быть документалn= 0;но оформлены в системном п = 88;оекте. <o:p></o:p> = Совещани= ;я предоставлn= 3;ют заинтересоk= 4;анным специалистk= 2;м из различны = 93; команд и организациl= 1; возможностn= 0; работать вм = 77;сте над достиже = 85;ием общей цели крупного проекта. Надлежащаn= 3; подготовка является залогом успеха совещаний. Первым дело = 84; необходимо распростраl= 5;ить идею внутри организациl= 0;, разъясняя преимущестk= 4;а проведения = 89;овещаний членам команды. Подготовка включает в себя также выявление заинтересоk= 4;анных лиц, которые могут повлиять на процессы ЖЦ ПС и чьи потребностl= 0; необходимо учесть, чтоб= 099; гарантировk= 2;ть успешный результат. <o:p></o:p= > Необ= ходимо заранее разослать подготовитk= 7;льные материалы, чтобы подго = 90;овить участников, = 072; также повысить производитk= 7;льность проводимогl= 6; совещания. Подготовитk= 7;льные материалы должны стимулировk= 2;ть как конкретное, так и свободное мышление. Для гk= 2;рантии успеха рекомендуеm= 0;ся, чтобы совещ = 72;ние проводилосn= 0; сторонним человеком, имеющим опы = 90; в решении уникальных = 79;адач управления. Если совещание проводится членом команды, это= 090; человек вначале не должен= вносить свои идеи и участвоватn= 0; в обсуждени = 80;. Иначе существует опасность, что совещание утратит, необх= ;одимую для получен = 80;я реальных фактов объе = 82;тивность и не будет способствоk= 4;ать созданию атмосферы, в которой мож = 85;о достигнуть консенсуса. = 042; любом случа = 77; специалист, = 074;едущий встречи играе= ;т ключевую роль в успех= 077; совещания и должен:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>у = 89;тановить правила проведения встречи и до= 073;иваться их выполнен = 80;я;<o:p></o:p> <![if !supportLists]>- = ; <![endif]>управлят&= #1100; течением дискуссии и удерживать команду на главной цел = 80; совещания;<o:p></o:p>= <![if !supportLists]>- &nb= sp; <![endif]>с = 87;особствова&#= 1090;ь процессу принятия решения и до= 089;тижения консенсуса, но избегать участия в содержателn= 0;ной части диску = 89;сии;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>у = 76;остоверить&#= 1089;я, что все заинтересоk= 4;анные лица участвуют и их пожелани= 03; учтены;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>к = 86;нтролирова&#= 1090;ь поведение участников, которое может приве = 89;ти к расколу ил= 080; мешает прод = 91;ктивной работе.<o:p></o:p> Следует активно привлекать заказчиков = 82; совещаниям, управлению их требован = 80;ями и масштабом проекта, чтобы обеспечить как качеств = 86;, так и своевр= 077;менность разработки ПС. Именно заказчики несут финан = 89;овую ответственl= 5;ость за выполнение внешних обязательсm= 0;в перед пользоватеl= 3;ями. Необходимы указания заказчиков при приняти = 80; основных решений, и только они могут реально опр = 77;делить, как, сократи= 074; функции ПС, п&#= 1086;лучить полезный комплекс пр = 86;грамм высокого качества, выполненныl= 1; в срок и в пределах бюджета. Исключенныl= 1; из процесса принятия решений заказчик бу = 76;ет недоволен и, естественнl= 6;, будет стремиться обвинить разработчиl= 2;ов в недостаточl= 5;ой старательнl= 6;сти. Привлечениk= 7; заказчика помогает наименее болезненно решить проблемы управления масштабом и функциями проекта. <o:p></o:p> Для защиты, как проекта, та= 082; и бизнес- = 94;елей заказчика может понад = 86;биться вести переговоры об объеме работ для команды. Во время перег = 86;воров с заказчико = 84; о техническ = 86;м задании и требованияm= 3; базового ур = 86;вня следует l= 8;уководство= 074;аться принципом меньше обещ = 72;ть и больше делать. Тогд= 072; неизбежные издержки разработки ПС (непредви= 076;енные технологичk= 7;ские риски, изменения требований, задержки пр = 80; приобретенl= 0;и закупаемых компонентоk= 4;, непредвидеl= 5;ный уход основных членов кома = 85;ды и т.п.) не приведут к нарушению графика ваш = 77;го проекта. Однако зака = 79;чики, внешние или внутренние, естественнl= 6; желают получить ка = 82; можно больш = 77; функционалn= 0;ных возможностk= 7;й в каждой версии ПС. Именно эти функционалn= 0;ные возможностl= 0; создают добавленнуn= 2; стоимость, которая важна им для достижения их бизнеl= 9;-целей. Следует с пониманием = 86;тноситься к требованияl= 4; клиентов, поскольку именно они, в конечном сч = 77;те, добиваются успеха на рынке. Однак= 086; если пойти на встреч = 91; требованияl= 4; заказчика повышения функционалn= 0;ности, это может негативно сказаться н = 72; качестве и общей жизнеспосоk= 3;ности проекта. <o:p></o:p> Обычно наиболее важным для р= 077;ализации проекта ПС и завl= 0;сящим от больш= ;инства его особенностk= 7;й и факторов является тl= 8;удоемкость,<s= pan style=3D'mso-spacerun:yes'> непос= ;редственно определяющk= 2;я стоимость</spa= n> создаваемl= 6;го комплекса программ. Значения длительносm= 0;и разработки = 80; числа специалистl= 6;в взаимосвязk= 2;ны и в некоторы= 093; пределах могут размениватn= 0;ся. Поэтому оценки этих показателk= 7;й затрат можно варьироватn= 0;, и при недост= 072;точном числе специалистl= 6;в естественнl= 6; возрастает длительносm= 0;ь разработки, хотя трудое = 84;кость может остаться практическl= 0; неизменной. Многократl= 5;ое применение = 86;дних и тех же апробироваl= 5;ных компонентоk= 4; и/или адаптация П = 57; к различным условиям применения является од = 85;им из перспективl= 5;ых методов повышения качества и снижения затрат труд = 72; специалистl= 6;в в жизненном цикле сложных комплексов программ.<o:p></o:p>= <o:p></o:p= > <h1><a name=3D"_Toc508102482"></a><a name=3D"_Toc508102255">9.3. Ресурсы для обеспечениn= 3; функционалn= 0;ной приго= ;дности при рk= 2;зработке сложных программныm= 3; средств</a> </h1> <o:p> </o:p> При проектировk= 2;нии ПС необходимо учитывать, что экономи = 95;еские, временные, вычислителn= 0;ные и другие ресурсы на разработку = 80; весь ЖЦ прог= 088;амм всегда ограниченнm= 9; и используемm= 9;е затраты для улучшения каждой характерисm= 0;ики должны учитывать эти ограничениn= 3;. Для рациона = 83;ьного распределеl= 5;ия этих ресурс = 86;в необходимо знать как от= 088;ажается изменение затрат на улучшении к = 72;ждой характерисm= 0;ики качества ПС. Эта взаимос = 74;язь затрат ресурсов и значений каждой хара = 82;теристики зависит от назначения, = 072; также от ряд= 072; свойств и других особенностk= 7;й комплекса программ, чт= 086; усложняет учет влияни= 03; таких связе = 81;. Тем не менее,<s= pan style=3D'mso-spacerun:yes'> выявл= ;ены основные те = 85;денции такого взаимодейсm= 0;вия, которые мог = 91;т служить ориентирамl= 0; при выборе и установленl= 0;и требований = 82; определеннm= 9;м характерисm= 0;икам качества в конкретных проектах ПС. <o= :p></o:p> Обеспеч= ;ение функционалn= 0;ной пригодностl= 0; является ос = 85;овной целью при использоваl= 5;ии финансовых, трудовых, вычислителn= 0;ных и других ресурсов в жизненном цикле ПС. Одн&#= 1072;ко это не значит, что затраты на р= 077;шение этой основной задачи всегда являются до = 84;инирующими по величине. Необходимоl= 9;ть выполнения ряда требований = 82; остальным, к= 086;нструктивн&= #1099;м характерисm= 0;икам качества, ча= 089;то приводит к тому, что исп&#= 1086;льзование ресурсов на их реализацию может превышать б = 72;зовые затраты на обеспечениk= 7; функционалn= 0;ной пригодностl= 0;. В то же время, затраты на выполнение этих требований, всегда напр = 72;влены на повышени = 77; и совершенс = 90;вование функционалn= 0;ной пригодностl= 0;. Поэтому обычно трудно четк = 86; выделить и количествеl= 5;но оценить все виды затрат = 99;, используемm= 9;е только на функционалn= 0;ную пригодностn= 0;. <o:p></o:p> В любом прогр = 72;ммном средстве можно выделить компоненты, = 074; которых сосредоточk= 7;ны функционалn= 0;ные алгоритмы и программы, предназначk= 7;нные для решения основных целевых задач ПС. В некоторые и = 79; них органическl= 0; входят компоненты для повышен = 80;я качества решения фун = 82;циональных задач или он= 080; построены с учетом требований = 74;ысокого качества результатоk= 4; основных функций. Для анализа затрат ресурсов в ж= 080;зненном цикле ПС при проектировk= 2;нии, их целесообраk= 9;но разделить н = 72; две части:<o:p></o:p></span= > <p class=3DMsoBodyTextIndent2 style=3D'margin:0cm;margin-bottom:.0001pt;tex= t-align: justify;text-indent:35.45pt;line-height:normal;mso-pagination:none;mso-list: l135 level1 lfo141;tab-stops:list 14.2pt'><![if !supportLists]>- &nb= sp; <![endif]>з = 72;траты на создание программныm= 3; компонентоk= 4;, обеспечиваn= 2;щих базовые свойства функционалn= 0;ной пригодностl= 0; комплекса п = 88;ограмм для его прим= 077;нения по прямому назначению пользоватеl= 3;ями, в соответст = 74;ии с требованияl= 4;и контракта и техническоk= 5;о задания;<o:p></o:p> <p class=3DMsoBodyTextIndent2 style=3D'margin:0cm;margin-bottom:.0001pt;tex= t-align: justify;text-indent:35.45pt;line-height:normal;mso-pagination:none;mso-list: l135 level1 lfo141;tab-stops:list 14.2pt'><![if !supportLists]>- &nb= sp; <![endif]>о = 89;новные составляющl= 0;е дополнителn= 0;ных затрат, обеспечиваn= 2;щие требуемые конструктиk= 4;ные характерисm= 0;ики качества дл= 03; улучшения функционалn= 0;ной пригодностl= 0; ПС в соответствl= 0;и с целями и сферой его применения. <o:p></o:p> Кр= оме того, следуе= 090; учитывать совокупносm= 0;ь затрат ресурсов на технологию, = 080;нструмента&= #1088;ий автоматизаm= 4;ии разработки = 80; систему качества, обеспечиваn= 2;щие жизненный цикл ПС. Эта составляющk= 2;я затрат зависит не только от характерисm= 0;ик проектируеl= 4;ого ПС, но и от интенсивноl= 9;ти применения технологичk= 7;ских средств (см. рис. 9.1). = <o:p></o:p> За= траты на обеспечениk= 7; функционалn= 0;ной пригодностl= 0; зависят, в первом приближениl= 0;, от сложност = 80; алгоритмов, объема комп = 83;екса программ и баз данных, которые опр = 77;деляют затраты труда и длительносm= 0;ь полного цикла их разработки. Основные затра= ;ты идут на овеществлеl= 5;ный, преимущестk= 4;енно, интеллектm= 1;альный труд специа = 83;истов различных категорий. Поэтому для иm= 3; измерения наиболее универсальl= 5;ой единицей ст = 72;ли трудозатраm= 0;ы специалистl= 6;в в человеко-дн= 03;х или человеко-ме = 89;яцах, которые обычно дост = 72;точно просто могу = 90; преобразовm= 9;ваться в стоимость процесса разработки. <o:= p></o:p> &nb= sp; Для учета классов крупномасшm= 0;абных ПС с позиции затрат на их разработку проведено ранжированl= 0;е эксперименm= 0;альных данных и выд= 077;лены классы (см. ISO<= span style=3D'font-size:14.0pt'> 12182), наиболее сильно отличающиеl= 9;я затратами н = 72; функционалn= 0;ную пригодностn= 0;, при одном и том же общем размере пол = 85;остью новых программ и информации баз данных, которые характеризm= 1;ются (см. лекцию 5):<o:p></o:p><= /span> <![if !supportLists]>- &nb= sp; <![endif]>м = 72;ксимальной трудоемкосm= 0;ью - ПС систем управления динамическl= 0;ми объектами или процессами = 74; реальном време= ;ни (СРВ);<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>с = 88;едней трудоемкосm= 0;ью - ПС администрk= 2;тивных, организациl= 6;нных и инфор= ;мационно-по= 080;сковых систем (ИПС);<o:p></o= :p> <![if !supportLists]>- &nb= sp; <![endif]>м = 80;нимальной трудоемкосm= 0;ью созда= ;ния - пакеты автономных расчетных п = 88;икладных программ (ППП).<o:p></o:p> Все остальные типы ПС могу= 090; быть упорядоченm= 9; между выдел = 77;нными классами и для них получен = 99; оценки изменения трудоемкосm= 0;и (стоимости) относительl= 5;о максимальнl= 6;й для ПС реального в = 88;емени. Малые проекты, создаваемыk= 7; небольшими коллективаl= 4;и специалистl= 6;в характеризm= 1;ются большим коэффициенm= 0;ом вариации – разбросом значений п = 88;едполагаем&#= 1086;й трудоемкосm= 0;и, вследствиk= 7; высокой рол = 80; индивидуалn= 0;ных способностk= 7;й отдельных специалистl= 6;в. Трудоемкосm= 0;ь разработки крупномасшm= 0;абных ПС объемом с= 074;ыше 100 тыс. строк отражается более определеннm= 9;ми закономернl= 6;стями и стабильнымl= 0; значениями, что обусловленl= 6; усреднениеl= 4; творческих возможностk= 7;й специалистl= 6;в и условий их труда в больших коллективаm= 3;, а также возрастаниk= 7;м доли затрат = 080; роли руково = 76;ящего и вспомогатеl= 3;ьного персонала в ЖЦ ПС.<o:p></o:p> Основные составляющl= 0;е дополнителn= 0;ных затрат, обеспечиваn= 2;щие требуемые х = 72;рактеристи&#= 1082;и качества ПС целесообраk= 9;но структурирl= 6;вать в соответст = 74;ии с их номенкл= 072;турой в стандарте </s= pan>ISO<= span style=3D'color:windowtext'> 9126 (см. лекцию 11). Однако желательно эти затраты связать с процессами ЖЦ ПС. Важней&#= 1096;ее значение имеет устан = 86;вление и формализацl= 0;я исходных требований = 82; характерисm= 0;икам ПС. По= 01;тому целесообраk= 9;но выделять значительнm= 9;е ресурсы на системный анализ и про= 077;ктирование требований ко всему комплексу х = 72;рактеристи&#= 1082; и их атрибут= 099; на начальны = 93; этапах проекта ПС (см. рис. 9.1). На этих этапах неопределеl= 5;ность оценки влияния факторов наибольшая, тем не менее даже приблизитеl= 3;ьный их учет позволяет избегать грубых ошибок (в несколько раз) при оцен&#= 1082;е затрат на разработку, = 082;оторые делаются экспертами без детального анализа влияния различных факторов на = 090;ребуемое качество ПС. Подобный анализ може = 90; быть базой для рациона = 83;ьного, первичного распределеl= 5;ия ограниченнm= 9;х ресурсов разработки = 80; для управле = 85;ия их использоваl= 5;ием по мере разв= 080;тия проекта. Уче= 090; возможного = 80;зменения затрат в зависимостl= 0; от основных = 087;араметров проекта способствуk= 7;т упорядоченl= 0;ю процесса разработки ПС и концент= 088;ации усилий на те= 093; факторах и затратах, ко= 090;орые могут дать максимальнm= 9;й эффект в повышении качества, пр= 080; конкретных условиях со = 79;дания программ и реальных ограничениn= 3;х ресурсов. <o:p></o:p></span= > После проведения системного = 87;роектирова&#= 1085;ия, а также пред= 074;арительног&= #1086; распределеl= 5;ия ресурсов, возможна ошибка в оце= 085;ке совокупных затрат на разработку ПС с требуемым к = 72;чеством, приблизитеl= 3;ьно в полтора-дв= 072; раза. Разработка архитектурm= 9; комплекса п = 88;ограмм на основе прототипов = 80; подготовка = 82; программиl= 8;ованию готовых апр = 86;бированных алгоритмов позволяет е = 77; уменьшить д = 86; 20-30%. Такую достоверноl= 9;ть можно получить, ко= 085;ечно, только при п= 086;дробном анализе и оценке влия = 85;ия важнейших факторов и требований = 82; качеству конкретногl= 6; ПС (см. лекцию = 5).<o:p></o:p> Крупные затраты, достигающиk= 7; 30% от полных затрат на разработку сложных ПС, могут приходитьсn= 3; на верифика = 94;ию и тестированl= 0;е программныm= 3; компонентоk= 4;, что должно обеспечиваm= 0;ь корректносm= 0;ь и надежност= 00; ПС в целом. Хотя эти характерисm= 0;ики и их атрибут= 099; принципиалn= 0;но различаютсn= 3;, ресурсы на и= 093; реализацию полностью разделить н = 77;возможно. Поэтому оценивание = 80; выделение р = 77;сурсов на решение этих задач целесообраk= 9;но анализировk= 2;ть совместно. <o:p></o:p= > Затраты на квалификацl= 0;онное тестированl= 0;е и испытания ПС в целом обычно могу = 90; быть достаточно четко выделены из остальных ресурсов, та= 082; как в этих процессах непосредстk= 4;енно участвуют заказчик и пользоватеl= 3;и. Величина этих затрат, без учета ре= 089;урсов, необходимыm= 3; для имитаци = 80; внешней среды, может составлять около 10% от общих затра = 90; на разработ = 82;у. При этом практическl= 0; невозможно разделять затраты на о= 094;енивание отдельных стандартизl= 0;рованных характерисm= 0;ик и их атрибут= 086;в. <o:p></o:p> Затраты на обеспечениk= 7; безопасносm= 0;и и надежност = 80; функционирl= 6;вания ПС определя= 02;тся требуемым уровнем защищенносm= 0;и и сложность= 02; (размером) программ дл= 03; ее реализац = 80;и (см. лекцию 11). При наличии осо = 73;енно высоких требований = 82; безопасносm= 0;и критическиm= 3; ПС эти затра= 090;ы могут даже в 2 – 4 раза превышать затраты на решение базовых, функционалn= 0;ных задач. Для типовых администраm= 0;ивных систем труд = 86;емкость создания программныm= 3; средств защиты обыч = 85;о составляет 20 – 40% затрат на решение основных, функционалn= 0;ных задач. В более прос = 90;ых случаях, доля таких затра = 90; может снижа = 90;ься до 5 – 10%.= Затраты на = 086;беспечение высокой надежности в составе ра = 79;работки ПС могут достигать 2 – 3 кратного увеличения общих затрат, при высок= ;их требованияm= 3; наработки н = 72; отказ. Для ми&#= 1085;имального обеспечениn= 3; автоматичеl= 9;кого рестарта в о= 088;динарных системах он = 80; составляют порядка 10 – 20%. Однак= ;о практическl= 0;, в любых сист= 077;мах должен присутствоk= 4;ать минимум про = 75;раммных компонентоk= 4;, обеспечиваn= 2;щих надежность = 80; защиту от пр= 077;днамеренны&= #1093; и слуm= 5;айных угроз.<o:p></o:p> <s= pan style=3D'mso-no-proof:yes'>Затраты= ; на создание доста= точно полного </spa= n>комплект= ;а докумен- тации= практичесl= 2;и пропо= рциональны размеру комплекса = 87;рограмм= ;. Удель= ные затра= ты на документацl= 0;ю завис= ят от класса, = 85;азначен= ;ия и широты l= 7;рименен= ;ия прогр= амм, что тр= ;удно учест= ь в достаточ= ;но общем= виде. Эти затраты сопутств= ;уют в некоторой = 89;тепени </spa= n>всем этапа= м разра= ботки, однак= о, оформ= ление эксплуатацl= 0;онных доку- менто= в обычн= о локал= изуется в спец= и-альном э= тапе работ. Затраты на разработ= ;ку комплекта эксплуатаци= 086;нной докум= ентации для </span= >сложных программныm= 3; продуктов , подле= жащих дл&= #1080;-тельному</spa= n> с= опровожденl= 0;ю, обычн= о опред= еляются затра= тами ориентир-ов = 86;чно 5 – 10 страниц </spa= n>на тысячу строк текст= а прогр= аммы. <o:p></o:p> <h2 style=3D'margin:0cm;margin-bottom:.0001pt;text-align:justify;text-inden= t: 35.45pt;line-height:normal'>Достато= 095;но определеннl= 6; могут быть выделены и оценены зат = 88;аты на обеспече = 85;ие и реализаци= 02; требований = 82; характерисm= 0;икам: защищенносm= 0;и, сопровоk= 8;даемости, мобильностl= 0; и практичносm= 0;и (последние в части документирl= 6;вания) ПС. Эти затра&#= 1090;ы состоят из двух связанных частей: затр= 072;т на реализацию соответствm= 1;ющих характерисm= 0;ик качества в программныm= 3; продуктах и затрат при и= 089;пользовани&= #1080; этих характерисm= 0;ик в процессе эксплуатацl= 0;и комплекса программ. Обычно совершенстk= 4;ование качества и повышение затрат на реализацию = 93;арактерист&#= 1080;к способствуk= 7;т снижению затрат при и= 093; эксплуатацl= 0;и. Последние трудно оцен = 80;ть априори, так как они зависят от внешней сре = 76;ы и активност = 80; применения конкретногl= 6; ПС, а не от его свойств и требуемого качества. Поэтому дал = 77;е основное внимание акцентировk= 2;но на затратах, которые необходимы для достиже = 85;ия требуемых характерисm= 0;ик качества. <o:p></o:p></span= ></h2> При анализе затрат на обеспечениk= 7; требуемых функций крупномасшm= 0;абных ПС доминиру= 02;щим фактором, влияющим на их величину, является сложность ф = 91;нкциональн&#= 1086;й части комплекса программ и базы данных.<sp= an style=3D'mso-spacerun:yes'> Понятие сложности программ ак = 90;ивно исследовалl= 6;сь последние д = 77;сятилетия, и предложен ряд показат = 77;лей и методов дл= 103; ее измерени= 03;. Наибольшее внимание исследоватk= 7;лей привлекала статистичеl= 9;кая мера сложно = 89;ти и мера структурноl= 1; сложности программ. Дл= 103; относительl= 5;о небольших программ эт = 80; методы позволили повысить достоверноl= 9;ть определениn= 3; сложности программ и установить адекватносm= 0;ь этого показ = 72;теля величине трудоемкосm= 0;и их создания. Однако для П= 057; средней и вы= 089;окой сложности ряд дополнителn= 0;ных факторов затрудняет подобные оц = 77;нки. В крупныm= 3; ПС обычно реал = 80;зуются задачи различной сложности. При наличии особо сложной функционалn= 0;ной задачи возрастаниk= 7; затрат на ее реализацию = 84;ожет нивелироваm= 0;ься рядом други = 93; типовых и более простых задач. Поэтому пок = 72; не проявили = 89;ь преимущестk= 4;а приведенныm= 3; мер сложнос = 90;и и они не нашли широкого практическl= 6;го применения.<o:p= ></o:p> = Наиболее активно в качестве простейшегl= 6; показателя сложности используетl= 9;я размер – масштаб комплекса п = 88;ограмм, выраженный числом операторов (команд) или строк текст = 72; на языке программирl= 6;вания (с учетом коэффициенm= 0;а, зависящего от класса ПС и специфики языка) (см. лекцию 5). Размер про = 75;рамм без комментариk= 7;в является од = 85;ой из наиболее достоверно измеряемых = 93;арактерист&#= 1080;к сложности П = 57; и достаточн = 86; адекватен экономичесl= 2;им затратам на его разрабо = 90;ку. Реальное изменение создаваемыm= 3; в настоящее время новых сложных ПС объемом от 103</= sup> до 106 строк определяет диапазон трудоемкосm= 0;и разработки таких программ от человеко-го = 76;а до тысяч человеко-ле = 90;. С друk= 5;ой стороны, отсутствуюm= 0; какие-либо данные о значительнl= 6;м преимущестk= 4;е других дост = 72;точно простых мер сложности при прогнозироk= 4;ании ресурсов на разработку крупномасшm= 0;абных ПС. <o:p></o:p> Ограниченl= 5;ые ресурсы вре = 84;ени реализации проектов ПС являются одним из самых сильных факторов, влияющих на достижимое качество комплексов программ. Из= 073;ыточный оптимизм многих разработчиl= 2;ов и давление заказчиков относительl= 5;о сроков реализации контрактов на ПС, негативно отражается, прежде всег = 86;, на характерисm= 0;иках качества ПС. Поэтому при выборе и формализацl= 0;и в контракте значений требуемых характерисm= 0;ик качества ПС, особое вним = 72;ние следует обращать на возможностn= 0; их достигну = 90;ь в согласова = 85;ные сроки. Чем сложнее комплекс программ, а с&#= 1086;ответствен= но, чем выше в нем вероятностn= 0; ошибок и деф= 077;ктов, тем больше времени требуется для их устранения = 80; на весь процесс разработки. При реальном допустимом времени реализации проекта, оно ограничиваk= 7;т затраты на все промежуточl= 5;ые этапы работ, и тем самым на качество их выполнен = 80;я. <o:p></o:p> Пр= и современныm= 3; технологияm= 3; полностью н = 86;вые, крупномасшm= 0;абные комплексы программ, реализуемыk= 7; в допустимо = 77; время= ; 2 – 4 года, ограничены объем= ;ом 106 = - 10 7 стро= 082; текста. Выше отмечалось (см. лекцию 5), что диапазону размеров со = 74;ременных ПС в три-четыре порядка (до 10 млн. строк) соответствm= 1;ют приблизитеl= 3;ьно такие же диапазоны изменения трудоемкосm= 0;и и стоимости их разработ = 86;к. Очевидна принципиалn= 0;ная нерентабелn= 0;ность разработки очень сложн = 99;х ПС за= 5 -</span= > 10 лет. С другой стороны, даж= 077; относительl= 5;о небольшие программы высокого качества в несколько тысяч строк по полному технологичk= 7;скому циклу с сертификацl= 0;онными испытаниямl= 0; продукции = 88;едко создаются з = 72; время, меньшее, чем полгода = - год. Таким образом, диапазон вариации длительносm= 0;ей разработок ПС много меньше, чем вариация их трудоемкосm= 0;и, а эти длител= 100;ности ограничены сверху и снизу, и объем новых программ яв = 83;яется одним из осн= 086;вных факторов, определяющl= 0;м эти границы.<o:= p></o:p> Размер баз = 99; данных ПС в некоторой с = 90;епени коррелировk= 2;н с размером текстов программ. Эт= 086; привело к тому, что в ряде эконом = 80;ческих исследованl= 0;й размер базы данных либо совсем не учитывался, либо включа = 83;ся в объем ПС. В статистичеl= 9;кой теории слож = 85;ости программ показано, чт= 086; для программныm= 3; модулей и относительl= 5;о небольших групп программ имеется корреляция числа имен переменных = 80; операторов = 74; программе. О= 076;нако для крупl= 5;ых ПС корреляц = 80;я может быть меньше. Это определило необходимоl= 9;ть разделения ПС на два типа: на осущ&#= 1077;ствляющие преимущестk= 4;енно сложную логическую обработку о = 90;носительно небольшого = 87;отока данных и на информациоl= 5;но-поисковы&#= 1077; системы при наличии бол= 00;ших объемов информации баз данных и <s= pan class=3DGramE>при относительl= 5;о простой их обработк = 77;. Степень этого влияния тру = 76;но формализовk= 2;ть, так как большую рол= 00; играет структура базы данных = 080; ее функционалn= 0;ное назначение. = 055;оэтому обычно этот фактор отдельно не учитываетсn= 3; и только для очень больших и сложных структур ба = 79; данных рекомендуеm= 0;ся увеличиватn= 0; оцениваемуn= 2; трудоемкосm= 0;ь разработки.<o:p= ></o:p> = <o:p></o:p> <h1> = <a name=3D"_Toc508102483"></a><a name=3D"_Toc508102256">9.4.&= nbsp; Ресурсы на реализациn= 2; конструктиk= 4;ных характерисm= 0;ик качес= ;тва программныm= 3; средств</a> </h1> <o:p> </o= :p> Им= еющийся опыт показывает, что кроме функционалn= 0;ной пригодностl= 0; и мобильнос = 90;и большинствl= 6; факторов может изменять тр = 91;доемкость процессов разработки программ на десятки про = 94;ентов и не более чем в 2 -</span= > 3 раза. Приводимыk= 7; ниже экспертные = 86;ценки относятся = 82; разработке полностью нового, круп= 085;ого ПС, без использоваl= 5;ия готовых про = 75;раммных компонентоk= 4;. Эти оценки могут служи = 90;ь ориентирамl= 0;, которые должны напо = 84;инать разработчиl= 2;ам, что каждое повышение требований = 82; качеству ПС реализуемо за счет дополнителn= 0;ных ресурсов, которые могут быть с= 086;измеримыми или даже превышать затраты на р= 077;шение основных, функционалn= 0;ных задач. = <o:p></o:p> = Анализ затрат на обеспечениk= 7; корректносm= 0;и зависит от полноты прослеживаl= 5;ия реализации требований = 82; ПС сверху вн= 080;з, в требовани= 03;х к компонент = 72;м вплоть до объектного кода программ и о= 090; степени их п= 086;крытия тестами. Эти затраты входят непо = 89;редственно в процесс разработки = 80; зависят от объема и дет= 072;льности процессов верификациl= 0; и тестирова = 85;ия. Для с= ;ложных ПС при требовании их высокой корректносm= 0;и они могут составлять = 76;о 30% от затрат на обеспечениk= 7; первичной, функционалn= 0;ной пригодностl= 0;. Для относительl= 5;о простых комплексов программ эт = 72; величина в среднем не превышает 20%.<o:p></= o:p> = Затраты на взаимодейсm= 0;вие программныm= 3; средств и их компонентоk= 4; с внутренне = 81; и внешней средой определяютl= 9;я сложностью (объемом) программ и затратами производитk= 7;льности ЭВМ, реализу= 102;щими эти функции. Они включаю = 90; затраты на визуализацl= 0;ю информации, обеспечиваn= 2;щей функционалn= 0;ную пригодностn= 0;, телекоммунl= 0;кацию с внешними абонентами системы и с операционнl= 6;й системой и могут соста = 74;лять 10 – 20% затрат на обеспечениk= 7; основных функций ПС.<o:p></o:p= > <s= pan style=3D'mso-spacerun:yes'> Особенносm= 0;и затрат на реализацию остальных требований = 82; конструктиk= 4;ным характерисm= 0;икам качества отмечаются при предста = 74;лении соответствm= 1;ющих характерисm= 0;ик (см. лекцию 11) и сво= ;дятся к следующем = 91;:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>д = 86;полнительн&#= 1099;е затраты на обеспечениk= 7; высокой над = 77;жности ПС могут дост = 80;гать 2 – 3 кратного увеличения затрат относительl= 5;о функционалn= 0;ной пригодностl= 0; при требованияm= 3; наработки на отказ в десятки тысяч часов, а для минимальноk= 5;о обеспечениn= 3; автоматичеl= 9;кого рестарта в ординарных системах со = 89;тавляют порядка 10 – 20%;<o:p></o:p= > <![if !supportLists]>- &nb= sp; <![endif]>д = 83;я повышения эффективноl= 9;ти использоваl= 5;ия ресурсов ЭВ = 52; затраты могут быть относительl= 5;о невелики (несколько процентов) и их трудно вы= 076;елить из затрат на решение основных, функционалn= 0;ных задач;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;траты на обеспечениk= 7; практичносm= 0;и зависят в основном от сложности применения ПС, от качества и количества эксплуатацl= 0;онной документацl= 0;и и электронныm= 3; учебников и могут составлять до 20% затрат на решение основных, функционалn= 0;ных задач. <o:p></o:p> Стремлениk= 7; уменьшить затраты в период разработки без учета последующеk= 5;о испол= ;ьзования ПС, его компо= ;нентов и всего жизн= 077;нного цикла может оказаться мало полезн = 99;м, а в некоторых случаях привести к значительl= 5;ому увеличению совокупных = 79;атрат в ЖЦ. При применении сложных ПС эти затраты исчисляютсn= 3; сотнями человеко-ле = 90;, что определ= 03;ет особую актуальноl= 9;ть снижения этих k= 9;атрат. Поэтому необходим с = 80;стемный анализ распределеl= 5;ия и испl= 6;льзования ресурсов н = 72; разработку программ с у= 095;етом всего их жизненного цикла, включая соп = 88;овождение и перенос на другие платформы. При использ = 86;вании приведенныm= 3; данных, необходимо учитывать, что они могу= 090; служить только ориентирамl= 0; при приближ = 77;нной оценке затрат на непосредстk= 4;енную разработку = 80; обеспечениk= 7; качества ко = 85;кретного ПС. <o:p></o:p> </spa= n>Сопровож = 76;аемость ПС можно оценивать потребностn= 0;ю трудовых и временных ресурсов дл= 03; ее обеспече = 85;ия и для реализ= 072;ции. Возможные затраты рес = 91;рсов на развитие = 080; совершенстk= 4;ование качества комплекса программ зависят не только от внутренних свойств программ, н= 086; также от запросов и потребностk= 7;й пользоватеl= 3;ей на новые функции и от готовности заказчика и разработчиl= 2;а удовлетворl= 0;ть эти потребностl= 0; (см. лекцию 15). <o:p></o:p> В современныm= 3; проектах ПС большую или меньшую дол= 02; составляют готовые апробироваl= 5;ные компоненты = 80;з других подобных разработок R= 11; прототипы и/или покупн= 099;е пакеты прикладных программ. Эт= 086; позволяет значительнl= 6; ускорять работы и сок= 088;ащать затраты на создание сложных комплексов программ. Перед= ; разработчl= 0;ками проекта ПС зачастую возникает дилемма: разрабатывk= 2;ть ли весь комплекс программ по = 83;ностью из новых компонентоk= 4; или использ = 86;вать, адаптироваm= 0;ь и приспосаб = 83;ивать готовые ком = 87;оненты, какие и в каком количестве. = 042; результате при первичном экономичесl= 2;ом анализе рес = 91;рсов на создание ПС с требуем= 099;ми характерисm= 0;иками качества, целесообраk= 9;но рассматривk= 2;ть два альтерн = 72;тивных варианта определениn= 3; затрат на разработку:<o:p= ></o:p> <![if !supportLists]>- = &nb= sp; <![endif]>&#= 1087;олностью нового ПС, для которог = 86; отсутствуюm= 0; или недоступны подходящие готовые компоненты R= 11; прототипы и/или их заведомо нерентабелn= 0;но использоваm= 0;ь;<o:p></o:p> <![if !supportLists]>-&nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; <![endif]>програм= ;много продукта на базе компле = 82;сирования набора готовых программныm= 3; компонентоk= 4; и информаци = 80; баз данных, для которог = 86; почти не требуется создания но = 74;ых компонентоk= 4;.<o:p></o:p> = Мобильносm= 0;ь и затраты ко= 085;кретных ресурсов дл= 03; переноса программ и д= 072;нных на иные аппаратные = 80; операционнm= 9;е платформы при проектировk= 2;нии могут быть учтены, только очен= 00; приблизитеl= 3;ьно. Эти субх = 72;рактеристи&#= 1082;и включают адаптируем&#= 1086;сть, простоту установки и <sp= an class=3DSpellE>замещаем = 86;сть программ, ко= 090;орые целесообраk= 9;но оценивать количествеl= 5;но: совокупнымl= 0; затратами, стоимостью, трудоемкосm= 0;ью и длительносm= 0;ью на реализац = 80;ю процедур переноса прогр= ;амм и данных. Оценки мобильностl= 0; зависят не только от вн= 091;тренних субхараl= 2;теристик ПС, но также от организа = 94;ии, технологии = 80; документирl= 6;вания реализации жизненного цикла и процессов переноса комплексов программ и и= 093; компонентоk= 4; (см. лекцию 15). <o:p></o:p= > При переносе программ и данных свойства систем практическl= 0; всегда изменяются, что следует учитывать при системном а = 85;ализе целесообраk= 9;ности и эффективноl= 9;ти переноса, а также могут быть необходимы = 90;естировани&#= 1077;, испытания и сертификацl= 0;я получаемых ПС в новой среде. Кроме того, любой перенос связан с затратами. При создани= ;и мобильных П = 57; трудно предусмотрk= 7;ть все возможн = 99;е особенност= и и различия платформ и внешней среды, для которых декларируе= тся мобильностn= 0; конкретных программныm= 3; средств. Эти особенностl= 0; и возможное расширение свойств окружающих прикладных программ и данных могу = 90; преподносиm= 0;ь неприятные сюрпризы не = 89;тыковки, для ликвида = 94;ии которых потребуютсn= 3; дополнителn= 0;ные ресурсы. Требования мобильностl= 0; компонентоk= 4; ПС приводят = 082; необходимоl= 9;ти их проектироk= 4;ания как автоном = 85;ых комплектуюm= 7;их изделий. Это реализуетсn= 3; за счет стан= 076;артизации их построения = 80; организациl= 0; интерфейсоk= 4;, унификации структуры базы данных = 080; гарантии качества функционирl= 6;вания. В результат = 77; подготавлиk= 4;ается возможностn= 0; создание новых ПС из набора готовых про = 75;раммных модулей или функционалn= 0;ных групп программ, ранее использоваl= 5;ных и испытанны = 93; в другом сочетании при решении = 085;есколько иных функци = 86;нальных задач. Однак= 086; в любом комплексе п = 88;ограмм вряд ли возможно и нужно повторно ис = 87;ользовать все 100% готовых программныm= 3; модулей. При сборке нового ПС из комплектуюm= 7;их компонентоk= 4;, может= ; потре= ;боваться доработка некот= ;орых из них, или создание специальныm= 3; программ, для их взаимодейсm= 0;вия.<o:p></o:p> В ряде случаев целесообраk= 9;на настройка - адаптация готовых ком = 87;онентов на новые условия применения. При больших изменениях условий при = 84;енения, эффективноl= 1; может оказаться сборка нового ПС с частичным использоваl= 5;ием апробироваl= 5;ных компонентоk= 4; и с разработкоl= 1; небольшой части прогр = 72;ммных модулей, обеспечиваn= 2;щих новые функц = 80;и, интерфейсы = 80; условия применения ПС. При этом относительl= 5;ое снижение за = 90;рат пропорционk= 2;льно доле исполь = 79;ования готовых комплектуюm= 7;их компонентоk= 4; и степени их пригодностl= 0; для использ = 86;вания в новом ПС. В пределе при построении нового ПС н= 072; 80 - 90% из готовых компонентоk= 4; суммарные затраты мог = 91;т сокращатьсn= 3; в 3 - 5 раз. В этом случае, кроме 10 <span style=3D'font-size:14.0= pt; font-family:Symbol;mso-ascii-font-family:"Times New Roman";mso-hansi-font-f= amily: "Times New Roman";color:windowtext;mso-char-type:symbol;mso-symbol-font-fam= ily: Symbol'>= - 20% затрат на создание новых программныm= 3; компонентоk= 4;, необходимы ресурсы на комплексирl= 6;вание нового ПС, его квалификацl= 0;онное тестированl= 0;я, испытания и документирl= 6;вание. <o:p></o:p> = Практичесl= 2;и всегда необ = 93;одимо время и трудоемкосm= 0;ь на системны = 81; анализ, и оценивание целесообраk= 9;ности разработки комплекса программ из = 075;отовых компонентоk= 4; с учетом стоимости приобретенl= 0;я и адаптации переносимыm= 3; программ. Интегрироk= 4;ание компонентоk= 4; в новой операционнl= 6;й среде, тестироваl= 5;ие и испытания = 074; комплексе с унаследоваl= 5;ными программамl= 0;, также почти всег = 76;а требует времени и других ресу = 88;сов. Некоторые, казалось бы, второстепеl= 5;ные, детали и факторы не = 89;овместимос&#= 1090;и готовых, пе= 088;еносимых программ и новой платформы могут заметно отражаться на трудоемк = 86;сти проекта. Особенно тщательно и = 93; следует анализироk= 4;ать в унаследоваl= 5;ных систе= ;мах, в котl= 6;рых относительl= 5;о мелкие детали взаи = 84;одействия новых и старых программ могут= ; сущес= ;твенно влиять на экономичеl= 9;кие характерисm= 0;ики проекта. <o:p></o:p> Обычно наиболее важным для р= 077;ализации проекта и завl= 0;сящим от большинстk= 4;а его особенностk= 7;й и факторов я= 074;ляется трудоемкосm= 0;ь, непосредсm= 0;венно определяющk= 2;я стоимость создаваемl= 6;го комплекса п = 88;ограмм. Значения длительносm= 0;и разработки = 80; числа специалистl= 6;в взаимосвязk= 2;ны и в некоторы= 093; пределах могут разме = 85;иваться. Поэтому оценки этих показ= ;ателей можно варьироватn= 0;, и при недост= 072;точном числе специ = 72;листов естественнl= 6; возрастает длительносm= 0;ь разработки, хотя трудое = 84;кость может остаться пр = 72;ктически неизменной. Многократнl= 6;е применение одних и тех же апробироваl= 5;ных компонентоk= 4; и/или многократнk= 2;я адаптация П = 57; к различным условиям применения является од = 85;им из самых пер= 089;пективных методов повышения качества и снижения затрат труд = 72; специалистl= 6;в в жизненном цикле крупномасшm= 0;абных комплексов программ.<o:p></o:p>= <o:p> </o= :p> <h1><a name=3D"_Toc508102484"></a><a name=3D"_Toc508102257">9.5. Ресурсы на имитацию внешней среды для об= 077;спечения те&#= 1089;тирования и испытаний программныm= 3; средств</a></h1> = <o:p></o:p> При создании крупных ПС, одной из больших составляющl= 0;х могут быть н= 077;обходимые ресурсы на генерацию т = 77;стов. В ряде случаев они соизмеримы = 89; затратами н = 72; создание основных функций комплексов программ, чт= 086; определяетl= 9;я принципиалn= 0;ным соответствl= 0;ем сложности необходимыm= 3; наборов тес = 90;ов и тестового покрытия программ, и сложности функций, реализуемыm= 3; испытываемm= 9;м ПС. Создание представитk= 7;льных совокупносm= 0;ей тестов возможно путем испол= 00;зования реальных объектов внешней сре = 76;ы или с помощь= 102; программныm= 3; имитаторов, адекватных этим объектам по результатаl= 4; функционирl= 6;вания и генерируе = 84;ой информации. При этом возникает проблема = - какой метод и когд= 072; выгодней по затратам на генерацию тестов и по обеспечениn= 2; необходимоl= 1; степени пок = 88;ытия тестами испыт= ;ываемых ПС (см. лекцию = 14).<o:p></o:p> = Имитаторы тестов необходимы не только дл= 103; оценивания = 76;остигнутых характерисm= 0;ик качества комплексов программ, но также для их комплексноl= 1; отладки, квалификацl= 0;онного тестированl= 0;я, испытаний и <sp= an class=3DGramE>при создания версий. Поэтому затраты на п= 088;ограммные имитаторы и их экономич = 77;скую эффективноl= 9;ть целесообраk= 9;но рассматривk= 2;ть в проекте с учетом всег = 86; комплекса задач, которые они способны и должны решать в ЖЦ ПС. Анализ эффективноl= 9;ти программноl= 1; имитации внешней сре = 76;ы при разработке = 80; определениl= 0; качества ПС целесообраk= 9;но разделить н = 72; две части: оценка факторов, определяющl= 0;х эффективноl= 9;ть средств имитации те = 89;тов, и оценка экономичесl= 2;ого выигрыша пр = 80; моделирова&= #1085;ии внешней среды на ЭВМ по сравнени= 02; с натурными эксперименm= 0;ами в реальных с= 080;стемах.<o:p></o:p> = Факторы, определяющl= 0;е эффективноl= 9;ть программноl= 1; имита= ;ции внешней сре = 76;ы на ЭВМ при разработке ПС, могут оцениватьсn= 3; в основном п= 086; их воздействиn= 2; на качество создаваемыm= 3; программ. Эт= 086; влияние трудно непосредстk= 4;енно измерить, од= 085;ако качественнm= 9;й анализ пока = 79;ывает, что автоматизиl= 8;ованная имитация мо = 78;ет значительнl= 6; изменять не только достигаемыk= 7; характерисm= 0;ики качества разрабатывk= 2;емого ПС, но также т&= #1088;удоемкость и длительносm= 0;ь его создани= 03;. Программнаn= 3; имитация внешней сре = 76;ы на ЭВМ может обеспечиваm= 0;ь широкие наб = 86;ры тестов и дос= 090;аточно полные тест = 86;вые покрытия ПС = 080; компонентоk= 4; при испытан = 80;ях, в том числе за пределами характерисm= 0;ик реально сущ = 77;ствующих или доступн = 99;х источников тестов, а также соответствm= 1;ющие критическиl= 4; или опасным ситуациям функционирl= 6;вания объектов внешней среды. Для каждого пар = 72;метра, отражающегl= 6; внешнюю среду, отношение диапазона или числа тестов, возможных п = 88;и программноl= 1; имитации на ЭВМ по сравнению с натурными эксперименm= 0;ами, может служи = 90;ь оценкой величины, возрастаниn= 3; достоверноl= 9;ти определениn= 3; характерисm= 0;ик качества ПС.<o:= p></o:p> &nb= sp; При тестированl= 0;и необходимо учитывать н = 77; только соот = 85;ошение размеров об = 83;астей изменения параметров тестов, но и распределеl= 5;ие вероятностk= 7;й значений каждого пар = 72;метра в этих областях дл= 03; реальных и п= 077;рспективны&= #1093; объектов внешней среды. Некот= 086;рые значения те = 89;тов не только трудно создать при натурных эксперименm= 0;ах, но они являю= 090;ся маловероятl= 5;ыми в реальных условиях. Однако таки = 77;, даже маловероятl= 5;ые ситуации и значения тестов могу = 90; быть критическиl= 4;и и/или особо важными для функционирl= 6;вания всей систем = 99;, для которой разрабатывk= 2;ется ПС. Выбор и имитация подобных ситуаций позволяют отрабатываm= 0;ь и оценивать качество ПС = 074; критическиm= 3; маловероятl= 5;ых ситуациях, которые невозможно или опасно создавать н = 72; реальных объектах, но без их выпол= 085;ения некоторые П = 57; не допустимо = 01;ксплуатиро&#= 1074;ать в критическиm= 3; системах уп = 88;авления и обработки информации. <o:= p></o:p> Э= 082;ономическу&= #1102; эффективноl= 9;ть программноl= 1; имитации внешней среды на ЭВМ по сравнени= 02; с натурными эксперименm= 0;ами целесообраk= 9;но оценивать при одинаковых объемах тестовых данных для испытаний и определениn= 3; качества ПС.<sp= an style=3D'mso-spacerun:yes'> Показ= ;ателем экономичесl= 2;ой эффективноl= 9;ти имитации может служи = 90;ь соотношениk= 7; затрат ресурсов на проведение натурных эксперименm= 0;ов и затрат на программнуn= 2; имитацию то = 81; же совокупн = 86;сти тестовых и эталонных данных. <o:p></o:p> Затраты ресурсов на натурные эксперименm= 0;ы для генерац = 80;и тестов при проведении разработки, испытаний и определениn= 3; качества пр = 86;порциональ&#= 1085;ы реальному времени функционирl= 6;вания проверяемоk= 5;о ПС и затратам на применение привлекаемm= 9;х средств реа = 83;ьной внешней среды. Они включают стоимость э = 82;сплуатации реального объекта, соз= 076;ающего тесты в единицу времени (напрl= 0;мер, затраты на функционирl= 6;вание администраm= 0;ивной системы, прокатного стана или системы управления воздушным движением и всех управляемыm= 3; ею объектов). Таким образ = 86;м, затраты на натурные эксперименm= 0;ы для оценива = 85;ия характерисm= 0;ик ПС определя= 02;тся использоваl= 5;ием всей реальной вн = 77;шней среды, в которой пре = 76;стоит в дальнейше = 84; функционирl= 6;вать программам, а также затра = 90;ами на средства измерения характерисm= 0;ик этой среды и проверяемоk= 5;о ПС в процесс= 077; разработки, испытаний и определениn= 3; качества.<o:p></o:p>= &nb= sp; Затраты на программнуn= 2; имитацию тестовых данных определяютl= 9;я ресурсами необходимыl= 4;и на проектир = 86;вание и эксплуатацl= 0;ю сложных комплексов программ дл= 03; этих целей и<sp= an style=3D'mso-spacerun:yes'> следующимl= 0; составляющl= 0;ми:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;тратами на разработку комплекса программ для имитации информации внешних объектов и среды их функционирl= 6;вания;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;тратами на эксплуатацl= 0;ю программ имитации за время прове = 76;ения тестированl= 0;я, испытаний и/или определениn= 3; характерисm= 0;ик качества те = 89;тируемого ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>з = 72;тратами на первичну= 02; установку и эксплуатацl= 0;ю моделирующk= 7;й ЭВМ и вспомогатеl= 3;ьного оборудованl= 0;я, используемl= 6;го в имитацион = 85;ом стенде.<o:p></o:p> &nb= sp; Имитационl= 5;ые стенды практическl= 0; всегда являются ун = 80;кальными и достаточн = 86; полно используют = 88;есурсы моделирующk= 7;й ЭВМ. В ряде сл&= #1091;чаев эти комплексы программ могут иметь = 086;бъем порядка 104 <sp= an style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";mso-char-type:symbol;mso-symbol-fon= t-family: Symbol'>= - 106 стро = 82; текста и должны создаватьсn= 3; с применени = 77;м современныm= 3; технологичk= 7;ских систем. Затраты на эксплуатацl= 0;ю программ имитации в о= 089;новном определяютl= 9;я длительносm= 0;ью проведения тестированl= 0;я, испытаний и/или измере= 085;ия характерисm= 0;ик качества ПС. Значения эт = 86;го времени соответствm= 1;ют реальному времени генерации тестовых данных и тестированl= 0;я программ. Затраты на эксплуатацl= 0;ю ЭВМ, использ= 091;емую в моделирую = 97;ем имитационнl= 6;м стенде (МИС), включают: первичные затраты на з= 072;купку и установку оборудованl= 0;я, необходимоk= 5;о для имитаци = 80; тестовых да = 85;ных, стоимость имитирующеl= 1; ЭВМ и устройств сопряжения имитационнl= 6;го стенда с ЭВМ, на которой функционирm= 1;ют тестируемыk= 7; программы. <o:p></o:p= > = Обычно МИС используетl= 9;я для тестированl= 0;я нескольких ПС разного, но близкого целевого назначения. Следователn= 0;но, затраты на и= 084;итационный стенд и на часть его программ ра = 89;пределяютс&#= 1103; на число про= 077;ктов ПС, тестируемыm= 3; с его использоваl= 5;ием. В результат = 77; удельные затраты на создание и эксплуатацl= 0;ю стендов быстро убывают при унификации имитаторов = 80; расширении области их п= 088;именения для тестированl= 0;я и оценивани= 03; качества большого числа ПС, имеющих бли = 79;кое функционалn= 0;ное назначение. Даже прибли = 78;енные оценки при системном анализе соотношениn= 3; этих затрат = 074; большинствk= 7; случаев пок = 72;зывают высокую рен = 90;абельность программныm= 3; имитаторов внешней среды, особенно дл= 03; квалификацl= 0;онного тестированl= 0;я и оценивани= 03; характерис&= #1090;ик качества кр = 91;пномасштаб&#= 1085;ых ПС реальног = 86; времени. Например, пр= 080; тестированl= 0;и ПС для управ= 083;ения воздушным движением, применение имитационнm= 9;х стендов, по крайней мер = 77;, на порядок снижает затраты по сравнению с натурными эксперименm= 0;ами и использоваl= 5;ием реальных объектов (самолетов), а для управления космическиl= 4;и аппаратами или атомным = 80; электростаl= 5;циями это соотношениk= 7; может быть значительнl= 6; больше (~ 10 -</span= > 100). При соk= 9;дании и определениl= 0; качества администраm= 0;ивных систем с полной загр = 91;зкой, имитация способна заменить сложную организациn= 2; функционирl= 6;вания по определеннl= 6;й программе большого коллектива операторов банка, налоговой инспекции или таможен = 85;ого органа. <o:p></o:p> &nb= sp; При разработке = 80; тестированl= 0;и компонентоk= 4; повторяемоl= 9;ть некоторых тестов окол = 86; 3 - 5, а при испытаниях = 80; определениl= 0; качества кр = 91;пномасштаб&#= 1085;ых ПС достигае = 90; 2 - 3. Поэтому целесообраk= 9;но запоминать имитированl= 5;ые данные для и= 093; многократнl= 6;го использоваl= 5;ия и создавать фильмы сценариев поведения и характерисm= 0;ик тестов, отра= 078;ающих внешнюю среду. В результате затраты на имитацию могут быть уменьшены в = 085;есколько раз за счет однократноl= 1; имитации каждой сово = 82;упности тестов с полным испо = 83;ьзованием МИС. Предваритеl= 3;ьная подготовка фильмов позволяет удобно контролироk= 4;ать имитированl= 5;ые данные, боле= 077; эффективно использоваm= 0;ь МИС, а также обеспечиваn= 2;т абсолютную повторяемl= 6;сть эксперименm= 0;ов. Однако они н= 077; позволяют у = 95;итывать в имитирова = 85;ных данных реакцию функционирl= 6;вания испытываемm= 9;х комплексов программ. Поэтому не полностью исключаютсn= 3; сложные экс = 87;ерименты с одновреме = 85;ным использоваl= 5;ием всей реальной аппаратуры = 52;ИС и оцениваем = 86;й системы, но обеспечиваk= 7;тся сокращение = 74; несколько раз количес = 90;ва таких экспе = 88;иментов. <o:p></o:p> <o:p> </o:p> <h1><a name=3D"_Toc508102485"></a><a name=3D"_Toc508102258">Л= 077;кция 10. Дефекты, ошибки и риски в жизненном цикле = программнm= 9;х средств</a><= span class=3Da4> = <o:p></o:p></h1> <o:p> </o:p></spa= n> <h1><a name=3D"_Toc508102486"></a><a name=3D"_Toc508102259">10.1. Общие особенностl= 0; дефектов, ошибок и рисков = = &nb= sp; k= 4; сложных программнm= 9;х средствах</spa= n></a><o:p></o:p></h1> <o:p> </o:p> Статистикk= 2; ошибок и дефектов в комплексах программ и и= 093; характерисm= 0;ики в конкретных типах проектов ПС, могут служи = 90;ь ориентl= 0;рами для разрабо = 90;чиков при распред = 77;лении ресурсов в ж= 080;зненном цикле ПС &#= 1080; предохраняm= 0;ь их от излишнего оптимизма п = 88;и оценке достигнутоk= 5;о качества программныm= 3; продуктов. </s= pan>Источни= ;ками ошибок в ПС являются специалистm= 9; – конкретны = 77; люди с их индивидуалn= 0;ными особенностn= 3;ми, квалификацl= 0;ей, талантом и опытом. При этом можно в= 099;делить п= ;редсказуем = 99;е модификациl= 0;, расширения = 80; совершенстk= 4;ования ПС и изменения, обусловленl= 5;ые выявлением случайных, нk= 7;предсказуе= 084;ых дефектов и о= 096;ибок. Вследствие этого, плотность потоков и ра= 079;меры необходимыm= 3; корректироk= 4;ок в модулях и компонентаm= 3; при разрабо = 90;ке и сопровожд = 77;нии ПС может различатьсn= 3; в десяток раз. Однако, в крупны&#= 1093; комплексах программ статистика = 80; распределеl= 5;ие типов выполняемыm= 3; изменений для коллект = 80;вов разных специалистl= 6;в нивелируютl= 9;я и проявляютсn= 3; достаточно общие закономернl= 6;сти, которые могут испол= 00;зоваться к= ;ак ориентиры при их выявл= 077;нии и системати = 79;ации. Этому могут помогать оценки типо = 74;ых дефектов, модификациl= 1; и корректироk= 4;ок, путем их нак= 086;пления и обобщения по опыту создания определеннm= 9;х классов ПС в конкретных предприятиn= 3;х. <o:p></o:p> К пl= 6;нятию риски= относятся негативные события и их величины, отражающие потери, убытки или ущерб от про= 094;ессов или продукт = 86;в, вызванные д = 77;фектами при проекти = 88;овании требованиl= 1;, недостаткаl= 4;и обоснованиn= 3; проектов ПС, а также при последующиm= 3; этапах= разработкl= 0;, реализации = 80; всего жизне = 85;ного цикла комплексов программ. В ЖЦ ПС не всегда удается достигнуть требуемого = 87;оложительн&#= 1086;го эффекта и может проявлятьсn= 3; некоторый ущерб – риск<sp= an style=3D'mso-spacerun:yes'> в созk= 6;аваемых проектах, программныm= 3; продуктах и их характерисm= 0;иках. Ри= ски проявляютсn= 3;, как нk= 7;гативные последствиn= 3; дефектов функционирl= 6;вания и применения ПС, которые спо = 89;обны вызвать ущерб системе, внешней среде или пользоватеl= 3;ю, в резm= 1;льтате о= ;тклонения характериl= 9;тик объектов ил = 80; процессов, от заданных требованиn= 3;ми заказчика, согласоваl= 5;ными с разработчиl= 2;ами. <o:p></o:p> = Оценки качества программныm= 3; средств могут проводитьсn= 3; с двух позиц= 080;й: с позиции положительl= 5;ой эффективноl= 9;ти и непосредстk= 4;енной адекватноl= 9;ти их характер = 80;стик назначениn= 2;, целям создания и п= 088;именения, а также с негати= вной позиции возможного при этом ущерба – риска от использоваl= 5;ия ПС или системы. Показатели качества пр = 77;имуществен&#= 1085;о отражают положительl= 5;ый эффект от применения системы или ПС и основна= 103; задача разработчиl= 2;ов проекта сос = 90;оит в обеспечениl= 0; высок= ;их значений качества. Риски характеризm= 1;ют возможные негативныk= 7; последствиn= 3; дефектов ил = 80; ущерб пользоватеl= 3;ей при применении = 80; функционирl= 6;вании ПС и системы, и задача разработчиl= 2;ов сводится к сокращению дефектов и ликвидации рисков. Поэт= 086;му методы и системы управления качеством в жизненном цикле ПС близки к методам анализа и управления рисками про = 77;ктов комплексов программ, он= 080; должны их до= 087;олнять и совместно способствоk= 4;ать совершенстk= 4;ованию программныm= 3; продуктов и систем на их основе. <o:p></o:p> Характериl= 9;тики дефектов и рисков непосредстk= 4;енно связаны с достигаемоl= 1; корректносm= 0;ью, безопасносm= 0;ью и надежностьn= 2; функционирl= 6;вания прогр= ;амм и поl= 4;огают:</= span><o:p></o:p></sp= an> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>о = 94;енивать реальное состояние проекта и пл= 072;нировать необходимуn= 2; трудоемкосm= 0;ь и длительносm= 0;ь для его положительl= 5;ого завершения; <o:= p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в = 99;бирать методы и средства автоматизаm= 4;ии тестированl= 0;я и отладки программ, адекватные текущему состоянию разработки = 80; сопровождеl= 5;ия ПС, наиболее эффективныk= 7; для устране = 85;ия определеннm= 9;х видов дефек = 90;ов и рисков;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>р = 72;ссчитывать необходимуn= 2; эффективноl= 9;ть контрмер и дополнителn= 0;ных средств оперативноl= 1; защиты от потенциальl= 5;ых дефектов и не выявленных ошибок; <o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>о = 94;енивать требующиесn= 3; ресурсы ЭВМ по расширен = 80;ю памяти и производитk= 7;льности, с учетом затрат на реализацию = 82;онтрмер при модифик = 72;ции и устранени = 80; ошибок и рисков.<o:p></o:p> </spa= n>&#= 1055;онятие ошибки в программе</spa= n> &#= 8211; в общем случае под ошибкой подразумевk= 2;ется неправильнl= 6;сть, погрешностn= 0; или неумышл = 77;нное искажение объекта или процесса, чт= 086; может быть </s= pan>&#= 1087;ричиной ущерба – риска при функционирl= 6;вании и применени = 80; программы. При этом предполагаk= 7;тся, что извесm= 0;но правильное, эталонное состояние объекта или процесса, по отношени= 02; к которому может быть определено наличие отк = 83;онения – ошибки или дефекта. Исходным эт = 72;лоном для любого П= 057; являются специ= ;фикация требований = 79;аказчика или потенциальl= 5;ого пользоватеl= 3;я, предъ= ;являемых к программам. Подоб= ;ные документы устанавливk= 2;ют состав, содержание = 80; значения результатоk= 4;, которые должен полу = 95;ать пользоватеl= 3;ь при определеннm= 9;х условиях и исходных данных. Любо= 077; отклонение = 88;езультатов функционирl= 6;вания программы о = 90; предъявляеl= 4;ых к ней требований = 80; сформироваl= 5;ных по ним эталонов-те = 89;тов, следует ква = 83;ифицироват&#= 1100; как ошибкm= 1; – дефект = 74; программе</spa= n>, наносящий некоторый ущерб. Раз= 083;ичие между ожидаемыми и полученныl= 4;и результатаl= 4;и функционирl= 6;вания программ могут быть следствием ошибок не только в соз= 076;анных программах, но и ошибок в первичных требованияm= 3; спецификацl= 0;й, явившихся базой при создании эталонов-те = 89;тов. Тем самым проявляетсn= 3; объективнаn= 3; реальность, = 079;аключающая&= #1089;я в невозможноl= 9;ти абсолютной = 82;орректност&#= 1080; и полноты исходных спецификацl= 0;й и эталонов для сложных проектов ПС.<o:= p></o:p> На практик = 77; в процессе Ж= 062; ПС исходные требования = 87;оэтапно уточняются, = 084;одифицирую&= #1090;ся, расширяютсn= 3; и детализируn= 2;тся по согласов = 72;нию между заказчиком = 80; разработчиl= 2;ом. Базой= ; таких уточнений я = 74;ляются н= ;еформализо = 74;анные представлеl= 5;ия и знания специалистl= 6;в-заказчико&#= 1074; и разработчиl= 2;ов, а также результаты промежуточl= 5;ых этапов проектировk= 2;ния. Однако установить не корректн = 86;сть таких эталонов ещ = 77; труднее, чем обнаружить дефекты в сопровождаk= 7;мых программах, так как принципиалn= 0;но отсутствуюm= 0; формализовk= 2;нные данные, которые можно использоваm= 0;ь как исходны = 77;. В процессе декомпозицl= 0;и и верификац = 80;и исходной спецификацl= 0;и требований на ПС, возможно появление ошибок в спе= 094;ификациях на группы программ и н= 072; отдельные модули. Это способствуk= 7;т расширению спектра возможных дефектов и вызывает необходимоl= 9;ть создания гаммы метод = 86;в и средств тестированl= 0;я для выявлен = 80;я некорректнl= 6;стей в спецификацl= 0;ях на компонен = 90;ы разных уровней. <o:p></o:p> Важной особенностn= 0;ю процесса выявления ошибок в программах является &#= 1086;тсутствие полностью определеннl= 6;й программы-э = 90;алона, которо = 81; должны соот = 74;етствовать текст и результаты функционирl= 6;вания разрабатывk= 2;емой программы. Поэтому установить = 85;аличие и локализоваm= 0;ь дефект непосредстk= 4;енным сравнением = 89; программой без ошибок в большинствk= 7; случаев невозможно. При отладке = 080; тестированl= 0;и обычно сначала обн = 72;руживаются вторичны= е ошибки = 80; риски, т.е. последствиn= 3; и результаты проявления некоторых внутренних дефектов ил = 80; некорректнl= 6;стей программ (ри= 089;.10.1). Эти внутрен = 85;ие дефекты следует квалифицирl= 6;вать как перв= ичные ошибки или причины обнаруженнm= 9;х аномалий результатоk= 4;. Последующаn= 3; локализациn= 3; и корректироk= 4;ка таких первичных ошибок= должна при = 74;одить к устранени= 02; ошибок, первоначалn= 0;но обнаруживаk= 7;мых в результатаm= 3; функционирl= 6;вания программ.<o:p></o:p>= Потери эффективноl= 9;ти и риски прог= 088;амм за счет неполной ко = 88;ректности в первом приближениl= 0; можно счита = 90;ь прямо пропорционk= 2;льными (с коэффицие= 085;том) вторичным ошибкам в выходных результатаm= 3;. Типичным является случай, когд= 072; одинаковые по величине = 080; виду вторич = 85;ые ошибки в различных результируn= 2;щих данных существеннl= 6; различаютсn= 3; по своему воздействиn= 2; на общую эффективноl= 9;ть и риски применения комплекса программ. Эт= 086; влияние вторичных ошибок, в лучшем случ = 72;е, можно оценить мет = 86;дами экспертногl= 6; анализа при условии пре = 76;варительно&#= 1081;, четкой классификаm= 4;ии видов возмо = 78;ных первичных ошибок в программах = 80; выходных величин. Таким образом, оценка посл = 77;дствий, отражающиm= 3;ся на втl= 6;ричных ошибках и функционирl= 6;вании программ, может, в п = 88;инципе, производитn= 0;ся по значения = 84; ущерба – рис= 082;а вследствие не устраненныm= 3; их причин – первичных ошибок в программе. В= 090;оричные ошибки являются определяющl= 0;ми для эффективноl= 9;ти функционирl= 6;вания программ, однако не каждая перв = 80;чная ошибка вносит заме = 90;ный вклад в выходные результаты. Вследствие этого ряд первичных о = 96;ибок может оставаться не обнаруженнm= 9;м и, по существ&#= 1091;, не влияет на функционалn= 0;ные характерисm= 0;ики ПС.<o:p></o:p> Появление ошибок в программах, естественнl= 6;, предшествуk= 7;т их обнаружениn= 2; и устранени= 02; на основе вторичных проявлений. Наибольшее число перви = 95;ных ошибок внос = 80;тся на этапах системного анализа и разработки модификациl= 1; программ. Пр= 080; этом на долю системного анализа приходятся наиболее сл = 86;жные для обнаружениn= 3; и устранени= 03; дефекты. На последующиm= 3; этапах разработки изменений П = 57; ошибки вносятся и устраняютсn= 3; в программа = 93; в процессе и= 093; корректироk= 4;ки по результатаl= 4; тестированl= 0;я. Общие тенде = 85;ции состоят в быстром росте затра = 90; на выполнен = 80;е каждого изменения н = 72; последоватk= 7;льных этапах процессов модификациl= 0; программ. <o:p></o:p></span= > Пр&#= 1080; системном анализе модификациl= 1; интенсивноl= 9;ть обнаружениn= 3; ошибок отно = 89;ительно не велика, и ее трудно выделить из процесса проектировk= 2;ния ПС. Интенсивноl= 9;ть проявления = 80; обнаружени&= #1103; вторичных ошибок наиболее ве = 83;ика на этапе акт= 080;вного тестированl= 0;я и автономно = 81; отладки программныm= 3; компонентоk= 4;. Затем она снижается приблизитеl= 3;ьно экспоненциk= 2;льно. Различия интенсивноl= 9;тей устраl= 5;ения первичных о = 96;ибок, на основе их вторичных проявлений</spa= n>, и внесения первичных ошибок при корректироk= 4;ках программ определяют скорость достижения заданного качества ве = 88;сий ПС. Уровень сер= 00;езности последствиl= 1; ошибок варьирует о = 90; классов проектов и о= 090; предприятиn= 3;, но, в общем, можно разделить ошибки= на три уров= 085;я. <o:p></o:p> Небольшимl= 0; ошибками называю= ;т такие, на которые средний пол= 00;зователь не обратит внимания пр = 80; применении ПС, вследствиk= 7; отсутствия их проявлен = 80;я, и последств = 80;я которых обычно так и не обнаружи = 74;аются. Небольшие ошибки могу = 90; включать ор = 92;ографическ&#= 1080;е ошибки на экране, пропущенныk= 7; разделы в справочникk= 7; и другие мелкие проб = 83;емы. Такие ошибк = 80; никогда не помешают выпуску и применению версии сист = 77;мы и программноk= 5;о продукта. По десятибаллn= 0;ной шкале риско = 74; небольшие ошибки находятся в пределах от 1 до 3 приорите&#= 1090;а (см. ниже).<o:p></o:p> </spa= n>Уl= 4;еренными ошибками называют те, которые вли= 03;ют на конечног = 86; пользоватеl= 3;я, но имеются слабые последствиn= 3; или обходны = 77; пути, позволяющиk= 7; сохранить достаточнуn= 2; функционалn= 0;ность ПС. Это такие дефекты, как неверные ссылки на страницах, ошибочный текст на экране и даж= 077; сбои, если эти сбои трудно воспроизвеl= 9;ти, и они не оказывают влияния на существеннl= 6;е число пользоватеl= 3;ей. Некоторые умеренные ошибки, возможно, пр= 086;никают в конечный программныl= 1; продукт. Ошибки, кото= 088;ые можно испра = 74;ить на этом уровне, след= 091;ет исправлять, если на это есть время и возможностn= 0;. По десятиба = 83;льной шкале умеренные ошибки нахо = 76;ятся в диапазоне от 4 до 7 приоритета.<o:p= ></o:p> Кl= 8;итические ошибки останавливk= 2;ют выпуск версии программноk= 5;о продукта. Это могут быть ошибки с высоким влиянием, которые выз = 99;вают сбой в системе или потерю данн = 99;х, отражаются на надежнос = 90;и и безопасносm= 0;и применения ПС, с которым&#= 1080; никогда не передается комплекс прогр= ;амм пользоватеl= 3;ю. По десятибаллn= 0;ной шкале – от 8 до 10= приоритетk= 2;.<o:p></o:p> Совокупноl= 9;ть ошибок, дефектов и последствиl= 1; модификациl= 1; проектов кр = 91;пномасштаб&#= 1085;ых комплексов программ можно упоря = 76;очить и условно пр= 077;дставить в виде перев= 077;рнутой пирамиды в зависимостl= 0; от потенциа = 83;ьной опасности и возможной величины корректироk= 4;ок их последст = 74;ий – рис. 10.2. В верхней части перечня расположенm= 9; модификациl= 0;, дефекты и ошибки, последствиn= 3; которых обычно треб = 91;ют наибольших = 79;атрат ресурсов дл= 03; реализации изменений, и &#= 1086;ни постепенно сокращаютсn= 3; при снижени = 80; по перечню. Такое представлеl= 5;ие величины типов корре = 82;тировок программ и данных= полезно ис = 87;ользовать к= ;ак ориентир для учета необходимыm= 3; ресурсов пр = 80; разработке = 80; сопровожде&= #1085;ии ПС, однако оно может содержать значительнm= 9;е отклонения при упорядоченl= 0;и статистичеl= 9;ких данных реальных проектов. Каждому тип = 91; корректироk= 4;ок соответствm= 1;ет более или менее определеннk= 2;я категория специалисm= 0;ов, являющихся = 80;сточником изменений данного тип = 72; (таблица 10.1). Та= 082;ую корреляцию целесообраk= 9;но рассматривk= 2;ть и учитывать как общую качественнm= 1;ю тенденцию при анализе = 080; поиске их причин. <o:p></o:p> </spa= n><o:p></o:p> <h1><a name=3D"_Toc508102487"></a><a name=3D"_Toc508102260">10.2. Причины и свойства дефектов, ошибок и мод= 080;фикаций в = сложных программнm= 9;х средствах</spa= n></a><o:p></o:p></h1> <o:p> </o:p> Одной из основных причин изме = 85;ений комплексов программ яв = 83;яются организациl= 6;нные дефекты при модификациl= 0; и расширени = 80; функций ПС, которые отличаются от остальны = 93; типов и усло= 074;но могут быть в= 099;делены как самостоятеl= 3;ьные (см. рис. 10.2). Ошибки и деф= 077;кты данного тип = 72; появляются из-за недост= 072;точного понимания коллективоl= 4; специалистl= 6;в технологии процесса ЖЦ ПС, а также вследствие отсутствия четкой его организациl= 0; и поэтапног = 86; контроля качества продуктов и изменений. Это порождаетсn= 3; пренебрежеl= 5;ием руководитеl= 3;ей к организациl= 0; всего технологичk= 7;ского процесса Ж = 62; сложных ПС и &#= 1087;риводит к серьезной недооценке его дефекто = 74;, а также трудоемкосm= 0;и и сложности модификациl= 1;. При отсутствии планомерноl= 1; и методично = 81; разработки = 80; тестированl= 0;я изменений П = 57;, остается не выявленным = 79;начительно&#= 1077; количество ошибок, и, прежде всег = 86;, дефекты взаимодейсm= 0;вия отдельных ф = 91;нкциональн&#= 1099;х компонентоk= 4; между собой = 080; с внешней средой. Для сокращения этого типа массовых ошибок, активную роль должны играть лидеры – мен= 077;джеры и системотехl= 5;ики, способные вести контроль и к= 086;нфигурацио&= #1085;ное управление требованияl= 4;и, изменениямl= 0; и развитием версий и ком= 087;онентов ПС. <o:p></o:p></= span> Изменения характерисm= 0;ик системы и внешней среды, приня= 090;ые в процессе р= 072;зработки ПС за исходные, могут быть р= 077;зультатом аналитичесl= 2;их расчетов, моделироваl= 5;ия или исследованl= 0;я аналогичныm= 3; систем. В ряде случае = 74; может отсут = 89;твовать полная адек = 74;атность предполагаk= 7;мых и реальных характерисm= 0;ик, что являетс= 03; пl= 8;ичиной сложных и тр= 091;дно обнаруживаk= 7;мых системных ошибок и дефектов ра = 79;вития проекта. Ситуация с т= 072;кими ошибками дополнителn= 0;но усложняетсn= 3; тем, что эксперименm= 0;ы по проверке взаимодейсm= 0;вия ПС с реально= 081; внешней средой во всей област = 80; изменения п = 72;раметров зачастую сложны и дор= 086;ги, а в отдельны= 093; случаях, при создании опасных ситуаций, недопустимm= 9;. В этих случаях приходится использоваm= 0;ь моделироваl= 5;ие и имитацию внешней среды с заве= 076;омым упрощением её отдельны = 93; элементов и характерисm= 0;ик, хотя степен= 00; упрощения н = 77; всегда удается оце = 85;ить с необходимоl= 1; точностью. Однако полн = 86;й адекватносm= 0;и моделей внешней среды и реал= 100;ной системы добиться трудно, а во многих случаях и не= 074;озможно, что может являться причиной зн = 72;чительного числа крупн = 99;х дефектов.<o:p></o:p>= Первичные ошибки в программах проектов можно анализировk= 2;ть с разной сте= 087;енью детализациl= 0; и в зависимостl= 0; от различны = 93; факторов. Практическl= 0;й опыт показа = 83;, что наиболее существеl= 5;ными факторами, влияющими н = 72; характерисm= 0;ики обнаруживаk= 7;мых ошибок явля= 02;тся:<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тодология, технология = 80; уровень авт = 86;матизации системного = 80; структурноk= 5;о проектировk= 2;ния ПС, а также непосредстk= 4;енного программирl= 6;вания компонентоk= 4;;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>д = 83;ительность с начала процесса тестированl= 0;я и текущий этап разработки или сопрово = 78;дения и модификациl= 0; комплекса п = 88;ограмм;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>к = 83;асс ПС, масштаб (размер) и типы компонентоk= 4;, в которых обнаруживаn= 2;тся ошибки;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>м = 77;тоды, виды и уровень автоматизаm= 4;ии верификациl= 0; и тестирова = 85;ия, их адекватн = 86;сть характерисm= 0;икам компонентоk= 4; и потенциал= 00;но возможным в программах ошибкам;<o:p></o:p> <![if !supportLists]>- &nb= sp; <![endif]>в = 80;ды и достоверноl= 9;ть эталонов-те = 89;тов, которые используютl= 9;я для обнаруж = 77;ния ошибок.<o:p></o:p> Пk= 7;рвичные ошибки в ПС в порядке уменьшения их влияния н= 072; сложность обнаружениn= 3; и масштабы корректироk= 4;ок можно разде = 83;ить на следующи = 77; группы= (см. рис. 10.2):<o:p></o:p> <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки, обусловленl= 5;ые сложностью компонентоk= 4; и ПС в целом и наиболее сильно влияющие на размеры модификациl= 1;;<o:p></o:p> <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки вследствие большого маl= 9;штаба – размера ко= 084;плекса программ, а также высоких тре = 73;ований к его качеству;<o:p></o:p>= <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки планированl= 0;я и корректносm= 0;и требований модификациl= 1; часто могут быть наиболее кр = 80;тичным для общего успеха ЖЦ ПС и системы;<o:p></o:p></span= > <![if !supportLists]>- &nb= sp; = <![endif]>о = 96;ибки проектировk= 2;ния, разработки структуры и функций ПС в более полны = 77; и точные техническиk= 7; описания сценариев того, как комплекс пр = 86;грамм и система бу = 76;ут функционирl= 6;вать;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>с = 80;стемные ошибки, обусловленl= 5;ые отклонениеl= 4; функционирl= 6;вания ПС в реальной системе, и характерисm= 0;ик внешних объектов от предполагаk= 4;шихся при проекти = 88;овании;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>а = 83;горитмичес&#= 1082;ие ошибки, связанные с неполным формированl= 0;ем необходимыm= 3; условий решения и некорректнl= 6;й постановкоl= 1; целей функц = 80;ональных задач;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>о = 96;ибки реализации спецификацl= 0;й изменений – программныk= 7; дефекты, воз= 084;ожно, ошибки нарушения требований или структу = 88;ы компонентоk= 4; ПС; <o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>п = 88;ограммные ошибки, вследствие неправильнl= 6;й записи текс = 90;ов программ на языке программирl= 6;вания и ошибок тра= 085;сляции текстов изменений программ в о= 073;ъектный код;<o:p></o:p> <![if !supportLis= ts]>- &nb= sp; = <![endif]>о = 96;ибки в документацl= 0;и, которые наиболее ле = 75;ко обнаруживаn= 2;тся и в наименьшей степени влияют на фу= 085;кционирова&= #1085;ие и применени = 77; версий ПС; <o:p></o:p> <![if !supportLists]>-&nb= sp; = &nb= sp; <![endif]>т = 77;хнологичес&#= 1082;ие ошибки подготовки физических носителей и документацl= 0;и, а также ввод= 072; программ в память ЭВМ и вывода резу = 83;ьтатов на средства отображениn= 3;.<o:p></o:p> </spa= n> Сложн= ость проявления, обнаружениn= 3; и устранени= 03; ошибок зна = 95;ительно конкретизиl= 8;уются и стан= 086;вятся измеримой, когда устан = 72;вливается связь этого понятия с конкретнымl= 0; ресурсами, необходимыl= 4;и для решения соответствm= 1;ющей задачи и воз= 084;ожными проявленияl= 4;и дефек= ;тов. При разработке = 80; сопровождеl= 5;ии проk= 5;рамм основным лимитирующl= 0;м ресурсом обычно являются допустимые трудозатраm= 0;ы специалистl= 6;в, а также ограниченl= 0;я на сроки раз= 088;аботки, параметры ЭВМ, техноло&sh= y;гию проектировk= 2;ния корректироk= 4;ок ПС. П</span= >оказат= 077;ли сложности при анализе = 084;ожно разделить на две большие гру = 87;пы:<o:p></o:p> <![if !supportLists]><sp= an style=3D'mso-list:Ignore'>-&nb= sp; = <![endif]>сложно= ;сть ошибок при создании корректироk= 4;ок компонентоk= 4; и комплекса программ <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-family:"Times N= ew Roman"; mso-hansi-font-family:"Times New Roman";letter-spacing:.3pt;mso-char-type:s= ymbol; mso-symbol-font-family:Symbol'>- статическаn= 3; сложность, когда реали = 79;уются его требуемые функции, вносятся ос = 85;овные дефекты и ош= 080;бки;<o:p></o:p> <= ![if !supportLists]>- = &nb= sp; <![endif]>сложно&= #1089;ть проявления ошибок функционирl= 6;вания программ и получения р = 77;зультато= ;в <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";letter-spacing:.3= pt; mso-char-type:symbol;mso-symbol-font-family:Symbol'>- динамическk= 2;я сложность, <sp= an style=3D'font-size:14.0pt;letter-spacing:.3pt'>когд= а проявляютсn= 3; дефекты и ошибки, отражающиеl= 9;я на функционалn= 0;ном назначении, рисках и кач= 077;стве применения версии ПС.<o:p></o:p> К группе факторов, влияющих на <sp= an style=3D'mso-bidi-font-style:italic'>сложн= 086;сть ошибок= &= #1082;омплексов программ, от= 085;осятся:<o:p></o:p> = <![if !supportLists]>- &nb= sp; = <![endif]>величина – размер модифицируk= 7;мой программы, выраженная числом стро = 82; текста, функционалn= 0;ных точек или количеством программныm= 3; модулей в комплексе;<o:p></o:p> = <![if !supportLists]>- &nb= sp; = <![endif]>количествl= 6; обрабатываk= 7;мых переменных или размер и структура п = 72;мяти, используемl= 6;й для размещения базы данных корректироk= 4;ок;<o:p></o:p> <![if !supportLists]><sp= an style=3D'mso-list:Ignore'>-&nb= sp; = &nb= sp; <![endif]>трудоемкос= ;ть разработки изменений комплекса п = 88;ограмм;<o:p></o:p> <![if !supportLists]>- &= nbsp; &nbs= p; &= nbsp; &nbs= p; &= nbsp; <![endif]>длительнос= ;ть разработки = 80; реализации корректироk= 4;ок;<o:p></o:p> = <![if !supportLists]>- &nb= sp; = <![endif]>число специалистl= 6;в, участвующиm= 3; в ЖЦ комплекса прог= рамм.<o:p></o:p> Не= которые из перечисленl= 5;ых параметров коррелир = 86;ванны между собой, причем, определяющl= 0;ми часто являю = 90;ся размер изменений программы и объем базы д= 072;нных. Остальные характерисm= 0;ики можно рассм = 72;тривать как вторичные, однако они могут предс = 90;авлять самостоятель= ;ный интерес при анализе сложности и = 087;рогнозиров&= #1072;нии вероятного числа дефектов в измененной программе. <sp= an style=3D'font-size:14.0pt;letter-spacing:.5pt;mso-bidi-font-weight:bold; mso-bidi-font-style:italic'>Сложноl= 9;ть ошибок комплекl= 9;ов программ целесообраk= 9;но анализировk= 2;ть на базе трех наиболее специфичесl= 2;их компонентов:<s= pan style=3D'font-size:14.0pt'><o:p></o:p> <= ![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>сложно= ;сть ошибок изменяемых программныm= 3; компонентоk= 4; и модулей опре= ;деляется конструктивн= ой сложностью модификациl= 0; оформленноk= 5;о компонента программы и может быть оценена с по= 079;иции сложности внутренней структуры и преобразовk= 2;ния данных в каждом модуле, а также инте</span= >грал= ;ьно по некоторы = 84; внешним статистичеl= 9;ким характерисm= 0;икам размеров моду= ;лей;<o:p></o:p> <![if !supportLists]><sp= an style=3D'mso-list:Ignore'>-&nb= sp; = &nb= sp; = <![endif]>сложнl= 6;сть ошибок корректироk= 4;ок структуры комплекса или компонентоk= 4; и связей межд= 091; модулями по передачам управления = 80; по обмену ин&sh= y;формацией определяетl= 9;я глубиной взаимодейсm= 0;вия модулей и ре&sh= y;гуля= рностью структуры межмодульнm= 9;х связей;<o:p></o:p> <= ![if !supportLists]>- &nb= sp; = &nb= sp; <![endif]>сложно= ;сть ошибок изменения структуры д = 72;нных оп= ределяется количествоl= 4; и с= труктурой глобальных = 80; обменных пе = 88;еменных в базе данных, регулярносm= 0;ью их = размещения в массивах, а также сложн = 86;стью доступа к эт= 080;м данным.<o:p></o:p> Масштаб – размер компле= ксов программ и и= 093; изменяемой части наиболее си = 83;ьно влияет на количество ошибок, а также на тре= 073;ования к качеству ПС (см. лекцию 5). К= ;ачество откорректиl= 8;ованного ПС характер = 80;зуется многими показателяl= 4;и, состав кото = 88;ых зависит от класса и кон= 082;ретного назначения комплекса программ. Ниже предполагаk= 7;тся, что всегда модификациl= 0; ПС соответствm= 1;ют заданному функционалn= 0;ному назначению = 80; основным требованияl= 4; заказчика к = 080;х качеству. По мере увелич = 77;ния размера и повышения требований = 82; качеству ПС = 080; его корректироk= 4;кам, затраты на обнаружениk= 7; и устранени = 77; ошибок ПС ув= 077;личиваются все более высокими темпами. Одновременl= 5;о расширяетсn= 3; диапазон неопределеl= 5;ности достигаемоk= 5;о качества. В зоне высоко = 75;о качества программ во = 79;растают трудности измерения этих характерисm= 0;ик, что может приводить к необходимоl= 9;ти изменения з = 72;трат в несколько раз в зависимостl= 0; от применяе = 84;ых методов и результатоk= 4; оценки каче = 89;тва ПС. Вследствие этого в ЖЦ сложных и св= 077;рхсложных ПС всегда велики проявления не устранен = 85;ых ошибок и недостаточl= 5;а достоверноl= 9;ть оценок достигнутоk= 5;о качества.<o:p></o:p>= </spa= n>Оm= 6;ибки корректносm= 0;и формированl= 0;я и планирова = 85;ия выполнения требований = 82; ПС часто считаются наиболее критичным для общего успеха версий программноk= 5;о продукта и системы. Ошибки требований = 03;вляются наиболее трудными дл= 03; обнаружениn= 3; и наиболее сложными дл= 03; исправлениn= 3;. Вот почему и= 089;правление ошибок треб = 86;ваний может быть в 15 – 70 раз дороже, чем ошибок и= 093; программирl= 6;вания. Требование = 82; изменению может быть пропущено в спецификацl= 0;и к системе и ПС. Это ведет к неудовлет= ;воренности пользоватеl= 3;я, и программа считается заказчиком = 80; пользовате= лем ошибочной. Пропуск некоторых требования – это наиболее обычная проблема среди ошибо = 82; требований. Ошибка треб = 86;ваний может представляm= 0;ь собой конфликтуюm= 7;ие требования = 74; спецификацl= 0;и модификациl= 1;. Напри= ;мер, два требования, которым необходимо следовать, имеют противополl= 6;жный смысл. Может проявлятьсn= 3; неопределk= 7;нность требований R= 11; такой спосо = 73; формулировk= 2;ния требования, что даже есл= 080; и не конфлик= 090;ует с другим требование= м, оно выражен = 86; недостаточl= 5;о ясно, чтобы п&#= 1088;ивести к единственнl= 6;му, конструкти= вному решению при разработке = 80;зменения. Конечный пользоватеl= 3;ь часто назыв = 72;ет это ошибкой, хотя на самl= 6;м деле это выбор конст = 88;уктивного решения на основе непо = 83;ного или неопред = 77;ленного требования. Многочислеl= 5;ные исследованl= 0;я показали, чт= 086; ошибки требований дороже всег = 86; исправить и труднее всего обнар = 91;жить. <o:p></o:p> &nbs= p; Ошибки проектировk= 2;ния и разработк = 80; структуры П = 57; опредеl= 3;яются процессами перевода неопределеl= 5;ных и общих полl= 6;жений, сделанных н = 72; стадии спецификацl= 0;й требований, = 074; более точны = 77; техническиk= 7; описания сценариев того, как измененные ПС и система должны рабо = 90;ать. Ошибки структуры легче обнар = 91;жить, чем ошибки требований, но они в коне&#= 1095;ном итоге могут оказаться при корректироk= 4;ках такими же дорогостояm= 7;ими. Главная причина тог = 86;, что ошибки структуры дорого исправлять, состоит в том, что они могут влият= 00; на систему в целом. Испрk= 2;вление изменений всей систем = 99; сложнее, и при этом воз= 085;икает большая опасность з = 72;нести новые ошибк = 80;, чем при исправлениl= 0; нескольких нарушенных строк кода или при замене одного моду = 83;я. <o:p></o:p> Ошибки структуры можно разде = 83;ить на три категории: п= 088;опуски, конфликты и ошибки перевода. Пропуски означают неспособноl= 9;ть включить изменения одного или б= 086;лее требований в окончател= 00;ную структуру П = 57;. Когда пропуск новой функц = 80;и или компоне = 85;та попадает в окончательl= 5;ую структуру, о= 085; станет ошибкой в конечном программноl= 4; продукте. Конфликты возникают, когда модификациn= 3; двух различ = 85;ых, конструктиk= 4;ных свойств имеют конфликтуюm= 7;ую структуру. Э= 090;о может происходитn= 0; в случае явного конф = 83;икта, когда в структуре установленl= 6;, что файл может быть открыт двум= 03; разными людьми в одн= 086; и то же время, тогда как в б&#= 1072;зовом классе определяетl= 9;я только однопользоk= 4;ательский доступ. Ошибки, которые основаны на конфликтах на этом уровне, част= 086; невозможно = 80;справить без полного переписываl= 5;ия модулей версии ПС. <o:p></o:p></spa= n> Ошибки перевода – наиболее коварные среди всех ошибок стру = 82;турного уровня. Они проявляютсn= 3;, когда требо = 74;ания заказчика интерпретиl= 8;уются неправильн= о, по крайней мере, с точки зрения коне = 95;ного пользоватеl= 3;я. Если разраб= ;отчик структуры либо неверн = 86; прочитает т = 88;ебования, либо не увидит содержание требования также как конечный по = 83;ьзователь, появится ошибка разработки = 89;труктуры данного ком = 87;онента или ПС. <o:p></o:p> Системные ошибки в ПС<sp= an style=3D'font-size:14.0pt'> определяютl= 9;я, прежде всег = 86;, неполной информациеl= 1; о реальных процессах, п= 088;оисходящих в источника = 93; и потребите = 83;ях информации. Кроме того, эти процесс = 99; зачастую зависят от самих алгоритмов = 80; поэтому не могут быт= 100; достаточно определены = 80; описаны заранее без исследованl= 0;я изменений функционирl= 6;вания ПС во взаимодейсm= 0;вии с внешней средой. На начальных этапах не всегда удается точ = 85;о и полно сформулироk= 4;ать целевую задачу всей системы, а также целевые зад = 72;чи основных групп программ, и эти задачи у= 090;очняются в процессе п= 088;оектирован&= #1080;я. В соответствl= 0;и с этим уточн= 103;ются и конкретиз = 80;руются спецификацl= 0;и на отдельны = 77; компоненты = 80; выявляются отклонения от уточненн = 86;го задания, которые могут квалифицирl= 6;ваться как системные ошибки.<o:p></o:p> Характериl= 9;тики внешних объ = 77;ктов, принятые в качестве ис = 93;одных данных в процессе разработки алгоритмов, могут являться результатоl= 4; аналитичесl= 2;их расчетов, мо= 076;елирования или исследованl= 0;я аналогичныm= 3; систем. Во всех случая = 93; может отсут = 89;твовать полная адекватносm= 0;ь условий получения предполагаk= 7;мых и реальных характерисm= 0;ик внешней среды, что является причиной сл = 86;жных и трудно обнаруживаk= 7;мых ошибок. Это усугубляетl= 9;я тем, что очень часто = 085;евозможно заранее пре = 76;усмотреть все разнообразl= 0;е возможных внешних условий и реальных сц = 77;нариев функционирl= 6;вания и применени= 03; версий программноk= 5;о продукта.<o:p></o:p>= Пр&= #1080; автономноl= 1; и в начале комплексноl= 1; отладки версий ПС, относительl= 5;ая доля системных о = 96;ибок может быть невелика (около 10%), но он= 072; существеннl= 6; возрастает (до 35–40%) на завершающиm= 3; этапах комп = 83;ексной отладки новых базовых версий ПС. В процессе сопровождеl= 5;ия системные ошибки явля= 02;тся преобладаюm= 7;ими (около 60 – 80% от всех ошибок). Следует также отметить большое количество команд, корректируk= 7;мых при исправлениl= 0; каждой тако = 81; ошибки (окол= 086; 20 – 50 команд на одну ошибку).<o= :p></o:p> Алгоритмиm= 5;еские ошибки программ трудно поддаются обнаружениn= 2; методами статическоk= 5;о автоматичеl= 9;кого контроля. Тр= 091;дность их обнаружениn= 3; и локализациn= 3; определяетl= 9;я, прежде всег = 86;, отсутствиеl= 4; для многих логических программ строго формализовk= 2;нной постановки задачи, полной и точной спецификацl= 0;и, которую можно использоваm= 0;ь в качестве эталона для сравнения результатоk= 4; функционирl= 6;вания программ. К алгоритмичk= 7;ским ошибкам следует отнести, прежде всег = 86;, ошибки, обусловленl= 5;ые некорректнl= 6;й постановкоl= 1; требований = 82; функционалn= 0;ным задачам, когда в спецификацl= 0;ях не полность= 02; оговорены все условия, необходимыk= 7; для получения правильногl= 6; результата. Эти условия формируютсn= 3; и уточняются = 74; значительнl= 6;й части в процессе тестированl= 0;я и выявления ошибок в результатаm= 3; функционирl= 6;вания программ. Ошибки, обусловленl= 5;ые не полным учетом всех условий решения зад = 72;ч, являются наиболее ча = 89;тыми в этой групп= 077; и составляю = 90; до 50 – 70% всех алгоритмичk= 7;ских ошибок.<o:p></o:p> К алгоритмичk= 7;ским ошибкам сле = 76;ует отнести также ошибк = 80; интерфейса = 84;одулей и функционалn= 0;ных групп программ, когда инфор = 84;ация, необходимаn= 3; для функцио = 85;ирования некоторой части программы, оказываетсn= 3; не полность= 02; подготовлеl= 5;ной программамl= 0;, предшествуn= 2;щими по времени включения, или неправильнl= 6; передается информация = 80; управление между взаимодейсm= 0;вующими модулями. Этот вид ошибок сост = 72;вляет около 10% от общего количества, = 080; можно квалифицирl= 6;вать как ошибки некорректнl= 6;й постановки задач. Алгоритмичk= 7;ские ошибки проя = 74;ляются в неполном учете диапазонов изменения переменных, = 074; неправильнl= 6;й оценке точности используемm= 9;х и получаемы = 93; величин, в неправильнl= 6;м учете корреляции между различными переменнымl= 0;, в неадекват = 85;ом представлеl= 5;ии формализовk= 2;нных условий решения задачи в вид= 077; частных спецификацl= 0;й или блок-схем, подлежащих программирl= 6;ванию. Эти обстоят = 77;льства являются причиной того, что для исправлениn= 3; каждой алго = 88;итмической ошибки приходится изменять в среднем около 20 команд (стр= 086;к текста), т.е. существеннl= 6; больше, чем при программныm= 3; ошибках.<o:p></o:p> Особую, весьма существеннm= 1;ю, часть алгоритмичk= 7;ских ошибок в системах ре = 72;льного времени, при сопровождеl= 5;ии составляют просчеты в использоваl= 5;ии доступных ресурсов вычислителn= 0;ной системы. Получающиеl= 9;я при модификациl= 0; программ попытки пре = 74;ышения использоваl= 5;ия выделенных ресурсов, сл= 077;дует квалифицирl= 6;вать как ошибку, так как зате= 084; всегда след = 91;ет корректироk= 4;ка с целью удовлетворk= 7;ния имеющимся ограничениn= 3;м. Одновременl= 5;ая разработка множества модулей различными специалистk= 2;ми затрудняет оптимальноk= 7; и сбалансироk= 4;анное распределеl= 5;ие ограниченнm= 9;х ресурсов ЭВ = 52; по всем зада= 095;ам, так как отсутствуюm= 0; достоверныk= 7; данные потребных ресурсов дл= 03; решения каждой из них. В резуль&#= 1090;ате возникает либо не достаточноk= 7; использоваl= 5;ие, либо, в подав&#= 1083;яющем большинствk= 7; случаев, нехватка каких-то ресурсов ЭВ = 52; для решения задач в перв= 086;начальном варианте. Наиболее крупные про = 89;четы обычно допу = 89;каются при оценке в= 088;емени реализации различных групп программ ре = 72;льного времени, и при распределеl= 5;ии производитk= 7;льности ЭВМ. Алгорит= 084;ические ошибки этог = 86; типа обусловленm= 9; техническоl= 1; сложностью расчета времени реализации программ и сравнительl= 5;о невысокой достоверноl= 9;тью, определениn= 3; вероятностl= 0; различных маршрутов обработки и = 85;формации.<o:p></o:p></sp= an> Ошибки реализации спецификацl= 0;й компонентоk= 4; – это пр= 086;граммные дефекты, воз= 084;ожно, ошибки требований, структуры или програм= ;мные ошибки комп = 86;нентов. Ошибки реализации наиболее обычны, и, в общем, наиболее легки для исправлениn= 3; в системе, что не делае= 090; проблему легче для программисm= 0;ов (см. таблицу 10.1). В отличие от ошибок треб = 86;ваний и структурныm= 3; ошибок, которые обычно специфичны для приложения, программисm= 0;ы часто совершают при кодиров = 72;нии одни и те же в&= #1080;ды ошибок. <o:p></o:p> Первую категорию составляют дефекты, которые приводят к отображениn= 2; для пользоватеl= 3;я сообщений о = 73; ошибках при = 090;очном следовании порядку вып= ;олнения требуемых функций. Хот= 103; эти сообщен = 80;я могут быть вполне законны, пользовате= ли могут посчи = 90;ать это ошибкой, поскольку они делали в= 089;е правильно и, тем не менее, получили со = 86;бщение об ошибке. Часто ошибк = 80; этого типа вызваны либ = 86; проблемами = 89; ресурсами, л= 080;бо специфичесl= 2;ими зависимост= ями от данных.<o:p></o:p></span= > Вторая категория модификациl= 1; может содержать ошибки, связ= 072;нные с дефектами = 074; графическоl= 4; интерфейсе пользоватеl= 3;я. Такие ошибк = 80; могут являт= 00;ся либо нестандартl= 5;ыми модификациn= 3;ми пользоватеl= 3;ьского интерфейса, которые приводят к тому, что пол&#= 1100;зователь совершает н = 77;верные действия, либо они мог= 091;т быть стандартныl= 4;и компонентаl= 4;и пользоватеl= 3;ьского интерфейса, используемm= 9;ми иначе, чем ожидает кон= ;ечный пользоватеl= 3;ь. <o:p></o:p> &n= bsp; <o:p></o:p> &n= bsp; Третья категория может содержать п = 88;опущенные на стадии реализации функции, что всегда считается ошибкой, возможно, с большим риском. Многие т = 77;стировщики</= span> и пользоватеl= 3;и бета-версий = 089;ообщают об ошибках, которые на самом деле я= 074;ляются желательныl= 4;и улучшениямl= 0;. В данном случае можн = 86; не замечать обнаруженнm= 9;е таким образ = 86;м отсутствия функций, которых не было в специ= 092;икациях. <o:p></o:p> Прог&= #1088;аммные ошибки модифицироk= 4;анных компонентоk= 4; по количест = 74;у и типам в первую очередь определяютl= 9;я степенью ав = 90;оматизации программирl= 6;вания и глубиной статическоk= 5;о контроля те = 82;стов программ. Количество программныm= 3; ошибок зависит от квалификацl= 0;й программисm= 0;ов, от общего размера комплекса программ, от глубины инф = 86;рмационног&#= 1086; взаимодейсm= 0;вия модулей и от ряда других факторов. Пр= 080; разработке ПС программ = 85;ые ошибки можн = 86; классифициl= 8;овать по видам исп= 086;льзуемых операций на следующие крупные группы: ошибки типо = 74; операций; ош= 080;бки переменных; ошибки управления = 80; циклов. В логическиm= 3; компонентаm= 3; ПС, эти виды ошибок близ = 82;и по удельном = 91; весу, однако для автоматизаm= 4;ии их обнаружениn= 3; применяютсn= 3; различные методы. На начальных э = 90;апах разработки = 80; автономной отладки мод = 91;лей, программныk= 7; ошибки сост = 72;вляют около одной трети всех ошибок. Кажд= 072;я программнаn= 3; ошибка влечет за собой необходимоl= 9;ть изменения около 10 команд, что существеннl= 6; меньше, чем при алгорит = 84;ических и системных ошибках. <o:p></o:p> Ошибки в документацl= 0;и модификациl= 1; состоят в том, что сист&#= 1077;ма делает что-т= 086; одним образом, а документацl= 0;я отражает сценарий, чт= 086; она должна работать иначе. Во многих случаях права должн = 72; быть документацl= 0;я, поскольку она написан = 72; на основе ор= 080;гинальной спецификацl= 0;и требований системы. Иногда документацl= 0;я пишется и вк= 083;ючает допущения и комментариl= 0; о том, как, по мнению авто = 88;ов документацl= 0;и, система дол = 78;на работать. В других случаях ошибку можн = 86; проследить не до кода, а до документацl= 0;и конечных пользоватеl= 3;ей, внутренних технологичk= 7;ских документов, характеризm= 1;ющих систему, и даже до экранных подсказок и файлов помо = 97;и. Ошибки документацl= 0;и можно разде = 83;ить на три катег= 086;рии – неясность, неполнота и неточность. Неясность – это когда по= 083;ьзователю не дается достаточно информации, чтобы определить, как сделать процедуру должным образом. Неполная документацl= 0;я оставляет пользоватеl= 3;я без информации = 86; том, как правильно реализоватn= 0; и завершить задачу. Пользоватеl= 3;ь считает, что задача выпо= ;лнена, хотя на само= 084; деле это не так. Такие ош&#= 1080;бки ведут к тому, что пользоватеl= 3;ь неудовлk= 7;творен версией ПС, даже если программа в действител= ьности может сдела = 90;ь все, что хочет пользоватеl= 3;ь. Неточная до = 82;ументация – это худший вид ошибок документацl= 0;и. Такие ошибк = 80; часто возникают, когда при сопровождеl= 5;ии в систему позже вносятся изменения и об этих изменениях не сообщают лицу, пишуще= 084;у документацl= 0;ю. <o:p></o:p> Технологиm= 5;еские ошибки документацl= 0;и и фиксированl= 0;я программ в памяти ЭВМ составляют иногда до 10% от общего числ = 72; ошибок обнаруживаk= 7;мых при тестиро = 74;ании. Большинствl= 6; технологичk= 7;ских ошибок выявляется автоматичеl= 9;ки статическиl= 4;и методами. Пр= 080; ручной подг = 86;товке текстов маш = 80;нных носителей при однократноl= 4; фиксированl= 0;и исходные данные имею = 90; вероятностn= 0; искажения около 10 -3 – 10 -4 н= 072; символ. Дубл= 080;рованной подготовкоl= 1; и логически = 84; контролем вероятностn= 0; технологичk= 7;ской ошибки може = 90; быть снижен = 72; до уровня 10 -5 – 10 -7 на симво= л. Непосредсm= 0;венное участие чел = 86;века в подготовк = 77; данных для ввода в ЭВМ и при анализе результатоk= 4; функционирl= 6;вания программ по данным на дисплеях определяет = 74; значительнl= 6;й степени их уровень дос = 90;оверности и не позволяет полностью пренебрегаm= 0;ь этим типом о= 096;ибок в программа = 93;. <o:p></o:p> = В примере анализа ошибок конкретногl= 6; крупного проекта, было принят = 86;, что завершиласn= 0; инспекция н = 72;чального запрограммl= 0;рованного кода крупного ПС на предмет е= 075;о соответствl= 0;я рабочей проектной спецификацl= 0;и, в ходе которой был = 86; обнаружено 3,48 ошибок на тысячу стро = 82; кода. Наибольшее совпадение аппроксимаm= 4;ии рэлеевсl= 2;ой кривой распределеl= 5;ия ошибок с фактическиl= 4;и данными установленl= 6; для момента получения этих данных, ему соответ = 89;твует значение, равное такж = 77; 3,48. Зна&#= 1095;ения числа ошибо = 82; на тысячу строк получены, п= 088;и пересчетах на более ранние этап = 99; соответствk= 7;нно эскизного – (3,3) и рабочего – (7,8) проектировk= 2;ния программ. При прогноз = 80;ровании в соответствl= 0;и с рэлеев = 89;кой кривой распределеl= 5;ия вероятностl= 0; проявления дефектов пр = 86;грамм, на следующе = 84; этапе квалификацl= 0;онного тестированl= 0;я компонентоk= 4; следовало ожидать обнаружениn= 3; около 2,12 ошибок на ты= 089;ячу строк исходного кода. В случае сохр = 72;нения той же закон= 086;мерности, в момент поставки кл = 80;енту на испытани= 03;, программныl= 1; продукт мог содержать менее 0,07 ошибо= ;к на тысячу строк кода. Отмечается также, что частость проявления 0,1 – 0,05 ошибок на тысячу стро = 82; кода, можно считать допустимымl= 0; для ответст = 74;енных систем реального времени. <o:p></o:p> В исследованl= 0;ях 20 крупных поставляемm= 9;х программныm= 3; продуктов, созданных в 13 различных организациn= 3;х коллективы специалистl= 6;в добились среднего уровня 0,06 дефе= ;кта на тысячу строк новог = 86; и измененно = 75;о программноk= 5;о кода. При использоваl= 5;ии структурноk= 5;о метода в пят= 080; проектах достигнуто 0,04 – 0,075 ошибок на тысячу стро = 82;. Таким образом, уровенn= 0; ошибок окол = 86; 0,05 на тысячу строк кода = 074; разных публикацияm= 3; считается близким к предельном&#= 1091;, для высококачеl= 9;твенных программныm= 3; продуктов. <o:p></o:p> Другим примером оценок уровня ошиб = 86;к критическоk= 5;о ПС особенно высокого ка = 95;ества может служить программныl= 1; продукт бор = 90;овых систем Ш = 72;тла, созданный NASA= . По оценке авторов в не= 084; содержится = 84;енее одной ошибк = 80; на 10000 строк кода. Однако стоимость программноk= 5;о продукта достигает 1000 $ за строку кода, что в среднем в ст= 086; раз больше, чем для администраm= 0;ивных систем и в десять раз больше, чем – для ряда орд= 080;нарных критическиm= 3; управляющиm= 3; систем реал= 00;но времени. <o:p></o:p> Привk= 7;денные характерисm= 0;ики типов дефек = 90;ов и количествеl= 5;ные данные могу = 90; служить ориентирамl= 0; пl= 8;и прогнозироk= 4;ании возможного наличия не выявленных ошибок в ЖЦ различных сложных ПС в= 099;сокого качества. Следующим логическим шагом процесса их оценивания может быть усреднение для большог = 86; числа проектов фактическиm= 3; данных о кол= 080;честве ошибок на конкретном предприятиl= 0;, приходящихl= 9;я на тысячу строк кода, которые обнаружены в различных П = 57;. Тогда в следующем проекте буд = 77;т иметься воз = 84;ожность использоваl= 5;ия этих данных,<sp= an style=3D'mso-spacerun:yes'> в качk= 7;стве меры количества ошибок, обнаружениk= 7; которых следует ожидать при выполнении проекта с таким же уровнем качества ПС, или с целью повышения производитk= 7;льности при разработке для оценки момента прекращениn= 3; дальнейшегl= 6; тестированl= 0;я. Подобные оц = 77;нки гарантируюm= 0; оm= 0; избыточногl= 6; оптимизма при определениl= 0; сроков и при разработке = 75;рафиков разработки, = 089;опровожден&= #1080;я и реализаци = 80; модификаци&= #1081; программ с заданным качеством. Непредсказm= 1;емость конкретных ошибок в программах приводит к целесообраk= 9;ности последоватk= 7;льного, методичногl= 6; фиксированl= 0;я и анализа возможностl= 0; проявления = 83;юбого типа дефектов и необходимоl= 9;ти их исключен = 80;я на наиболее ранних этапах ЖЦ ПС прl= 0; минимальныm= 3; затратах. <o:p></o:p></span= > <o:p> </o:p> <h1><a name=3D"_Toc508102488"></a><a name=3D"_Toc508102261">10.3. Риски в жизненном цикле сложных программныm= 3; средств</a></h1> <o:p> = ;</o:p> </sp= an>Прич= 080;нами возникновеl= 5;ия и проявлени= 03; рисков могу = 90; быть: злl= 6;умышленные, активные воздействиn= 3; заинтересоk= 4;анных лиц или слm= 1;чайные негативные проявления дефектов внешней среды, системы или пользоватеl= 3;ей. В первом случае риск = 80; могут быть о= 073;условлены искажениямl= 0; прогр= ;амм и информациоl= 5;ных ресурсов и и= 093; уязвимостьn= 2; от предумыш = 83;енных, внешних воздействиl= 1; (атак) с целью незаконногl= 6; использоваl= 5;ия или искажен = 80;я информации = 80; программ, ко= 090;орые по своему содержанию предназначk= 7;ны для примене = 85;ия ограниченнm= 9;м кругом лиц. Для решения этой проблемы созданы и активно раз = 74;иваются методы, средства и стандарты обеспечениn= 3; защиты прог = 88;амм и данных от <s= pan style=3D'font-size:14.0pt;color:windowtext;mso-bidi-font-weight:normal; mso-bidi-font-style:italic'>предумm= 9;шленных негативных внешних воздействиl= 1;. Специфичесl= 2;ие факторы обеспечениn= 3; информациоl= 5;ной безопасносm= 0;и и риски, характерныk= 7; для сложных информациоl= 5;ных систем – целостностn= 0;, доступностn= 0; и конфиденц = 80;альность информациl= 6;нных ресурсов, а также ряд типовых процедур си = 89;тем защиты – криптографl= 0;ческая поддержка, идентификаm= 4;ия и аутентификk= 2;ция, защита и сохранностn= 0; данных поль = 79;ователей при предумышлеl= 5;ных атаках из внешней среды, далее не рассматр = 80;ваются.<o:p></o:p> Рl= 0;ски при случайных, дестабилизl= 0;рующих воздействиn= 3;х дефектов программныm= 3; средств и отсутствии предумышлеl= 5;ного негативногl= 6; влияния на систе= ;мы, ПС или инфор= 084;ацию баз данных существеннl= 6; отличаются от предшествуn= 2;щих задач. Эти риски объек = 90;ов и систем зависят от отказовы = 93; ситуаций, от= 088;ицательно отражающихl= 9;я на работосп = 86;собности и реализаци = 80; их основных функций, причинами которых могут быть дефек = 90;ы и аномалии в аппаратуре, программах, данных или вычислителn= 0;ных процессах. П= 088;и этом катаст = 88;офически, критически или существеннl= 6; искажается процесс функционирl= 6;вания систем, что может наносить значительнm= 9;й ущерб при их применении. Основными источникамl= 0; отказовы = 93; ситуаций могут быть некорректнm= 9;е исходные тр = 77;бования, сбои и отказ= 099; в аппаратур = 77;, дефек= ;ты или ошибки в программах = 80; данных функ = 94;иональных задач, прояв= 083;яющиеся при их испол= 085;ении в соответствl= 0;и с назначениеl= 4;. При таких воздействиn= 3;х, внешняя, функционалn= 0;ная работоспосl= 6;бность систем мож = 77;т разрушатьсn= 3; не полность= 02;, однако невозможно полноценноk= 7; выполнение заданных функций и требований = 82; качеству информации для потребителk= 7;й. Вредн= ;ые и катастрофиm= 5;еские последствиn= 3; таких отказов в ряде областей применения систем могут превышать п = 86; результатаl= 4;, последствиn= 3; злоумышленl= 5;ых воздействиl= 1;, имеют свою природ = 91;, особенностl= 0; и характерисm= 0;ики. <o:p></o:p> Рассматриk= 4;аемые риски могут = 073;ыть обусловленm= 9; нk= 2;рушениями технологий или ограничениn= 3;ми при использоваl= 5;ии ресурсов – бюджета, планов, колл= 077;ктива специалистl= 6;в, инструментk= 2;льных средств, выделенных на разработку ПС. Результируn= 2;щий ущерб = 74; совокупносm= 0;и зависит от велич= ;ины и вероятностl= 0; проявления каждого негативногl= 6; воздействиn= 3;. Этот ущерб – риск характеризm= 1;ется разнообразl= 5;ыми метриками, зависящими от объектов анализа, и в некоторых случаях может измер= 03;ться прямыми мат = 77;риальными, информациоl= 5;ными, функционалn= 0;ными потерями применяемыm= 3; ПС или систе= 084;. Одним из косвенных методов определениn= 3; величины риска может быть оценка совокупных затрат, необходимыm= 3; для ликвида = 94;ии негативных последствиl= 1; в ПС, системе или внешней среде, прояв= 080;вшихся в результат = 77; конкретногl= 6; рискового события. <o:p></o:p> Процессы анализа и сокращения рисков должны сопутствовk= 2;ть основным этапам разработки = 80; обеспечениn= 3; ЖЦ сложных п= 088;ограммных средств k= 4; соответстk= 4;ии с междунаро = 76;ными стандартамl= 0;, а также мето= 076;ам систем обеспечениn= 3; качества ПС. Эти процесс = 99; могут быть отражены пn= 3;тью этапами работ и процедур, которые рекомендуеm= 0;ся выполнять при поддержке базовых работ жизненного цикла проектов сложных программныm= 3; средств, и могут служить основой для разработки соответствm= 1;ющих планов рабо = 90; при управлении = 80; сокращении рисков – рис. 1= 0.3:<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>а = 85;ализ рисков следует начинать с подготовки детальных исходных требований = 80; характерисm= 0;ик проекта ПС, системы и внешней сре = 76;ы, для которых должны отсутствовk= 2;ть риски функционирl= 6;вания и применени= 03;;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>д = 83;я управления рисками и их сокращения = 74; рассматривk= 2;емых проектах сл = 86;жных комплексов программ ре = 82;омендуется выделять тр = 80; класса риск = 86;в: функционалn= 0;ной пригодностl= 0; ПС, конструк= 090;ивных характерисm= 0;ик качества и нарушения ограничениl= 1; ресурсов пр = 80; реализации процессов Ж = 62; ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>в каждом классе предлагаетl= 9;я анализировk= 2;ть несколько категорий наиболее важных рисков, которые упо = 88;ядочивать по степени опасности, угроз для проекта, обусловленl= 5;ых ограничениn= 3;ми ресурсов, дефектами и/или недост= 072;точным качеством разработки = 80; жизненного цикла ПС;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>к = 86;нтрмеры для сокращения рисков рекомендуеm= 0;ся анализировk= 2;ть и применять последоватk= 7;льно, начиная с ликвидации наиболее опасных исх = 86;дных причин – угроз, затем проводить анализ и уменьшение уязвимости компонентоk= 4; и ПС в целом, а при недостаточl= 5;ости этих контрмер воздействоk= 4;ать непосредстk= 4;енно на уменьшен = 80;е итогового ущерба – риска в жизненном цикле ПС и системы;<o:p></o:p> <![if !supportLists]>- &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = &nb= sp; = <![endif]>п = 88;оцессы устранения рисков должны завершатьсn= 3; проце= ;дурами мониторингk= 2;, сопровождеl= 5;ия и конфигура = 94;ионного управления изменениямl= 0; версий комплексов программ высокого качества с минимальныl= 4;и допустимымl= 0; рисками. <o:p></o:p> Таким образом, в жизненном ц = 80;кле программныm= 3; средств ущерб – риск= 080; могут проявлятьсn= 3; – рис.10.4:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в искажениях или не полно= 081; реализации требуемого назначения, функций или взаимодейсm= 0;вия ПС с компоне= 085;тами системы или внешней среды – недос= ;татками и дефектами <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>фm= 1;нкциональн= 086;й пригодностl= 0; комплексов = 87;рограмм;<o:p></o:p></sp= an> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в недостаточl= 5;ых и не соответствm= 1;ющих требованияl= 4;, кl= 6;нструктивн= 099;х характерисm= 0;иках качества ПС при его функционирl= 6;вании и применени = 80; по прямому назначению;<o:p= ></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>в нарушениях ограничениl= 1; на использоваl= 5;ие э= ;кономическ = 80;х, временных или техническиm= 3; ресурсов при создани = 80; и применени = 80; ПС.<o:p></o:p> Анализ и оценка рисков долж = 85;ы начинаться = 89; исследованl= 0;я понятий, требований = 80; функций, способ= ствующих одобр= ;ению и применени= 02; заказч&#= 1080;ком и пользоватеl= 3;ями конкретногl= 6; программноk= 5;о продукта. Пр= 080; этом должны быть определены требования = 82; характерисm= 0;икам ПС и оценки возможного ущерба при и= 093; нарушении. = 048;сследовани&= #1103; процессов р = 72;зработки проектов ПС показали, что во многих случаях стоимость и длительносm= 0;ь их реализац = 80;и значительнl= 6; превышали предполагаk= 7;мые, а характери = 89;тики качества не соответствl= 6;вали требуемым, что наносил = 86; ущерб заказ = 95;икам, пользоватеl= 3;ям и разработч = 80;кам. Эти потери – ущерб проектов, могли бы быт= 100; значительнl= 6; сокращены своевременl= 5;ым а= ;нализом, прогнозироk= 4;анием и корректироk= 4;анием рисков воз = 84;ожного нарушения требований контрактов, техническиm= 3; заданий и спецификацl= 0;й на характер = 80;стики, выделяемые ресурсы и технологию создания ко = 84;плексов программ. <o:p></o:p></span= > Управ= ления рисками предполагаk= 7;т ясное понимание в = 85;утренних и внешних причин и реальных источников угроз, влияющи= 093; на качество проекта ПС, к&#= 1086;торые могут привести к его провалу или большом = 91; ущербу. В результате анализа следует создавать план отслеж= ивания изменения рисков в жизненном цикле ПС, который должен регу = 83;ярно рассматривk= 2;ться и корректироk= 4;аться. Главн= 086;й целью управления рисками является обнаружениk= 7;, идентификаm= 4;ия и контроль з= 072; редко встре = 95;ающимися ситуациями = 80; факторами, которые при = 74;одят к негативны = 84; – рисковым резул= ;ьтатам проекта. Это должно отра = 78;аться на прим= енении регламентиl= 8;ованных процессов, в которых факторы и уг= 088;озы рисков систематичk= 7;ски идентифициl= 8;уются, оцениваютсn= 3; и корректир = 91;ются.<o:p></o:p> Одной из самых распростраl= 5;енных причин и опасных источников рисков, явля= 102;тся ошиб = 82;и при оценке масштаба – размера проектk= 2; или программноk= 5;о продукта (см. лекцию 5). Эти ошибки, чаще всего, бываю= 090; случайными R= 11; непредумышl= 3;енными, вследствие недостаточl= 5;ой компетентнl= 6;сти заказчика или разрабо = 90;чика-постав&= #1097;ика. Однако в некоторых случаях в превышении значения со = 75;ласованног&#= 1086; масштаба заказанногl= 6; продукта могут быть заинтересоk= 4;аны разработчиl= 2;и для получения больших ресурсов от заказчика, а уменьшеннуn= 2; оценку масштаба мо = 75;ут стремиться представитn= 0; заказчики для с= окращения выделяемых = 79;атрат на разработ = 82;у проекта или программноk= 5;о продукта. Величина оцененного = 80; согласованl= 5;ого между заказчиком = 80; разработчиl= 2;ом масштаба ПС непосредстk= 4;енно отражается на:<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>бюд= жете и трудоемкосm= 0;и разработки = 80; обеспечениn= 3; всего жизне = 85;ного цикла программноk= 5;о продукта;<o:p></o:p>= <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>зат= ратах времени и сроках с= ;оздания и всего жизненного цикла реали = 79;ации и применени= 03; ПС;<o:p></o:p> <![if !supportLists]><sp= an style=3D'font-size:14.0pt'>- &nb= sp; <![endif]>п = 86;требности в численност= 080; и квалификацl= 0;и специалистl= 6;в-разработ</sp= an>-чиков дл= 103; реализации проекта и создания программноk= 5;о продукта в соответствl= 0;и с требованияl= 4;и заказчика.<o:p></o:p>= Эти три ключевых ха = 88;актеристик обычно тесн = 86; связаны и могут измен= 03;ться в процессах разработки проекта заказчиком или разработчиl= 2;ом в сторону увеличения или уменьше = 85;ия в соответствl= 0;и с их интерес= 072;ми, целями и возможностn= 3;ми. При стремлении = 79;аказчика сократить сроки реали = 79;ации проекта может требоватьсn= 3; увеличить б= 02;джет (трудоемкос = 90;ь) и численностn= 0; специалистl= 6;в. При объективно недостаточl= 5;ом числе и квал= 080;фикации специалистl= 6;в, естественнl= 6;, возрастают сроки создания пр = 86;граммного продукта и, возможно, бюджет прое = 82;та. Практическl= 0; всегда основным фактором, определяющl= 0;м значения и взаимосвязn= 0; этих важней = 96;их характерисm= 0;ик и их рисков, при создании сложных ПС, является оценка и отс= 083;еживание масштаба проекта, а также его согласованl= 0;е между заказ = 95;иком и разработч = 80;ком. <o:p></o:p></spa= n> Для снижения во = 79;можного ущерба – рисков применяютсn= 3; оценки, контроль и мониторинг рисков, а также различные контрмеры. Уменьш = 77;ние рисков должно производитn= 0;ся путем макси = 84;ально возможного приближениn= 3; проекта к требованияl= 4; заказчика и = 082; выделенным ресурсам ил = 80; путем сниже = 85;ия этих требов = 72;ний и увеличени= 03; заказчиком ресурсов на проект ПС. В крупных проектах систем, испо= 083;ьзующих комплексы п = 88;ограмм, риски могут быть обусловленm= 9; дефектами функционалn= 0;ных характерисm= 0;ик самих ПС и их жизненного цикла, а также недостаткаl= 4;и систем и внешней среды, в которой они используютl= 9;я. Основной ущерб от рисков ПС проявляетсn= 3; в последств = 80;ях их применения – в дефектах и недостаткаm= 3; функционирl= 6;вания систем и внешней среды. Поэтому анализ и оценка рисков ПС должны быть тесно связаны с исследованl= 0;ем их проявления = 74; системах, гд= 077; они использ = 91;ются. <o:p></o:p> Риски ПС могут проявлятьсn= 3; в процессах проектировk= 2;ния, разработки = 80; сопровождеl= 5;ия при изменении и развитии комплексов программ и при применении готового пр = 86;граммного продукта по прямому назначению. Это приводи = 90; к необходимоl= 9;ти анализа рис = 82;ов функционирl= 6;вания ПС в условиях, ра= 079;личающихся:= <o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>и = 89;точниками и причинами </s= pan>угроз и опасного проявления рисков;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>к = 83;ассами, категориямl= 0;, уяk= 9;вимостью ПС и системы, вероятностn= 0;ю проявления = 80; величиной последствиl= 1; рисков;<o:p></o:p> <![if !supportLists]>-&nb= sp; = <![endif]>в = 86;зможными и реализуемыl= 4;и контрмера = 84;и для сокращения рисков и их э&#= 1092;фективност= ью.<o:p></o:p> Оц= енка и измерение рисков во многих случ = 72;ях характеризm= 1;ется значительнl= 6;й неопределеl= 5;ностью и применениеl= 4; качественнm= 9;х метрик. Факт= 086;ры и угрозы рисков могу = 90; быть распределеl= 5;ы, и отличатьс= 03; уязвимостьn= 2; по этапам жизненного цикла ПС и системы. При анализе и управлении рисками целесообраk= 9;но выделять, прежде всего, наиболее х = 72;рактерные этапы ЖЦ ПС: технико-эко = 85;омического обоснованиk= 7; проекта ПС; разработку требований спецификацl= 0;й; проектировk= 2;ние; кодированиk= 7;; тестированl= 0;е; и документирl= 6;вание. <o:p></o:p> <s= pan style=3D'font-size:14.0pt'> Неопр= еделенностn= 0; оценок мас = 96;таба комплексов = 80; компонентоk= 4; программ яв = 83;яется одним из важнейших факторов, влияю= 097;им на риски всего жизне = 85;ного цикла проекта ПС (см. лекцию 5). Точнос&= #1090;ь оценки разм = 77;ра нового ПС значительнl= 6; повышаетсn= 3; после формулировk= 2;ния начальных требований = 80; спецификацl= 0;й заказчиков, проведения анализ&#= 1072; требований, после завершения разработки предваритеl= 3;ьного проекта. На этап&= #1077; концепции проекта, ошибки оценки разм = 77;ра ПС ум&#= 1077;ньшаются приблизитеl= 3;ьно до 40%. Это вполне объяснимо, поскольку еще не уточнены структура и многие детали проекта. Эти вопросы могут быть р= 072;зрешены во время разработки структуры и спецификацl= 0;й треб= ;ований к ПС и тогда можно оцени = 90;ь размер ПС с точностью до 15 – 20% . <o:p></o:p><= /span> Как только структура П = 57; будет разбита с учетом выделения с = 72;мых нижних, дост= 091;пных уровней компонентоk= 4;, может быть с= 086;здан более точны = 81; показатель размера ком = 87;лекса программ. Пр= 080; этом исполь = 79;уются процессы измерения и суммированl= 0;я. После &#= 1079;авершения разработкl= 0; и подтверждения проектных спецификацl= 0;й при детальн = 86;м проектировk= 2;нии комплекса программ может быть определена структура внутренних данных и функции программныm= 3; компонентоk= 4;. На этом этапе, оценка размера проекта ПС может соста = 74;ить около 10%. Уточнения размеров ПС = 080; компонентоk= 4;, могут быть решены = 082; концу детального проk= 7;ктирования, однако при этом сохраняетсn= 3; неопределе&#= 1085;ность оценки разм = 77;ра комплекса программ около 5 – 10%, связанная = 89; тем, насколько хорошо прог = 88;аммисты пони = 84;ают спецификацl= 0;и, в соответствl= 0;и с которыми они должны кодиро&#= 1074;ать программу. </s= pan><o:p></o:p> = 42; рассматривk= 2;емом ниже пример = 77; проекта ПС средние ошибки оценивания = 84;асштаба могут быть больше или меньше реал= 00;ных значений, чт= 086; по-разному отражается на характери= 089;тиках договора с з= 072;казчиком на проект, а также на факторах и типах риско = 74; – рис. 10.5. Если масштаб проекта ПС в &#= 1076;оговоре завышеl= 5;, то следстви = 77;м могут быть, прежде всего, риски – ущерб экономичесl= 2;их категорий R= 11; превышения планируемm= 9;х ресурсов: стоимости, трудоемкосm= 0;и, длительносm= 0;и разработки = 80; числа необх = 86;димых специалистl= 6;в. При этом заказчик терпит убытки, разр= 072;ботчик получает неоправданl= 5;ую прибыль. При<sp= an style=3D'mso-spacerun:yes'> реализациl= 0; функционалn= 0;ной пригодностl= 0; и конструктиk= 4;ных характерисm= 0;ик ПС разработ = 95;ик может свобо = 76;но использоваm= 0;ь ресурсы и не предпринимk= 2;ть жестких мер для их эконо= 084;ии, что может отразиться на эффективноl= 9;ти последующеk= 5;о применения комплекса п = 88;ограмм.<o:p></o:p> Если при оценке масштаба пр = 86;екта ПС его величина в договоре определена нk= 7;достаточно= 081; – заниженно = 81;, то основной ущерб – риск= 080; достаются р = 72;зработчика&#= 1084;. Они вынужде = 85;ы принимать жесткие мер = 99; для выполне = 85;ия плановых сроков, выделенногl= 6; бюджета работ при относительl= 5;о малом числе специалистl= 6;в, что угрожае = 90; рисками срыва сроко = 74; и нарушения стоимости проекта. Недооценка размера проекта комплекса программ и ресурсов дл= 03; его реализации, = 084;ожет резко увеличиватn= 0; число дефектов в п= 088;ограммах. Кроме того, ограниm= 5;енные ресурсы дл= 03; реализации = 74; полном объеме функционалn= 0;ной пригодностl= 0;, могут отражаться на ее качестве и удобстве применения, = 072; также на конструктиk= 4;ных характерисm= 0;иках: на безопасносm= 0;и, надежности, качестве взаимодейсm= 0;вия с внеm= 6;ней средой и с пользоватеl= 3;ями, качестве до = 82;ументации и других эксплуатаm= 4;ионных факторах. <o:p></o:p> Оце= нки масштаба проекта ПС и рисков долж = 85;ы быть проана = 83;изированы и скорректи = 88;ованы для установленl= 0;я в договоре м= 077;жду заказчикамl= 0; и разработч = 80;ками исходного компромиссl= 5;ого масштаба, допустимогl= 6; для разработки первичных спецификацl= 0;й требований = 89; требуемым качеством. Некоторые требования могут потребоватn= 0; изменения (обычно увел= 080;чения) масштаба, и соответствk= 7;нно ресурсов на этапах предваритеl= 3;ьного и детальног = 86; проектировk= 2;ния для обеспечениn= 3; возможностl= 0; реализации требуемой функционалn= 0;ной пригодностl= 0; с допустимымl= 0; рисками.<o:p></o:p> <o:p= ></o:p> <h1> <a name=3D"_Toc508102489"></a><a name=3D"_Toc508102262">10.4. Риски пр = 80; формированl= 0;и требований = 82; характерисm= 0;икам сложн= ;ых программныm= 3; средств</a><o:p></o:p></sp= an></h1> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'><o:p> </o:p> <s= pan style=3D'font-size:14.0pt;mso-fareast-font-family:"MS Mincho";color:windowt= ext'> Для продолжениn= 3; разработки проекта пос = 83;е оценки рисков масштаба комплекса программ, необходимо выполнить цикл поэтап = 85;ого определениn= 3; и формированl= 0;я сово = 82;упности спецификацl= 0;й требований = 82; проекту ПС. Первым этапом является создание концепцl= 0;и проекта ПС и комплекса первичных т = 88;ебований к иерархичесl= 2;ому набору функций, на которые могут быть разбиты предполагаk= 7;мые фактическиk= 7; компоненты ПС. В дальней&#= 1096;ем разбиение может детализироk= 4;аться, формируя уп = 88;ощенный или более точный уров = 77;нь абстракции = 80; взаимодейсm= 0;вия компонентоk= 4;. Поэтапная разработка спецификацl= 0;й требований проекта ПС выпол= ;няется итерационнl= 6; после первичной оценки масштаба проекта ПС и обусловленl= 5;ых такими оценками рисков, вследствие ошибок размера в большую или меньшую сто = 88;ону (см. рис. 10.5). Ограничениn= 3; при прогноз = 80;ровании требований, <sp= an style=3D'mso-bidi-font-style:italic'> = ;определя= 02;тся, прежде всег = 86;, имеющимися данными, которые могут быть и= 089;пользован= 099; в качестве исходных аналогов ил = 80; обобщенных характерисm= 0;ик. <o:p></o:p> Для устранения или снижени= 03; рисков до допустимых пределов мо = 78;ет быть необхо = 76;имо изменение требований = 82; функционалn= 0;ной пригодностl= 0;, к конструкт = 80;вным характерисm= 0;икам и доступным ресурсам. Поэтому на этапах проектировk= 2;ния последова = 90;ельно должны определятьl= 9;я: <o:p></o:p> <p class=3DMsoBodyTextIndent2 style=3D'margin:0cm;margin-bottom:.0001pt;tex= t-align: justify;text-indent:35.45pt;line-height:normal;mso-list:l210 level1 lfo164; tab-stops:list 14.2pt 71.25pt;mso-layout-grid-align:none;text-autospace:non= e'><![if !supportLists]>- &nb= sp; <![endif]> при проектировk= 2;нии концепции и первичной оценке масш = 90;аба проекта = - предваl= 8;ительные требования = 82; назначению, функционалn= 0;ной пригодностl= 0; и к номенклатуl= 8;е необходимыm= 3; конструктиk= 4;ных характерисm= 0;ик качества ПС; <o= :p></o:p> при предваритеl= 3;ьном проектировk= 2;нии <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-weight:bold'>-</span= > уточненная оценка масштаба проекта, требованиn= 3; к функциона = 83;ьным и конструктиk= 4;ным характерисm= 0;икам качества с учетом общи = 93; ограничениl= 1; ресурсов, перечень ис = 90;очников угроз и величины возможных рисков;<o:p></o:p> при детальном проектировk= 2;нии <span style=3D'font-size:14.0pt;font-family:Symbol;mso-ascii-font-fa= mily: "Times New Roman";mso-hansi-font-family:"Times New Roman";mso-char-type:sym= bol; mso-symbol-font-family:Symbol;mso-bidi-font-weight:bold'>-</span= > под= робные спецификацl= 0;и требований = 82; функционалn= 0;ным и конструкт = 80;вным характерисm= 0;икам качества с детальным учетом и распределеl= 5;ием реальных ог = 88;аниченных ресур= ;сов, а также интегральнm= 9;е риски при их</s= pan> оптимизацl= 0;я по критерию = 082;ачество/зат= раты.<o:p></o:p> На этапе со= 079;дания концепции и системного анализа фор = 84;ируются цели разраб = 86;тки проекта ПС, выбираются методы и алгоритмы решения основных, функциональны&#= 1093; задач, а также формулируюm= 0;ся предваритеl= 3;ьные критерии качества создаваем= ых программ. Пр= 080; этом, естественнl= 6;, встает вопрос о ресурсах, которые потребуютсn= 3; для достижения = 94;елей, и о возможностl= 0; их реализации. </s= pan>Целенаправ&= #1083;енная и методична= 03; экспертная оценка возможного масштаба и ресурсов пр = 86;екта уменьшает величину риска, однако, обычно она остается все-таки довольно бо = 83;ьшой. <o:p></o:p> До завершения разработки первичного техническоk= 5;о задания на П= 057; могут быть сформулироk= 4;аны только приближен = 85;ые исходные требования, </s= pan>отража= ;ющие объект разр = 72;ботки и условия ег= 086; создания. Посл= ;е выбора технологии, средств автоматизаm= 4;ии разработки = 80; техн= ологическиm= 3; ЭВМ появляется возможностn= 0; достоверно учесть эти исходные да = 85;ные для подготовки уточненногl= 6; сценария разработки. Регистрациn= 3; этих данных </s= pan>може= ;т служить дополнителn= 0;ным ориентиром для оценки п= 086;лных р= ;есурсов на разработку, = 080; возможных р = 80;сков.<o:p></o:p> </spa= n>Разрабо= ;тку и утверждениk= 7; спецификацl= 0;й требований = 82; функционалn= 0;ным характерисm= 0;икам и качеству П= 057; с учетом анализа рис = 82;ов, целесообраk= 9;но проводить итерационнl= 6; на этапах предваритеl= 3;ьного и детальног = 86; проектировk= 2;ния. Чем крупнее и сл= 086;жней проект ПС и соответствk= 7;нно выше его стоимость, тем тщательнее следует разрабатывk= 2;ть требования = 82; его характерисm= 0;икам и распределяm= 0;ь ресурсы на и= 093; реализацию. Поэтому при средней и относительl= 5;о невысокой сложности П = 57; во многих случаях мож = 85;о удовлетворl= 0;ться подготовкоl= 1; требований = 82; комплексу п = 88;ограмм с подробностn= 0;ю анализа, соответствm= 1;ющего предваритеl= 3;ьному проектировk= 2;нию. Для крупных = 080; особо сложных проектов необходим более детальl= 5;ый анализ факторов и рисков при разработке требований = 80; их оптимиза = 94;ия по критерию = 082;ачество/зат= раты. <o:p></o:p> При первоначалn= 0;ном определениl= 0; требований = 82; функционалn= 0;ной пригодностl= 0; и к конструктиk= 4;ным характерисm= 0;икам, заданные за = 82;азчиком ограничениn= 3; ресурсов не всегда могу = 90; учитывать ряд особенн = 86;стей и характери = 89;тик проекта, что обусловит недопустимl= 6;е снижение (ил= 080; завышение) требований = 82; некоторым характерисm= 0;икам или рискам ПС. Кроме тог&#= 1086;, возможно, чт= 086; некоторые характерисm= 0;ики противореm= 5;ивы или принцип = 80;ально нереализуеl= 4;ы в данном проекте. В результате не сбалансироk= 4;анные требования и досm= 0;упные ресурсы проявятся как риски – уще= 088;б в виде потер= 100; в качестве или в потребностl= 0; дополнителn= 0;ных ресурсов (см. рис. 10.5). <o:p></o:p> В зависимостl= 0; от сложност = 80; проекта окончательl= 5;ым результатоl= 4; работ при предваритеl= 3;ьном или детальн = 86;м проектировk= 2;нии должны быть детализироk= 4;анные и утвержденнm= 9;е требования = 82; номенклатуl= 8;е, свойствам и значениям качества и допустимым = 88;искам проекта ПС, которые достаточны для его полн= 086;ценного рабочего проектировk= 2;ния и последующ = 77;й, эффективноl= 1; эксплуатацl= 0;и. Однако на по= 089;ледующих этапах жизн = 77;нного цикла и при конфигурацl= 0;онном управлении, требования могут измен= 03;ться по согласов = 72;нию между заказ = 95;иком и разработчиl= 2;ом, которые чащ = 77; всего приурочиваn= 2;тся к подготовк = 77; новой версии= ПС. Для этого необх = 86;дим мониторинг масштаба проекта, требований = 80; реализаций характерисm= 0;ик и рисков в течение всего ЖЦ ПС. По = 89;ле определениn= 3; назначения = 80; функций ПС, подготовка исходных данных и концепции проекта должны завершатьсn= 3; выделением номенклатуl= 8;ы приоритетнm= 9;х конструктиk= 4;ных характерисm= 0;ик, имеющих достаточнl= 6; сильное влияние на функционалn= 0;ную пригодностn= 0; и сокращающиm= 3; риски ПС.<o:p></o:p> Принципиаl= 3;ьные и техническ = 80;е возможностl= 0;, точность реализации свойств и измерения значений характерисm= 0;ик ПС, а также оk= 3;щие ресурсы конкретноk= 5;о проекта вс = 77;гда ограничены = 74; соответствl= 0;и с их содержа= 085;ием и возможностn= 3;ми заказчика и разработчиl= 2;ов. Это определяет рk= 2;циональные диапазоны значений каждого риска, которые могут быть в= 099;браны для проекта ПС на основе требований = 79;аказчика, здравого смысла, а также путем анализа пилотных пр = 86;ектов и прецедентоk= 4; в спецификацl= 0;ях требований реализованl= 5;ых проектов. Пр= 080; ограниченнl= 6;сти ресурсов проекта ПС распределеl= 5;ие приоритетоk= 4; должно стан = 86;виться более строгим и могут снижаться приоритеты характерисm= 0;ик, для реализа = 94;ии которых рес = 91;рсов недостаточl= 5;о. В результат = 77; формируетсn= 3; полный набо = 88; требуемых функционалn= 0;ных и конструктиk= 4;ных характерисm= 0;ик, свойств и допустимыm= 3; рисков в ЖЦ ПС (см= ;. рис. 10.5). </span= ><o:p></o:p> Для разработчиl= 2;ов особенно ва = 78;но формализовk= 2;ть требования = 82; качеству и с= 086;гласовать их риски с заказчиком при утверждениl= 0; контракта и техническоk= 5;о задания на проект ПС. Требования = 82; функционалn= 0;ным характерисm= 0;икам, качеству и допустимым рискам, утвержденнm= 9;е после предваритk= 7;льного проектировk= 2;ния, могут быть закреплены = 74; техническоl= 4; задании как обязательнm= 9;е для детального = 80; рабочего пр = 86;ектировани&#= 1103;. Эти данные могут использоваm= 0;ься при последу= 02;щем оценивании качества и реальных рисков, и при их сопоставлеl= 5;ии с требовани= 03;ми в процессе к= 074;алификацио&= #1085;ных испытаний или сертифи = 82;ации ПС. Однако для крупном = 72;сштабных и дорогих проектов может потре = 73;оваться уточнение требований = 82; качеству при детальном проектировk= 2;нии с позиции улучшения с = 86;отношения значений качества и затрат ресу = 88;сов, которые необходимы или допустимы для их реали= 079;ации в ЖЦ ПС.&nbs= p; <o:p></o:p> = Для заказч = 80;ка и пользоватеl= 3;ей может иметь значение не только определениk= 7; функционаl= 3;ьной пригодностl= 0;, но и оценка потенциальl= 5;ого спроса на рынке конкретногl= 6; программноk= 5;о продукта, а также его кl= 6;нкурентосп= 086;собности с другими аналогичныl= 4;и по функциям ПС с учетом его качеств = 72; и стоимости. Это обстоятельl= 9;тво может определять необходимоl= 9;ть уточнения требований = 82; отдельным характерисm= 0;икам не только дл= 103; их реализац = 80;и разработчиl= 2;ами в ЖЦ ПС, но также для оценивания = 80;нтегрально&#= 1075;о качества го = 90;ового программноk= 5;о продукта по = 89;тавляемого на рынок. Для заказчиков = 80; пользоватеl= 3;ей интегральнl= 6;е качество и р= 080;ски сосредоточl= 0;ваются на функционалn= 0;ной пригодностl= 0; и метриках в использоваl= 5;ии. Для разработчиl= 2;ов важны, прежд= 077; всего, внутренние метрики и за= 090;раты ресурсов, пр= 080; которых они = 076;остигаются. Поэтому при оценивании интегральнm= 9;х характерисm= 0;ик особо сложных ПС необходимо детально учитывать это различи = 77; целей и инте= 088;есов их потребит = 77;лей. = <o:p></o:p> Обычно заказчики и разработчиl= 2;и первоначалn= 0;но устанавливk= 2;ют требования = 82; каждой характерисm= 0;ике ПС без учета относительl= 5;ых затрат на их достижение, = 072; также без детального анализа их с= 086;вместного влияния на полную функционалn= 0;ную пригодностn= 0; и риски у потребителk= 7;й. Это может приводить к значительнm= 9;м перекосам и <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>нk= 7;сбалансиро= 074;анным значениям требований </sp= an>к отдельным, взаимосвязk= 2;нным характерисm= 0;икам, на которые н= 077; рациональнl= 6; используютl= 9;я ограниченнm= 9;е ресурсы ЖЦ ПС, или к не адекватно н = 80;зким их значения = 84;. В проектах крупномасшm= 0;абных ПС это может угрожать значительнm= 9;м повышением стоимости и рисков и/или снижением конкурентоl= 9;пособности создаваемоk= 5;о программноk= 5;о продукта из-за недостаточl= 5;ого уровня отдельных показателеl= 1; качества.<o:p></o:p>= Атрибуты качества ПС имеют разли = 95;ные меры и шкалы, вследствие чего они в большинствk= 7; своем непос = 88;едственно не сопостав = 80;мы между собой. Они предваритеl= 3;ьно выбираются = 80; согласовывk= 2;ются с заказчико = 84; при последоватk= 7;льном, почти незав = 80;симом анализе каждого атрибута качества, дл= 103; использоваl= 5;ия в контракте = 080; техническоl= 4; задании. Для обобщенногl= 6; оцениваниn= 3; качества необходим учет относительl= 5;ого влияния и риска каждо = 81; конструктиk= 4;ной характерисm= 0;ики ПС, на функционалn= 0;ную пригодностn= 0;. При этом не всегда учитываютсn= 3; ресурсы для их реализац = 80;и в конкретном ПС. Это часто приводит к выдвижению ряда не раци= 086;нальных требований, которые значительнl= 6; отличаются: либо по степени влияния на функционалn= 0;ную пригодностn= 0;, либо по величине ресурсов, не= 086;бходимых для их реализации. <sp= an style=3D'mso-bidi-font-weight:bold;mso-bidi-font-style:italic'>Дl= 3;я целенаправl= 3;енного эффективноk= 5;о управления рисками сложного ПС</sp= an> при проектировk= 2;нии целесообраk= 9;но иметь механ = 80;зм объединениn= 3; разнородныm= 3; характерисm= 0;ик в некоторый = 080;нтегральны&= #1081; показатель, отражающий их совокупн = 86;е влияние на его функцио = 85;альную пригодностn= 0;. Таким образом, при разработке требований = 82; характерисm= 0;икам проекта выявилась проблема анализа системной эффек= ;тивности ПС и обобщения его характерисm= 0;ик, а также оценивk= 2;ния совместногl= 6; влияния конструктиk= 4;ных характер= ;истик на функционалn= 0;ную пригодностn= 0; ПС с учетом з&#= 1072;трат на их реализ= 072;цию. <o:p></o:p> = Для управления рисками и детального сопоставитk= 7;льного оценивания выбранных характерисm= 0;ик качества целесообраk= 9;но каждому из них присваиватn= 0; коэффициенm= 0; или приорит = 77;т влияния на функционалn= 0;ную пригодностn= 0;. Группа квалифицирl= 6;ванных экспертов и = 79; состава заказчиков, потенциальl= 5;ых пользоватеl= 3;ей и/или разраб= 086;тчиков должны оценивать и устанавливk= 2;ть значения таких коэффиm= 4;иентов – рисков (приоритето = 74;) в пределах унифицировk= 2;нной шкалы, например, от единицы до десяти, для конкретногl= 6; проекта ПС. Точность определениn= 3; коэффициенm= 0;ов вряд ли може= 090; превышать 10%, поэтому ко = 83;ичество градаций шк = 72;лы целесообраk= 9;но не больше десяти. Аналогичнl= 6;, по такой же шкале экспертами целесообраk= 9;но оценивать относительl= 5;ые затраты ресурсов, которые след