КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Каскадна модель1.2.2. Неминучі повернення на попередні стадії в каскадній моделі
1.1. Визначення проекту і проектування. Основні особливості і проблеми сучасних програмних проектів
Основою проектування програмного забезпечення (ПЗ) є системний підхід. Системний підхід - це методологія дослідження об'єкту будь-якої природи як системи. Система - це сукупність взаємозв'язаних частин, які працюють спільно для досягнення деякого результату. Визначальна ознака системи - поведінка системи в цілому не може бути зведене до сукупності поведінки частин системи. Програмне забезпечення - це система, яка включає: комп'ютерні програми; документацію; дані, необхідні для коректної роботи програм. Проектування ПЗ - це процес створення специфікацій ПЗ на основі початкових вимог до нього. Проект ПЗ - сукупність специфікацій ПЗ (які включають моделі і проектну документацію), які забезпечують створення ПЗ в конкретному програмно-технічному середовищі. ПЗ можна розбити на два класи: «мале» і «велике». «Мале» програмне забезпечення має наступні характеристики: Ø вирішує одну нескладну, чітко поставлену задачу; Ø розмір початкового коду не перевищує декількох сотень рядків; Ø швидкість роботи ПЗ і необхідні йому ресурси не грають великої ролі; Ø збитки від неправильної роботи не мають великого значення; Ø модернізація ПЗ, доповнення його можливостей потрібна рідко; Ø зазвичай, розробляється одним програмістом або невеликою групою (5 або менш людей); Ø докладна документація не потрібна, її може замінити початковий код, який доступний. «Велике» програмне забезпечення має 2-3 або більше характеристик з наступного переліку: Ø вирішує сукупність взаємозв'язаних завдань; Ø використання приносить суттєву вигоду; Ø зручність його використання грає важливу роль; Ø обов'язкова наявність повної і зрозумілої документації; Ø низька швидкість роботи приводить до втрат; Ø збої, неправильна робота, завдає відчутного збитку; Ø програми в складі ПЗ під час роботи взаємодіє з іншими програмами і програмно-апаратними комплексами; Ø працює на різних платформах; Ø потрібний розвиток, виправлення помилок, додавання нових можливостей; Ø група розробників складається більше ніж з 5 чоловік. Далі розглядається проектування «великого» ПО, оскільки створення «малого» не викликає великих труднощів, не вимагає спеціальної технології і інструментів. Класифікація програмних проектів за розміром групи розробників і тривалістю проекту: Ø невеликі проекти - проектна команда менше 10 чоловік, термін від 3 до 6 місяців; Ø середні проекти - проектна команда від 20 до 30 чоловік, тривалість розробки проекту 1-2 року; Ø великомасштабні проекти - проектна команда від 100 до 300 чоловік, тривалість розробки проекту 3-5 років; Ø гігантські проекти - армія розробників від 1000 до 2000 чоловік і більш (включаючи консультантів і співвиконавців), тривалість розробки проекту від 7 до 10 років. З кінця 60-х років минулого століття до сьогоднішніх днів триває так звана «криза ПЗ». Виражається вона в тому, що великі проекти виконуються з перевищенням кошторису витрат і/або термінів відведених на розробку, а розроблене ПЗ не володіє необхідними функціональними можливостями, має низьку продуктивність і якість. За наслідками досліджень американської індустрії розробки ПЗ, виконаних в 1995 році Standish Group (www.standishgroup.com), тільки 16% проектів завершилися в строк, не перевищили запланований бюджет і реалізували всі необхідні функції і можливості. 53% проектів завершилися із запізненням, витрати перевищили запланований бюджет, необхідні функції не були реалізовані в повному об'ємі. 31% проектів були анульовані до завершення.
Для двох останніх категорій проектів бюджет середнього проекту виявився перевищеним на 89%, а термін виконання - на 122%. Останніми роками процентне співвідношення трьох перерахованих категорій проектів трохи змінюється в кращу сторону.
Причини невдач: Ø нечітке і неповне формулювання вимог; Ø недостатнє залучення користувачів до роботи над проектом; Ø відсутність необхідних ресурсів; Ø незадовільне планування і відсутність грамотного управління проектом; Ø часта зміна вимог і специфікацій; Ø новизна і недосконалість використовуваної технології; Ø недостатня підтримка з боку вищого керівництва; Ø недостатньо висока кваліфікація розробників, відсутність необхідного досвіду. При плануванні проектів часто з тих або інших причин встановлюються нездійсненні терміни, закладаються недостатні ресурси. Таким чином, виникають безнадійні проекти (death march projects). Ознаки безнадійного проекту: Ø план проекту стислий більш ніж наполовину у порівнянні з нормальним розрахунковим планом; Ø кількість розробників зменшена більш ніж наполовину у порівнянні з дійсно потрібним для проекту заданого розміру і масштабу; Ø бюджет і пов'язані з ним ресурси урізані наполовину; Ø вимоги до функцій, продуктивності та інших характеристик удвічі перевищують значення, які вони могли б мати в нормальних умовах. Іншою причиною невірного планування є помилка щодо продуктивності проектувальників. У великому проекті загальна продуктивність групи розробників не дорівнює сумі продуктивностей окремих членів групи (порахованої начебто вони працювали поодинці). Згідно Бруксу у книзі «Мифический человеко-месяц» Ø найчастіша причина провалу - брак часу; Ø іноді роботи не можна прискорити, не зіпсувавши результат; Ø людино-місяць - небезпечна помилка, оскільки передбачається, що кількість людей і місяці можна поміняти місцями; Ø розділення завдання між декількома людьми викликає накладні витрати; Ø якщо проект не укладається в строк, то додавання людей затримає його ще більше; Ø «срібної кулі» немає! Останнє положення стосується технології розробки. Брукс стверджує, що технології, яка дозволяє на порядок підвищити продуктивність розробників, не існує. Тобто, не можна вважати, що яка-небудь новітня технологія розробки дозволить здійснити проект в 10 разів швидше. Особливості сучасних проектів ПЗ: Ø складність - невід'ємна характеристика створюваного ПО; Ø відсутність повних аналогів і висока частка ПЗ, яке розробляється з нуля; Ø наявність успадкованого ПЗ і необхідність його інтеграції з розроблюваним ПЗ; Ø територіально розподілене і неоднорідне середовище функціонування; Ø велика кількість учасників проектування, роз'єднаність і різнорідність окремих груп розробників за рівнем кваліфікації і досвіду. Розробка ПЗ має наступні специфічні особливості: Ø неформальний характер вимог до ПЗ і формалізований основний об'єкт розробки - програми; Ø творчий характер розробки; Ø дуалізм ПЗ, яке, з одного боку, є статичним об'єктом - сукупністю текстів, з іншого боку, - динамічним, оскільки при експлуатації породжуються процеси обробки даних; Ø при своєму використанні (експлуатації) ПЗ не витрачається і не зношується; Ø «невідчутність», «легкість» ПЗ, що підштовхує до безвідповідального перероблення, оскільки легко стерти і переписати, чого не зробиш при проектуванні будівель і апаратури. Шляхом виходу з кризи ПЗ стало створення програмної інженерії (software engineering). Інженерія ПЗ (software engineering) - сукупність інженерних методів і засобів створення ПЗ. Фундаментальна ідея програмної інженерії: проектування ПЗ є формальним процесом, який можна вивчати і удосконалювати. Освоєння і правильне застосування методів і засобів програмної інженерії дозволяє підвищити якість, забезпечити керованість процесу проектування. Етапи становлення і розвитку SE: Ø 70-і і 80-і роки - систематизація і стандартизація процесів створення ПЗ (структурний підхід); Ø 90-і роки - початок переходу до складального, індустріального способу створення ПЗ (об'єктно-орієнтований підхід). Програмна інженерія застосовується для задоволення вимог замовника ПЗ. Основні цілі програмної інженерії: 1. Системи повинні створюватися в короткі терміни і відповідати вимогам замовника на момент впровадження. 2. Якість ПЗ повинно бути високою. 3. Розробка ПЗ повинна бути здійснена в рамках виділеного бюджету. 4. Системи повинні працювати на устаткуванні замовника, а також взаємодіяти з наявним ПЗ. 5. Системи повинні бути легко супроводжуваними і масштабованими.
1.2. Життєвий цикл програмного забезпечення. Стандарти, які регламентують життєвий цикл
Основним поняттям програмної інженерії є поняття життєвого циклу ПЗ. Життєвий цикл ПЗ (software lifecycle) - це період часу, який починається з моменту ухвалення рішення про необхідність створення ПЗ і закінчується у момент його повного вилучення з експлуатації.
Основний нормативний документ, який регламентує ЖЦ ПЗ - стандарт ISO/IEC 12207: 1995 “Information Technology - Software Life Cycle Processes”. У рамках технологій створення ПЗ поняття ЖЦ уточнюється, але вказані стандарти не порушуються. З погляду статичної структури ЖЦ є сукупністю процесів ЖЦ. Процес ЖЦ - набір взаємозв'язаних дій, які перетворюють деякі вхідні дані і ресурси у вихідні. Кожен процес характеризується завданнями, методами їх рішення, дійовими особами, результатами. Процеси ЖЦ протікають паралельно. Кожен процес розділений на набір дій, кожна дія - на набір завдань. Кожен процес, дія або завдання ініціюється і виконується у потрібний час, причому не існує заздалегідь певних послідовностей виконання, серед яких наступні: Ø основні (придбання, постачання, розробка, експлуатація, супровід); Ø допоміжні (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, сумісна оцінка, аудит, розв’язання проблем); Ø організаційні (управління, створення інфраструктури, удосконалення, навчання). Для ознайомлення приведемо зміст процесів ЖЦ. Процес придбання включає наступні дії: ініціація придбання; підготовку заявочних пропозицій; підготовку і коректування договору; нагляд за діяльністю постачальника; приймання і завершення робіт. Дійові особи: замовник, постачальник. Завдання придбання: визначення замовником своїх потреб у ПЗ; аналіз вимог до ПЗ; ухвалення рішення про придбання ПЗ; вироблення плану придбання і заявочних пропозицій; вибір постачальника; підготовка і укладення договору з постачальником; контроль за дотриманням умов договору; коректування договору при необхідності. Процес постачання включає наступні дії: ініціація постачання; підготовку відповіді на заявочні пропозиції; підготовку договору; планування і виконання постачання; контроль постачання; перевірку і оцінку. Дійові особи: замовник, постачальник. Завдання постачання: оцінка постачальником заявочних пропозицій; підготовки і укладення договору із замовником, контроль з боку постачальника за дотриманням умов договору, ухвалення рішення про залучення субпідрядника або виконанні робіт своїми силами, вироблення плану управління проектом і ін. Процес розробки включає наступні дії: підготовчу роботу; аналіз вимог до ПЗ; проектування архітектури ПЗ; детальне проектування ПЗ; кодування ПЗ; тестування ПЗ; інтеграцію ПЗ; встановлення ПЗ; приймання ПЗ. Дійові особи: розробник, замовник. Завдання розробки: вибір моделі ЖЦ ПЗ і узгодження із замовником; визначення вимог до ПЗ (функціональних і нефункціональних); визначення складу компонентів ПЗ і створення документації по кожному компоненту; моделювання і специфікація компонент ПЗ; планування інтеграції компонент; створення початкових текстів компонент; пошук і виправлення помилок у початкових текстах і документації; збирання ПЗ; розгортання ПЗ; оцінка результатів. Процес експлуатації включає наступні дії: підготовчу роботу; експлуатаційне тестування; експлуатацію; підтримку користувачів. Дійові особи: оператор (організація, яка експлуатує ПЗ), користувачі. Завдання експлуатації: вироблення плану експлуатації і експлуатаційних стандартів; складання процедур локалізації і розв’язання проблем експлуатації; пошук помилок у ПЗ перед введенням в експлуатацію його нових версій; надання допомоги користувачам і консультування. Процес супроводу включає наступні дії: підготовчу роботу; аналіз проблем і запитів на модифікацію ПЗ; перевірку і приймання; перенесення ПЗ в інше середовище; зняття ПЗ з експлуатації. Дійові особи: служба супроводу, користувачі. Завдання супроводу: вироблення плану супроводу; складання процедур локалізації і розв’язання проблем супроводу; оцінка доцільності внесення модифікацій в ПЗ; ухвалення рішення про модифікацію; пошук помилок в ПЗ після його модифікації; перевірка цілісності ПЗ; архівація при знятті з експлуатації; навчання користувачів. Процес документування включає наступні дії: підготовчу роботу; проектування і розробку документації; випуск документації; супровід. Процес управління конфігурацією включає в себе наступні дії: підготовчу роботу; створення бази знань про ПЗ (конфігурації); контроль за конфігурацією; облік стану конфігурації; оцінку конфігурації; управління випуском і постачання ПЗ. Конфігурація ПЗ - це сукупність відомостей про його функціональні і фізичні характеристики на всіх стадіях ЖЦ ПЗ. Основне завдання управління конфігурацією: організація, систематичний облік і контроль внесення змін в ПЗ. Процес забезпечення якості включає наступні дії: підготовчу роботу; забезпечення якості продукту; забезпечення якості процесу; забезпечення інших показників якості ПЗ. Завдання забезпечення якості: гарантована відповідність ПЗ вимогам замовника, зафіксованих в договорі; гарантовану відповідність процесів ЖЦ ПЗ, методів розробки, кваліфікації персоналу встановленим стандартам. Процес верифікації включає наступні дії: підготовчу роботу; верифікацію. Основне завдання верифікації - перевірка відповідності розроблених програм у складі ПЗ їх специфікаціям. Процес атестації полягає у визначенні повноти відповідності розробленого ПЗ вимогам замовника. Основне завдання атестації - оцінка достовірності тестування ПЗ. Зазвичай, для атестації залучають незалежних експертів. Процес сумісної оцінки включає наступні дії: підготовчу роботу; оцінку управління проектом; технічну оцінку. Основне завдання сумісної оцінки - контроль планування і управління ресурсами, персоналом, інфраструктурою проекту. Процес аудиту полягає у визначенні повноти відповідності проекту умовам договору. Процес розв’язування проблем передбачає аналіз і розв’язування проблем, які виникають протягом ЖЦ ПЗ. Процес управління включає наступні дії: підготовчу роботу; планування; виконання і контроль; перевірку і оцінку; завершення. Завдання управління: перевірка достатності наявних ресурсів; складання графіків робіт; оцінка витрат; виділення ресурсів; розподіл відповідальності; оцінка ризиків. Процес створення інфраструктури полягає у виборі і підтримці технології розробки ПЗ, стандартів і інструментальних засобів; виборі і встановленні апаратних і програмних засобів, необхідних для розробки, експлуатації і супроводу ПЗ. Процес удосконалення передбачає оцінку, вимірювання, контроль і удосконалення процесів ЖЦ ПЗ. Основне завдання удосконалення - підвищення продуктивності праці. Процес навчання включає наступні дії: підготовчу роботу; розробку учбових планів, курсів, матеріалів; реалізацію планів навчання. Завдання навчання: первинне навчання персоналу; підвищення кваліфікації персоналу. Процеси ЖЦ ПЗ взаємозв'язані. Динаміку, тобто розвиток ЖЦ у часі визначає модель життєвого циклу. Модель ЖЦ ПЗ - це структура, яка визначає послідовність виконання і взаємозв'язку процесів, дій і завдань впродовж всього ЖЦ. У будь-якій моделі ЖЦ розглядається як сукупність стадій ЖЦ. Стадія ЖЦ - це частина ЖЦ обмежена часовими рамками, після закінчення якої досягається певний важливий результат у відповідності до вимог для даної стадії ЖЦ. Моделі ЖЦ: Ø каскадна (водоспад); Ø еволюційна; Ø заснована на формальних перетвореннях; Ø ітераційні (покрокова і спіральна).
Дата добавления: 2014-01-07; Просмотров: 874; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |