К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
8.2.3. Стандартизація процесів інженерії домену У стандарті ISO/IEC 12207: 2002 подано опис процесу доменної інженерії домену (Domain engineering process) як нового процесу в моделі процесів ЖЦ. Згідно з цим стандартом процес інженерії домену охоплює ряд видів діяльності: аналіз і проектування домену, а також технологію інженерії домену. Аналіз домену полягає у: – визначенні меж домену і зв'язків з іншими доменами; – виявленні, формальному описі спільних і різних особливостей усередині домену (постійних і змінних вимог) і включенні у модель домену; – формуванні словників для опису основних понять у домені і взаємозв'язків між активами в домені; Розділ 8 229 – класифікації і документуванні моделей; – оцінці моделей і словників домену з урахуванням вибраної методології моделювання. Проектування домену (Domain design) – це визначення архітектури домену за допомогою програмних компонентів, специфічних ресурсів, або активів (Assets). Крім цього стандарту, відмітимо проект стандарту комітету OMG (http:\\www.omg.org) з повторних компонентів RAS (Reusing Assets Specifications). У ньому пропонується формат опису інформації щодо повторно використовуваних ресурсів при розробці ПС, що є узагальненням поняття активу (asset) як програмного розв’язання деякої задачі в заданому контексті, яка належать до проблеми розробки ПС, а контекст визначає процес розроблення або виконання програмного продукту. Актив — це компонент або КПВ, тобто робочий продукт або засіб розробника, який може бути використаний в інших програмних розробках. Поняття активу можливо розуміти більш широко, воно відповідає поняттю готовий ресурс упрограмній інженерії. Архітектура домену – каркас з КПВ, активів і формально визначених інтерфейсів і вона повинна узгоджуватися з моделлю домену, стандартами організації і оцінюватися на відповідність вибраній методології архітектурного проектування. Технологія інженерії домену, що базується на новому процесі в моделі ЖЦ (ISO/IEC 12207) і понятті ресурсу (asset), містить у собі наступні стандартизовані підпроцеси: – формування ресурсів (asset provision), тобто розроблення або придбання ресурсів, які можуть використовуватися при компонуванні нових програмних систем або підсистем; – розроблення бази ресурсів (asset-based development), основою якої є концепція повторного використання (software reuse) – КПВ, що забезпечує компоновку програмних продуктів домена; – супровід ресурсів (Asset maintenance) – модифікація і еволюція моделі, архітектури і продуктів домену за рахунок готових ресурсів типу КПВ. Ця технологія припускає розробку методик і інструментів для ефективного виконання процесів ЖЦ а також для генерації системи із КПВ і компонентів багаторазового застосування відповідно до специфікацій вимог до системи та опису специфіки ПрО засобами спеціалізованих мов DSL. Застосування технології інженерії домену в організації, що створює ПС, не дає можливості підтримки і розвитку архітектурного базису з множини ресурсів типу КПВ, що зберігаються в репозитарії, враховують загальні і специфічні особливості різних сторін діяльності в технології інженерії ПрО. Основна мета інженерії ПрО – забезпечення багаторазового застосування використовуваних рішень для сімейства ПС, а в інженерії застосувань – серійне виробництво одиночних систем з використанням лінії виробництва конкретної ПС або деякого ринкового продукту, що базується на КПВ і вимогах до неї. 8.3. Інженерія індустріального виробництва програмних продуктів На даний час багатьма фірмами, що займаються випуском програмної продукції, створені технологічні і інструментальні умови для автоматизованого виробництва програмних продуктів. До умов відносять засоби і інструменти, 230 Розділ 8 процеси та технологічні лінії виготовлення продуктів. Фірми-виготовники проводять моніторинг для визначення запиту на деякий вид програмного продукту. Вони підготовляють команду розробників, будують технологічний базовий процес і здійснюють настройку інформаційного, технологічного і технічного станів середовища, що використовується для вироблення в ньому продукту. Об’єктами виробництва можуть бути прості і складні за своєю природою продукти ПП. В основному вони складаються з різного роду КПВ. До об’єктів виробництва формулюються загальні вимоги, в яких відображаються властивості всіх КПВ, а також властивості, специфічні для окремих представників компонентів системи. Більш точно, розглядаються обов'язкові, необов'язкові і альтернативні властивості КПВ. До обов'язкових властивостей належать такі, які обов'язково присутні в кожному з представників сімейства систем, хоча їхня реалізація може дещо розрізнятися. До альтернативних властивостей відносять властивості, які відображають особливості вибору представника сімейства, який використовується багато разів. Необов'язкові властивості відображають певні специфічні особливості або можуть бути відсутні. Створення програмних продуктів у середовищі на визначеній платформі залежить від її архітектурних особливостей, що можуть впливати на генерацію компонентів та програм. Відомими середовищами для виготовлення програмних продуктів є лінії виробництва (Product Line Practice), система Microsoft Visual Studio Teams Systems, Microsoft MSF, Eclips тощо. Розглянемо їх детальніше. 8.3.1. Структура лінії виробництва програмних продуктів Технологічні прийоми виробництва програмних продуктів з готових компонентів і програмних систем втілені у, так звані лінії продуктів, що відповідають конвеєрному виробництву програмних продуктів на ринковій основі. Виробництво систем виконується з множини компонентів КПВ, програм і ПС, які задовольняють специфічні потреби деякого ринку програмної продукції і показники якості. Концепцію лінії виробництва продуктів або лінії сімейства продуктів запропонував Американський інститут програмної інженерії SEI. Головна мета такої лінії – це виробництво нових систем з готових КПВ і ПС, які задовольняють певний сегмент ринку програмної продукції. Вона є підтримкою інженерії ПрО, у завдання якої входить застосування підходів і методів для автоматизованої технологічної побудови різних видів окремих програмних продуктів. При цьому в межах домену досліджуються ринок і потреби покупців, будується виробничий план, процеси і визначається організація їхньої взаємодії. Відповідно до потреб ринку будується технологічна лінія продукту, в яку включаються процеси, необхідні методи розробки, тестування і оцінки продуктів та процесів цієї лінії. Основу лінії становить інфраструктура, в яку входять групи розробників, різні методи і засоби інженерії ПрО, необхідні для побудови і експлуатації лінії виробництва продуктів (рис. 8.6) [10–12], а також відповідні керівні матеріали і методики. Побудова конкретної лінії виробництва програмного продукту для певного представника сімейства визначається: – обмеженнями, властивими майбутнім продуктам лінії; Розділ 8 231 – зразками і каркасами, які можуть використовуватися на лінії виробництва; – виробничими обмеженнями, стратегіями і методами; – набором засобів і інструментів автоматизації процесів виробництва продуктів на лінії. Р озроб лення окремих комп онентів Р озроблення лінії п родукту Р озроб лення продукту застосування Інж енерія П рО Інж енерія п родукту Рис. 8.6. Інфраструктура лінії програмного продукту На основі цих даних визначаються область дії лінії виробництва і набір базових засобів автоматизації, будується план створення продукту на ній, що враховує терміни, вартість і вимоги до керування виробництвом продукту шляхом: – контролю плану робіт і відстеження ходу вироблення продукту; – виявлення ризиків і керування ними в процесі проектування сімейства; – прогнозування вартісних і технічних ресурсів проекту; – застосування технології керування конфігурацією; – вимірювання і оцінки якості продукту. На лінії може видаватися декількох програмних систем за умови, коли вони: – поділяють спільний і керований набір якостей, – задовольняють специфічні потреби певного сегмента ринку, – розроблені з використанням спільного набору готових ресурсів. Ця множина програм є фактично сімейством, якщо для її членів визначені їхні спільні властивості, а також індивідуальні властивості окремих членів сімейства програмних продуктів. Напрям інженерії ПрО, а саме, лінія виробництва програмного продукту, розвивається за рахунок використання готових компонентів, що накопичуються в репозитаріях доменів з метою вибору готових функцій, компонентів КПВ для використання на виробничому процесі цієї лінії. 8.3.2. Технологічне виготовлення систем у середовищі Microsoft В зв’язку з відсутністю в Україні власно створених програмних середовищ для підтримки технологічних процесів розроблення ПП, в даному підрозділі дано опис засобів та інструментів фірми Microsoft (рис. 8.7), призначених для керування проектом підприємства EPM (Enterprise Project Management). До їхнього складу входять такі: – пакет інструментів VSTS-2005 (Visual Studio Teams Systems), орієнтований на розробку великих проектів за участю різних спеціалістів (аналітиків, менеджерів, тестувальників, програмістів, кодувальників и ін.), що можуть бути розташовані в різних географічних точках; – методологія MSF (Microsoft Solution Arhitecture), що призначена для побудови виробничій архітектури підприємства за допомогою ЖЦ розробки ПС (Software Development Life Cycle), стандарту PMBOK, моделей перспектив та процесів; – системи Professional Studio та Foundation Server для підтримки процесів проектування, кодування, тестування, формування версій ПП тощо; 232 Розділ 8 – системи CMMI Process Impovement для регулюванням строків розробки за інструментами технології Agile. Рис. 8.7. Архітектура середовища EPM Microsoft Пакет VSTS є сімейством продуктів, призначених для проектування ПС, взаємодії різних членів команди, а також для підбору, розподілу і виконання робіт щодо програмного проекту. Виконавці проектів поділені за чотирма категоріями з урахуванням їх рівня знань і навиків програмування систем (рис.8.8). Рис. 8.8. Категорії розробників в пакеті VSTS Кожний член отримає роботу відповідно до здібностей і виконує її за відповідними для категории засобами. Перехід з першої категорії на вищу категорію можливий за допомогою якісного виконання завдання або додаткового навчання. Спеціалісти четвертої групи це кваліфіковані і відповідальні за функціональну правильність розробки ПС. Розділ 8 233 Засобом підтримки процесу розроблення елементів ПС є IDE (Integrated Development Environment), а перевірка вимог, відстеження процесів і результатів розроблення з оцінюванням ступеня їхньої готовності виконує Microsoft Office Project й Microsoft Office Excel. Тестування елементів ПС здійснюється додатковими засобами, що інтегруються з Visual Studio. У середовищі VSTS є також такі засоби: – Microsoft SQL Server 2005, що забезпечує збереження усіх робочих результатів, вихідного коду й даних інтеграції зусиллями Team команди. Підтримка різних типів звітів членів команди і роботи порталу забезпечується інструментами Analysis і Reporting Services та SharePoint Portal Services; – Microsoft Project 2003 – альтернативний засіб для керівників проекту; – Microsoft Excel 2003 – альтернативний засіб для керування проектуванням ПС тощо. До основних елементів продукування ПП у середовищі VSTS відносять наступні. Вимоги до якості (quality of service), які визначають характеристики системи, а саме: продуктивність (performance), навантажувальна здатність (loadability), стійкість до перевантажень (stressability), наявність і доступність функцій (availability, accessibility), зручність експлуатації (serviceability) і простота обслуговування (maintainability). Завдання – це task, що визначає певні дії (наприклад, опис вимог, підготовка й виконання тестів тощо). Ризики, тобто визначення ймовірних подій або умов, що можуть негативно позначитися в майбутньому ПП, а також дії по їхню мінімізацію і зменшенню. Помилка – інформація про наявність у системі потенційної проблеми та шляхи її виправлення. Таким чином, середовище VSTS є прикладом колективного вироблення ПП. Для цього є багатий набір інструментів для керованої підримки процесу ЖЦ проекту за графіком, а також його відслідкування, оцінювання результатів на якість, відповідну вартість та строки виконання проекту. Засоби й інструменти методології MSF. Ця методологія – система стратегій, принципів і керування проектом побудови виробничої архітектури підприємства з урахуванням [15]: обсягів робіт у проекті, часу і вартості, кількості персоналу, комунікацій, закупівель і контрактів, ризиків. Модель архітектури підприємства розробляється за такими аспектами: бізнес, застосування, інформація, технологія. Для розроблення ПП створюється скоординований технологічний план, що відповідає пріоритетові архітектури й одержанню максимального ефекту при мінімумі витрат. При цьому дотримується баланс між цілями і вимогами ПС, головними проектними рішеннями, людськими і фінансовими ресурсами організації. Метод MSF базується на аналізі і розробці вимог до ПС, проектуванні проектних рішень, що враховують базові концепції підприємства і пріоритетності архітектури. Цей метод містить у собі набір моделей: – виробничої архітектури; – проектної групи; – процесу розроблення ПС; – керування ризиками; 234 Розділ 8 – процесу проектування; – застосування. Модель виробничої архітектури – це набір принципів для створення версії виробничої архітектури підприємства за чотирма перспективами: бізнес, область застосування, інформацію і технологію (рис. 8.9). Основна задача цієї моделі – пристосування виробничої архітектури до бізнес-цілей організації поетапний випуск серії послідовних версій, орієнтованих на зазначені пріоритети та їхне послідовне коректування для одержання цілевої виробничої архітектури. Рис. 8.9. Перспективи виробничої архітектури Бізнес-перспектива вміщує стратегії і плани переходу до поліпшеного стану підприємства, коли визначені глобальні цілі і задачі організації; види продуктів і послуг; бізнес-процеси реалізації основних функцій і зв'язків між ними. Інформаційна перспектива ґрунтується на можливостях організації автоматизувати бізнес-завдання на персональних комп'ютерах з використанням загальносистемних засобів, мереж, документів і таблиц БД, створених у процесі роботи організації. Технологічна перспектива призначена для регламентації дій розробників з створення архітектури шляхом опису інфраструктури і системних компонентів, необхідних для підтримки прикладної й інформаційної перспектив з використанням відповідних технологічних стандартів і сервісів. Модель проектної групи визначає ролі, обов'язки кожного учасника проекту і розподіл між ними відповідальності з урахуванням змісту проекту, розміру групи і кваліфікації учасників. Члени проектної групи аналізують плани робіт, виявляють взаємозв'язки і перевіряють роботи на функціональність. Модель процесу розробки ПС – це набір процесів, їх процесів, видів діяльності і результатів процесу розроблення ПС. Між цією моделлю і моделлю проектної групи встановлюється тісний зв'язок. Це дає можливість проводити контроль ходу розробки проекту, мінімізацію ризиків, підвищення якості і скорочення термінів виконання проекту. Члени проектної групи на процесі розробки створюють: код системи, конфігурацію, функціональну специфікацію і сценарії тестування. Вони також створюють інфраструктуру і документ на конфігурацію. До основних задач інфраструктури відносять: – залучення клієнтів до створення системи; Розділ 8 235 – установлення зв'язків з корпоративною мережею; – збереження даних, створюваних на різних комп'ютерах і розташованих на окремих територіях підприємства; – видача інформації про властивості продукту комп'ютерною мережею і т.п. Виконання цих задач базується на: – узгоджені інформаційних технологій з цілями бізнесу; – обґрунтовані змін і відповідних витрат з урахуванням майбутніх інвестицій; – удосконалені внутрішніх і зовнішніх зв'язків між підрозділами підприємства, а також між замовником, постачальником і т.п.; – керуванні ризиками проекту шляхом їх аналізу і виявлення найбільш істотних моментів ризику, реалізації стратегії їхнього усунення, планування і моніторингу ризиків. Модель процесу проектування визначає мету і задачі процесу розроблення виробничої архітектури за трьома фазами розробки, а саме, концептуальної, логічної і фізичної. На цих фазах виконується систематичний перехід від абстрактних концепцій до конкретних технічних рішень. Модель застосування – це трирівнева структура, створена сценарним методом проектування і розробки системи. Її мета – забезпечити наочність, рівнобіжне виконання робіт і різні зручності при експлуатації і розгортанні компонентів системи на комп'ютерах і в різних серверах. Таким чином, методологія MSF дає можливість проектувати програмне і інформаційне забезпечення підприємства за допомогою розглянутих принципів, моделей і методів вирішення задач цього підприємства. Скоротити час розробки ПС, домогтися максимальної відповідності процесів вартісним і часовим вимогам, а також підвищити якість програмних продуктів виконується з використанням моделі MSF for CMMI Process Improvement. У ній містяться набір формальних методик для оцінки бізнес-процесів і можливості компаній, що займаються розробкою ПС. Вона має засоби для зниження ризиків у великих проектах та одержання в майбутньому сертифікатів різних рівнів. 8.3.3. Загальна характеристика інструментів Rational Rose CASE-cистема Rational Rose [16] підтримує застосування мови моделювання UML для представлення архітектури ПС з об'єктів. Засоби проектування і моделювання загальної (або абстрактної) архітектури та моделі системи поступово уточнюються до конкретної (фізичної) моделі класів об'єктів щодо створюваної ПС. Результат моделювання – візуальна (діаграмна) логічна модель системи. Об’єктно-орієнтовані програмні і інформаційні системи представляються у вигляді файлів логічної моделі за мовою UML. На її основі проводиться кодування її елементів засобами МП (С++, Ada, Java, Basic, XML, Oracle). Для зв'язування програмного коду ПС з БД може застосовуватися система Delphi. Допускається зворотне проектування, тобто перетворення готової інформаційної системи (наприклад, на С++) або база даних (Oracle) у візуальну модель ПС. Мова UML отримала автоматизовану підтримку в системі Rational Rose, а деякі аспекти проектування з метою досягнення якості знайшли відображення у ряді інструментальних засобів, короткий опис яких додається нижче. |