Проблеми розробки ПЗ

Проблеми

При розробці ПО часто зриваються графіки робіт і спостерігається перевищення встановленого бюджету. Часто поставлений програмний продукт не відповідає вимогам споживача і його ніколи не використовують. Програмні продукти часто просто погано працюють. Як видно із симптомів нездужання ПЗ, за його розробці виникає п'ять принципових питань:

Недолік прозорості;

Недолік контролю;

Недолік трасування;

Недолік моніторингу;

Неконтрольовані зміни.        

Питання         

Відповідь             

Брак прозорості         

ПО за своєю природою є концептуальним. На відміну від   моста, будівлі або будь-якого іншого фізичного об'єкта, складно подивитися на   програмний продукт і оцінити ступінь його завершеності. Без жорсткого   керівництва проектом розробка ПЗ буде завершена на 90% при використанні   90% відведеного часу. Політика управління конфігураціями (КК) та Управління   Змінами (УІ) та визначення моделі менеджменту конфігурації ПО при розробці   продукту, всі елементи конфігурації, компоненти і подкомпоненти миттєво   стають видимими для версій, релізів і сімейств продуктів.             

Недолік контролю         

Оскільки програмне забезпечення є нематеріальним   у фізичному сенсі, його складніше контролювати. Без точної оцінки   процесу розробки зриваються графіки виконання робіт і перевищуються   встановлені бюджети. Дуже складно оцінити обсяг виконаної і залишилася   роботи. Процес КК і УІ надає механізм управління процесом через визначення   фактично витрачених і планових ресурсів та оцінювання майбутніх витрат,   виходячи з обсягу виконаної роботи.             

Недолік трасування         

Відсутність зв'язку між окремими подіями проекту   призводить до його провалу. Головна перевага КК і УІ полягає в тому, що з його   допомогою забезпечується трасування серед версій, релізів і сімейств   продуктів. Цінність подібної трасування величезна в ситуаціях, коли в одному   з випусків або сімействі продукту виникає проблема, яка надає   вплив на інші клієнтські релізи та продукти. Виконання однієї зміни і   його поширення на всю базу ПО заощаджує багато часу, засобів і поліпшує   взаємини з клієнтами. Відсутність зв'язку між подіями проекту   призводить до його провалу, коли рішення однієї проблеми збільшують проблему в   іншої області або призводить до невдачі в спробі вирішити аналогічну проблему   де то в іншому місці. Наскрізна трасування виконуваних завдань дозволяє   менеджменту в межах аудиторської можливості КК і УІ перевірити ланцюжок   подій, через які виникли складності у проекті як інтегральному   процесі. А відстеження календарного графіка виконання робіт дозволяє, не   затягуючи проект, завершать розробку ПЗ у встановлені терміни.             

Недолік моніторингу         

Без трасування і «прозорості» складно здійснити   моніторинг програмних проектів. Керівництво не може прийняти компетентні   рішення, тому графіки продовжують зриватися, а витрати продовжують перевищувати   встановлений бюджет. Неможливо виконати моніторинг проекту, якщо у   менеджера проекту немає інструментальних засобів, щоб стежити за фактичної   розробкою продукту в межах проекту. У ході здійснення процесу КК і   УІ реалізується забезпечення інструментальними засобами, які дозволяють   здійснити різносторонній моніторинг процесу. За наявності КК і УІ,   трасування і «прозорості» моніторинг програмних проектів стає   простий частиною загальної задачі управління проектом. За допомогою моніторингу,   доступного завдяки інструментальним засобам КК і УІ і можливостям CCB *,   менеджери проектів приймають виважені рішення, не вибився з графіка   робіт і не перевищуючи бюджет.             

Неконтрольовані зміни         

ПЗ є достатньо гнучким, воно представляє результат   роботи великого колективу, але у споживачів постійно виникають нові ідеї   стосовно даного програмного продукту. Люди рідко просять конструктора   моста внести зміни в середині проекту, тоді як користувачі ПЗ часто   звертаються з такими проханнями. Вплив таких змін може бути просто   величезне. Всі інструментальні засоби SCM підтримують механізм для   управління відповідними змінами.             

Груповий синдром розробника         

Якщо для розробки проекту потрібно більше одного   розробника, то виникає проблема групи людей, що працюють над однією базою   продукту. У даному випадку базою може бути план проведення випробувань,   вимоги до специфікації або коду. Зусилля витрачаються даремно, кілька   осіб працюють над одним і тим же файлом, а потім його зберігають. Без   контролю КК І УІ зберігаються тільки зміни, записані останнім, хто   працює над цим файлом; всі інші зміни - втрачаються. Найпростіше   вирішення проблеми лежить у блокуванні файлу на час роботи з ним одним із   співробітників, щоб запобігти одночасну роботу над ним не скількох   чоловік.             

Множинність версій         

Удосконалення базового продукту призводить до випуску   додаткових версій із самими останніми змінами. Незважаючи на наявність   останньої модернізованої версії програмного продукту, частина користувачів   продовжує працювати з більш ранньою версією. Продукт КК І УІ дозволяє   контролювати всі версії. Якщо в програмі знайдені помилки, то зміни   необхідно зробити у всіх версіях. Як тільки у продукті з'являються нові   властивості, вони повинні бути доступні для всіх користувачів незалежно від   часу випуску версії продукту.             

Сімейство програмних продуктів         

Оскільки програмні продукти створені для того, щоб   пропонувати аналогічні функції за допомогою неоднорідних платформ апаратного   забезпечення, необхідно управляти як програмним продуктом взагалі, так і ПО   на базі певної апаратної платформи. Якщо програмний продукт працює   з чотирма версіями Windows, трьома версіями Unix, Red Hat Linux і FreeBSD, то   керівництво для користувача повинно бути аналогічним. Але для цих дев'яти   платформ необхідні різні процеси встановлення ПЗ. Без застосування про написати   дев'ять окремих посібника для користувача з даного програмного продукту.   За наявності КК І УІ достатньо буде одного комплекту документації, куди   будуть входити всі дев'ять версій, які будуть відрізнятися лише процедурою   інсталяції програмного продукту.             

Зміна вимог         

Перший закон системотехніки полягає в тому, що   незалежно від етапу життєвого циклу системи, система/ПЗ буде змінюватися, а   бажання змінити її буде постійно виникати на всьому протязі життєвого   циклу продукту. Боротьба з такими змінами являє собою складну   управлінську проблему. Наявність КК І УІ полегшує управління такими   змінами вимог до продукту. КК І УІ дозволяє легко ідентифікувати набори   функціональних можливостей, які об'єднують вимоги, яким відповідає   версія продукту. Цей набір функціональних можливостей відстежується від   розробки до поставки продукту.             

Зміна графіка робіт         

Оскільки технічні вимоги змінюються, повинен   змінюватися і графік їх виконання. Складання календарного плану з урахуванням   набору функціональних можливостей для версії дозволяє менеджерам проектів   більш точно розподіляти сили, необхідні для випуску наступної версії   програмного продукту. Наявність КК І УІ дає можливість на основі   статистичних даних порівнювати ефективність роботи при підготовці нових   версій. Статистичні дані допомагають оцінити розвиток подій типу а що,   якщо, які відбуваються в результаті успішного впровадження програмного   продукту серед нових споживачів або надання виконаних на замовлення   продуктів іншим клієнтам.             

Зміни ПЗ         

Жоден розробник не дозволяє собі, один раз написав   програму, повністю про неї забути. Розробляється за змінюється не тільки при   зміну технічних вимог і календарних планів, але і у відповідь на   зміни в інших елементах. Програмне забезпечення не є догмою. У цьому й полягає його   цінність. Програмний продукт можна змінювати, тому його і змінюють. Системи   КК І УІ відстежують ці зміни, а якщо внесено невірне зміна, то   завжди можна подивитися попередню робочу версію. Тільки одна ця функція КК   І УІ економить величезну кількість часу, оскільки розробники перевіряють   конкретні завдання, які не працюють в середовищі програмного продукту, і можуть   швидко перейти до робочої версії.             

Зміни штату         

У всіх організаціях співробітники просуваються службовими   сходах, переходять на іншу роботу або звільняються. Якщо це відбувається в   розпал роботи з розробки ПЗ, то з відходом фахівця втрачаються не тільки   технологічні знання. Втрачаються й практичний досвід з розробки   продуктів, на оволодіння якими пішло багато часу. Нові співробітники, навіть   знаючи технологію, не зможуть займатися розробкою продукту без   задокументованого процесу КК І УІ. Таким чином, КК І УІ є точкою   відліку і базою даних про історію розробки проекту. Завдяки КК І УІ новий   співробітник може дізнатися, як йде процес розробки в організації і що   нового в проекті на конкретну дату.             

Зміни документації система/користувач         

Жоден розробник не має права щось пропустити в   технології або інструментальному засобі. Усі розробники продукту   використовують систему мікропрограм апаратних засобів, операційні системи,   інструментальні засоби та документацію, які не знаходяться під їхнім   контролем. При зміні основної операційної системи (наприклад, наступної   найкращою версії Windows) КК І УІ відстежує всі елементи конфігурації,   компоненти і подкомпоненти, на які може вплинути це зміна.   Кожна зміна аналізують окремо, що дозволяє правильно розподілити   сили, необхідні для реагування на цю зміну. Можна скласти   календарний план реагування на ситуацію, яка виходить за рамки контролю   цієї організації.     

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.cmcons.com/