Причини проблем створення пз

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

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

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

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

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

5. Недосконалість користувальницького інтерфейсу. Однією з проблем впровадження нового ПЗ є консервативність користувачів які найчастіше просто не можуть знайти в програмі потрібну їм функцію (Операцію). Незважаючи на те що існують стандарти користувальницького інтерфейсу, концепція інтуїтивно зрозумілого інтерфейсу це не полностью__решает дану проблему. Від частини тут може допомогти найдокладнішим чином складена інструкція користувача та служба підтримки.

Визначення ЖЦПО по Леману

Введення У самому загальному випадку можна вважати, що життєвий цикл програмної системи складається з трьох фаз: визначення; реалізації; обслуговування.

Визначення системи

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