К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
Висновок. Представлено результати досліджень проблематики якості ПС, що містить у собі методи інженерії якості, метрики, оцінки атрибутів показників якості і якості в цілому. Зазначається, що на оцінку якості ПС впливають методи інженерії вимог до ПС і методи, що гарантують досягнення заданих характеристик на ранніх процесах ЖЦ. Розглянуто моделі надійності, подано їхню класифікацію, наведено моделі марковського й пуассонівського типів, основані на кількості помилок й інтенсивності відмов при тестування ПС. Контрольні питання й завдання 1. Визначте поняття якість ПС і рівні моделі якості ПС. 2. Визначте характеристики якості ПС і їхнє призначення. 3. Які методи визначають показники якості? 4. Визначте метрики програмного продукту і їхні складові. 5. Які існують стандарти з якості ПС? 6. Назвіть основні цілі й завдання системи керування якістю. 7. Визначте типи моделей надійності і їхній базис. 8. У чому різниця марковських і пуассонівських моделей надійності? 9. Сформулюйте параметри й припущення моделі Джелинського. 10. Визначте процеси досягнення надійності на ЖЦ. 11. Що таке сертифікація програмного продукту? Список літератури до розділу 9 1. ISO/IEC 9126. Infofmation Technology. – Software Quality Characteristics and metrics. – 1997. 2. ДСТУ 2844–1994. Программные средства ЭВМ. Обеспечение качества. Термины и определения. 3. ДСТУ 2850–1994. Программные средства ЭВМ. Обеспечение качества. Показатели и методы оценки качества программного обеспечения. 4. ДСТУ 3230–1995. Управление качеством и обеспечение качества. Термины и определения. 5. Барлоу Р., Прошан Ф. Математическая теория надежности. Пер. с англ. М.: 1969. – 483 с. 6. Липаев В.В. Надежность программного обеспечения АСУ. – М.: Сов.радио, 1977. – 400 с. 7. Лаврищева Е.М. Методы программирования. Теория, инженерия, практика.–Киев: Наук. думка, 2006.–451с. 8. Гласс Г. Руководство по надежному программированию. – М.: Финансы и Статистика, 1982. – 256 с. 9. Тейер Т., Липов Р., Нельсон Э. Надежность программного обеспечения. – М.: Мир, 1981. – 325 с. 10. Мороз Г.Б., Лаврищева Е.М. Модели роста надежности программного обеспечения. – Киев: ИК АН УССР.–Препр. 92–38, 1992. – 23 с. 11. Meyer B. The role of Object–Oriented Metrics.–Computer, 1998.–№11.–P. 23–125. 12. Кулаков А.Ю. Оценка качества программ ЭВМ. – Киев: Технiка. – 1984. – 167 с. Розділ 9 281 13. Липаев В.В. Методы обеспечения качества крупномасштабных программных систем. – М.: СИНТЕГ. – 2003. – 510 с. 14. Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы качества программных систем. – Киев: Академпериодика.– Второе изд.– 2007. – 669 с. 15. NASA –STD–2201 / Software Assurance Standart, 1993. 16. John D. Musa, Anthony Iannino, and Kazuhira Okumoto. Software Reliability: Measurement, Prediction, Application. Whippany, NJ: McGraw–Hill, 1987. 17. Musa J.D. Okumoto K.A. Logarithmic Poisson Time Model for Software Reliability Measurement // Proc. Sevent International Conference on Software Engineering. – Orlando, Florida. – 1984. – P. 230–238. 18. Goel A.L. Software reliability models& Assumptions, Limitations and Applicability// IEEE Trans. – N2. – P. 1411–1423. 19. Sukert A.N., Goel A.L. A guidebook for software reliability assessment / Proc. Annual Reliability and Maintainability Symp. – Tokio (Japan). – 1980. – P. 186–190. 20. Jelinski Z., Moranda P. Software reliability research /Statistical computer performance evaluation W.–Freiberger, Ed. Academic Press. – 1972. – Р. 465– 484. 21. Shick G.J., Wolverton R.W. An analysis of computing software reliability models / IEEE Tras. Software Eng. – V.– SE–4. – № 2. – 1978. – P. 104–120. 22. Yamada S., Ohba M., Osaki S. S–shaped software reliability grows modeling for software error detection // IEEE Trans. Reliability. – 1983. – R– 32. – № 5. – P. 475–478. 23. Schneidewind N.F. Software Reliability Model with Optimal Selection of Failure Data // IEEE Trans. on Software Eng. – 1993. – № 11. – P. 1095–1104. 281 Розділ 10. МЕТОДИ КЕРУВАННЯ ПРОГРАМНИМ ПРОЕКТОМ 10.1. Менеджмент проекту Термін « проект» (від лат. Projectus – кинутий вперед) вперше було застосовано Юлієм Цезарем в Записках про Галльську війну. У наш час, коли для суспільства характерні високі темпи зростання будівництва та машинобудування, проект визначається як сукупність документів, необхідних для зведення споруд, виготовлення машин тощо. Наразі побутує визначення проекту як плану, задуму організації, влаштування, заснування будь- чого. Часто проект визначають як тимчасову справу, що призначена для створення унікальних продуктів, послуг чи результатів [1]. Проект слід відрізняти від операційної діяльності, оскільки операційна діяльність – це тривалий у часі і повторюваний процес, в той час, як проекти вважаються тимчасовими й унікальними. Кінцеві цілі проекту і операційної діяльності розрізняються. Завдання проекту – досягнення визначеної цілі, після чого проект завершується. Операційна діяльність, навпаки, забезпечує нормальну роботу бізнесу. Проект відрізняється від неї тим, що він завершується після розроблення визначених цілей. 10.1.1. Основні поняття та задачі З загальної точці зору проект (Project) – це унікальний комплекс взаємозалежних заходів, направлених на досягнення конкретної цілі з його створення за визначених вимог до строків, бюджету та характеристик очікуваних результатів від нього [2]. Кожний проект має такі особливості: – конкретні цілі, заради яких він здійснюється (підвищення фахового рівня, отримання додаткового прибутку, підвищення ефективності процесу тощо); – унікальність поставлених цілей, персоналу, умов реалізації продукту. Це позначає, що його можна вимірити як кінцеву ланку виробничого ланцюга, так і окремим елементом; – послідовність розробки від задуму та початку розроблення проекту до закінчення та утилізації всіх його компонентів. Таку послідовність називають ЖЦ проекту [2-6] і означає поступове виконання робіт проекту. Наприклад, зміст проекту формулюється в загальних рисах на ранніх процесах проекту, потім зміст деталізується і конкретизується у міру того, як команда проекту отримує повне розуміння цілей і результатів проекту; – тимчасовість, тобто будь-який проект має чіткий початок і чітке завершення, коли досягнуто цілі проекту чи стає зрозумілим, що цілі будуть, або не можуть бути досягнуті. Термін «тимчасовий» не обов’язково означає коротку тривалість проекту, він може викоатися декілька років, але в будь-якому разі його обмежують часом робіт; – конкретні ресурси, які в реальному житті є обмеженими: за кількістю, термінами, протягом яких вони можуть використовуватися, за якістю результату, Розділ 10 283 зокрема за рівнем підготовки виконавців. Певною мірою обмеженим ресурсом є і час, який відводиться на реалізацію проекту. Саме обмеженість ресурсів та часу, який є у розпорядженні для його виконання, примушують зацікавлену сторону вживати спеціальні заходи, щоб використати їх найкращим чином з метою досягнення поставленої перед проектом мети. От ці заходи і є суттю управління проектом. Керування проектом (Project Management) або менеджмент проекту – це керування роботами команди виконавців проекту для реалізації програмного продукту з використанням загальних методів менеджменту, планування й контролю робіт (включаючи стартові операції, моніторинг і звітність), керування ризиками і конфігурацією за ефективною організацією команди виконавців. З менеджментом проекту пов’язано поняття – масштаб проекту або «зміст і межі проекту». Іншими словами, масштаб проекту (Project Scope) – це сукупність мети проекту та запланованих витрат часу і засобів. Тобто це своєрідний тривимірний простір (мета–час–гроші), у якому живуть учасники та виконавці проекту та і сам проект. Менеджери проектів часто кажуть, що існує «трійне обмеження» – змісту проекту, терміну і вартості, яке необхідно враховувати під час узгодження різноманітних вимог до проекту. Якість виконання проекту залежить від рівноваги цих трьох чинників, за координацію й реалізацію яких відповідає менеджер проекту. За ідейну і функціональну сторони проекту відповідає головний фахівець (у програмному проекті – головний програміст). Проекти з високою якістю організації дають необхідний продукт, послугу чи результат, що відповідає змісту проекту, своєчасно і в межах бюджету. Взаємовідношення між цими чинниками є такими: якщо один із них зміниться, то з великою імовірністю буде змінено, як мінімум, ще один чинник. 10.1.2. Головні цілі менеджменту проекту План реалізації проекту в найпростішому випадку містить у собі список задач з зазначенням дати їхнього початку і закінчення. Керівник проекту повинен бути готовим до того, що на певному процесі між вхідним планом і реальним станом виникне деяка розбіжність. Тому однією з основних задач керування проектами є своєчасна корекція початкового плану, причому з найменшими накладними витратами. У процесі керування проектом розв’язуються такі задачі: – дотримання директивних строків завершення проекту; – раціональний розподіл матеріальних ресурсів та виконавців між задачами, а також між процесами проекту; – своєчасна корекція вихідного плану згідно з реальним станом речей. Ці три задачі тісно пов’язані між собою, і недостатня увага до однієї з них неминуче призведе до проблем за двома іншими. Наприклад, невдалий розподіл ресурсів неодмінно викличе відхилення від запланованих термінів виконання задач проекту, а невміння відкоригувати вхідний план може звести нанівець усю виконану роботу. Щоб проект виявився успішним, під час його реалізації застосовується спеціальна технологія з трьох процесів: 1. Формування плану його виконання. Розділ 10 284 2. Контроль (відстеження, спостереження, тренінг) за реалізацією плану та керуванням проектом. 3. Завершення проекту. Чим якісніше будуть реалізовані ці процеси, тим вище вірогідність успішного виконання проекту. В інституті керування проектами США накопичений досвід з створення різних технічних проектів систематизовано у вигляді ядра знань – РMBOK (Project Management Body of Knowledge, www.pmi.org/publication/download/2000welcome. У цьому ядрі малими проектами вважаються ті, що містять у собі 100 робіт і 15 виконавців, середніми – 500 робіт і 50 виконавців і великими – 1000 робіт і 100 виконавців. У ядрі РМВОК визначені основні задачі розробки проектів: – методи керування, планування і контролю робіт на проекті; – ефективна організація проектної групи (команди); – застосування інструментарію менеджера проекту (наприклад, системи Project Management фірми Microsoft та Microsoft Visual Studio Team System 2005). Ці задачі є загальними, вони притаманні усім проектам. 10.1.3. Процес менеджменту проекту Особливість програмного проекту випливає з його домінуючої компоненти, а саме ПС, яке відображає функціональність системи і вимоги до технічного забезпечення. Успішне виконання проекту ПС залежить від рівня застосування методів керування проектом і врахування таких особливостей програмного проекту: – не матеріальність створюваного продукту, його не можна побачити в процесі конструювання (як це має місце при будівництві будинку) і вплинути на його реалізацію більш оперативно; – стандарти ЖЦ не орієнтовані на потрібний вид програмного продукту, як це має місце в технічних дисциплінах (автомобільній, авіаційній тощо), вони потребують розроблення додаткової методики для адаптації до виду й типу проекту; – програмні продукти створюють протягом тривалого часу на комп'ютерній техніці, яка швидко старіє і постійно відновлюються її елементна бази і мови програмування. Процес проектування проекту вміщує як головні, складові процеси його розроблення, що в сукупності забезпечують шлях від усвідомлення потреб замовника до передачі йому готового продукту. На цьому шляху виконуються наступні роботи. Визначення вимог. Збирання та аналізвимог до ПС замовником і виконавцем, представлення їх у мовної нотації, яка є зрозумілою їм обом. Проектування. Перетворення вимог у послідовність проектних рішень щодо способів їхньої реалізації: формування загальної архітектури ПС та принципів її прив’язки до конкретного середовища функціонування; визначення детального складу її архітектурних компонентів. Реалізація. Перетворення проектних рішень щодо реалізовані компонентів системи з визначеним їх складом. Тестування. Перевірка кожного з модулів, компонентів, їхньої інтеграції; тестування окремо та в цілому, верифікація відповідності функцій системи вимогам Розділ 10 285 до неї, поставленим замовником, і визначення сертифікату продукту (валідація) для проекту. Експлуатація та супроводження готової ПС для проекту. У розробленні проекту є специфіка зо визначення вимог, в якій беруть участь розробники і замовник, який уявляє функції ПС в дуже загальному, а іноді абстрактному вигляді. Для ПС формулюються початкові вимоги з реалізації базових функцій, сервісів і застосувань, що в процесі функціонування уточнюються і доповнюються. Після виготовлення першої версії ПС запускається ядро системи і замовник може видавати різні пропозиції щодо її завершення і випробування. На основі випробування в систему додаються нові функції або виконуються необхідні зміни при виявленні помилок або неточного виконання деяких вимог. Взагалі кінцевий програмний код системи будується шляхом системної інтеграції готових програмних компонентів, включаючи системні та мережні компоненти (СКБД, ОС, протоколи тощо), та розроблених, що становить не більше 20% загального обсягу ПС проекту. Таким чином, використовується ітеративній підхід до їх відбору, випробування та прийняття рішень про готові компоненти різного типу. Вирішення цих задач проектування виконується за допомогою методів проектного менеджменту, які розглянемо нижче. 10.1.4. Модель процесу керування проектом Процес керування проектом є новим процесом ЖЦ стандарту ISO/IEC 12207– 2002, який був відсутній в стандарті ДСТУ 3918–99 і внесений також у нову версію ДСТУ ISO 15504 (частини 1–9) 2002 року. Згідно з цим стандартів «призначення процесу керування проектом – це ідентифікація, впровадження, координація та моніторинг дій, задач та ресурсів для вироблення продукту та/або послуг відповідно до вимог [7]. Цей процес містить у собі: – визначення обсягу робіт за проектом; – оцінювання можливості досягнення цілей проекту за наявних ресурсів та обмежень; – оцінювання об’ємів та вартості задач та ресурсів, необхідних для виконання проекту; – встановлення інтерфейсів між елементами проекту, а також з організаційними підрозділами; – розроблення та впровадження планів виконання проекту під наглядом відповідних виконавців; –перевірка показників проекту і при їхній невідповідності вживання заходів з коригування відхилень від плану та запобігання повторенню проблем. Як результат зазначених дій визначається структурований опис процесу керування проектом у вигляді профілю проекту, який наведено на рис. 10.1. Наведемо трактування складових цього загального процесу. Вимоги до професійної кваліфікації виконавців визначають необхідний рівень їх компетентності. При цьому стандарти робочих продуктів даного процесу визначають структуру і зміст вхідних і вихідних документів процесу розроблення. Метрики процесу – це сукупність методів і шкал для вимірювання розміру і складності об'єктів діяльності, а також вартості, трудомісткості і тривалості процесу. Розділ 10 286 Суб'єкти процесу Об'єкти процесу Архітектура процесу (операційні потоки) Ресурси та обмеження (умови середовища) Стандарти для робочих продуктів процесу Вимоги до професійної кваліфікації виконавців процесу Базове та адаптоване визначення процесу Вимоги, пов'язані с особливостями класу ПЗ (обмеження щодо безпеки, цілістності) План виконання процесу Метрики процесу Міжнародні, національні, галузеві стандарти (вимоги до виконання процесу) Методи та засоби виконання процесу Рис. 10.1. Профіль процесу керування проектом Міжнародні і вітчизняні стандарти, що стосуються планів процесу, а також методів і засобів виконання – профіль стандартів. Методи і засоби виконання процесу – це методична і інструментально- технологічна підтримка його виконання. Основним об’єктом процесу керування є програмний проект, для якого визначається його модель, що відображає елементи проекту, зв’язки та їхнє виконання у часі. Головним, центральним поняттям моделі є робота, яка пов’язана з розробленням програмного проекту. Визначення складу робіт, їхніх зв’язків, планів їх виконання (упорядкування у часі та умов виконання), розподілу ресурсів проекту та контролю виконання з урахуванням вимог та угод замовника – сутність керування проектом. Контроль, обмеження та керування динамікою здійснюється шляхом впровадження версій проекту замовника та керування кінцевою конфігурацією проекту після випробування версії проекту. При цьому знаходяться деякі порушення у вимогах та сутності функцій. Це є основою прогнозування змін в ПС проекту щодо його функцій і можливості додавання або скорочення робіт, правил і ресурсів, пов’язаних з різними змінами. Розділ 10 287 10.1.5. Інфраструктура програмного проекту Інфраструктура проекту в організації – це інтегрований набір загальнодоступних технічних, технологічних і методологічних ресурсів, використання яких робить можливим процес виконання проекту колективом, що створюються за договором з замовником. Складовими ресурсами цієї інфраструктури є такі [7]: – техніка та комунікації (комп’ютери, файли і сервери; локальні та глобальні мережі; електронна пошта (e-mail); техніка налагодження; офісна техніка тощо). – загальносистемне ПС та інструменти (клієнт/серверні технології; ОС; системи документообігу; утиліти; засоби захисту інформації, CASE-інструменти, системи програмування, графічні інструменти, СКБД тощо); – інформаційні ресурси та методології, що визначають процеси розроблення проекту з використанням інструментів керування проектами та засобів Internet (веб-ресурси, веб-семантика тощо); – стандарти програмної інженерії з ЖЦ, визначення інтерфейсів, між проектної взаємодії, якості, вимірювання тощо; – кадрові питання відображають усе, що пов’язано з підготовкою персоналу для виконання різнопланових робіт у проекті, а також з вивченням сучасних систем знань (ядро знань SWEBOK, PMBOK, засоби Інтернету тощо) для досягнення необхідного рівня реалізації проекту [8, 10]. Організаційне забезпечення в інфраструктурі проекту вміщує велику кількість груп персоналу, в обов’язки яких входять ведення, планування, контроль і оцінювання процесу ЖЦ розроблення ПС. До них відносять такі групи: – техніко-технологічної підтримки (вивчення ринку, придбання Case, ПС, консультації співробітникам, тощо); – захисту інформації (забезпечення засобами захисту і перевірки інформації в проекті); – технологічної служби (супроводження процесу проекту, нормативно- методична підтримка ЖЦ, побудова графіків робіт, контроль тощо); – якості (SQA-група), у функції якої входить планування та виконання дій ЖЦ, дотримання дисципліни створення проекту, перевірки робіт у контрольних точках проекту, контроль якості робочих продуктів і документів з ПС тощо; – верифікації і валідації, які проводять кваліфікаційне тестування компонентів ПС або продукту на правильність, – координування планів робіт з менеджером проекту з вимог до ПС, перевірку виконання вимог (валідація) та тестового середовища; – керівника проекту, яка відповідає за фінансові і технічні ресурси проекту, виконання проектних угод замовника та визначеного середовища для розроблення складових проекту; – менеджера проекту, відповідального за розроблення проекту на основі вимог, проектних рішень і планів робіт на проекті і їхньої реалізації; – проектувальників і програмістів, які відповідають за розроблення проектних рішень і їхню реалізацію у вигляді програм, документів і інших вихідних результатів; – керівника конфігурацією, який реєструє версії проекту, зберігає тверді копії й версії на магнітних носіях і розмежовує доступ до них. Розділ 10 288 Серед цих груп найголовнішим є менеджер проекту, він несе відповідальність перед виконавцями проекту і замовником за успішне розроблення проекту. У його функції входять: – розроблення моделі ЖЦ і погодження її з керівником проекту системи; – підключення до проекту фахівців розглянутих груп; – координація всіх груп програмного проекту між собою; – визначення стратегії дій в різних точках процесу ЖЦ з продовження роботи або її закінчення; – розроблення основних документів проекту і керування верифікацією функцій на процесах ЖЦ і валідацією продукту на відповідність вимог замовника. Відповідальний програміст працює в тісній взаємодії з проектувальником для погодження з ним постановок задач і прийняття основних проектних рішень з реалізації функцій проекту. Крім того, він розподіляє роботу між програмістами, контролює дотримання ними порядку розроблення з моделі ЖЦ і стандартів зовнішнього інтерфейс та оброблення помилок тощо. |