Головна

Якість програмного забезпечення, його характеристики і атрибути.

  1. Mетрологічні характеристики електровімірювальніх приладів
  2. VI. КОРОТКИЙ ВИКЛАД ПРОГРАМНОГО МАТЕРІАЛУ НАВЧАЛЬНИХ МОДУЛІВ
  3. Антисоціальні характеристики особистості.
  4. Атмосферні фронти і їх характеристики.
  5. Аеродинамічні характеристики літака
  6. Без службової характеристики, завіреної печаткою, який навчається на зарахування не допускається.

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

Якщо попросити групу людей висловити свою думку з приводу того, що таке якісне ПЗ, можна отримати наступні варіанти відповідей:

Його легко використовувати.

Воно демонструє хорошу продуктивність.

У ньому немає помилок.

Воно не псує призначені для користувача дані при збоях.

Його можна використовувати на різних платформах.

Воно може працювати 24 години на добу і 7 днів на тиждень.

У нього легко додавати нові можливості.

Воно задовольняє потреби користувачів.

Воно добре документовано.

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

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

Якість програмного забезпечення визначається в стандарті ISO 9126 [1] як вся сукупність його характеристик, що відносяться до можливості задовольняти висловлені або побічні потреби всіх зацікавлених осіб.

розрізняються поняття внутрішнього якості, Пов'язаного з характеристиками ПО самого по собі, без урахування його поведінки; зовнішнього якості, Що характеризує ПЗ з точки зору його поведінки; і якості ПО при використанні в різних контекстах - тієї якості, яке відчувається користувачами при конкретних сценаріях роботи ПЗ. Для всіх цих аспектів якості введені метрики, що дозволяють оцінити їх. Крім того, для створення добротного ПЗ істотно якість технологічних процесів його розробки. Взаємини між цими аспектами якості за схемою, прийнятої ISO 9126, показано на рис. 5.1.


Мал. 5.1.Основні аспекти якості ПЗ по ISO 9126

Стандарт ISO 9126 [1,2,3,4] пропонує використовувати для опису внутрішнього і зовнішнього якості ПЗ багаторівневу модель. На верхньому рівні виділено 6 основних характеристик якості ПЗ. Кожна характеристика описується за допомогою декількох входять до неї атрибутів. Для кожного атрибута визначається набір метрик, що дозволяють його оцінити. Безліч характеристик і атрибутів якості згідно ISO 9126 показано на рис. 5.2.


Мал. 5.2.Характеристики та атрибути якості ПЗ по ISO 9126

Нижче наведені визначення цих характеристик і атрибутів за стандартом ISO 9126: 2001:

Функціональність (functionality) - Здатність ПЗ в певних умовах вирішувати завдання, потрібні користувачам. Визначає, що саме робить ПЗ, які завдання воно вирішує.

o Функціональна придатність (suitability). - Здатність вирішувати потрібний набір завдань.

o Точність (accuracy). - Здатність видавати потрібні результати.

o Здатність до взаємодії (interoperability). - Здатність взаємодіяти з потрібним набором інших систем.

o Відповідність стандартам і правилам (compliance). - Відповідність ПО наявними індустріальним стандартам, нормативним і законодавчим актам, іншим регулюючим нормам.

o Захищеність (security). - Здатність запобігати неавторизований, тобто без зазначення особи, що намагається його здійснити, і недозволений доступ до даних і програм.

Надійність (reliability) .- Здатність ПЗ підтримувати певну працездатність в заданих умовах.

o Зрілість, завершеність (maturity). - Величина, зворотна частоті відмов ПЗ. Зазвичай вимірюється середнім часом роботи без збоїв і величиною, зворотної ймовірності виникнення відмови за даний період часу.

o Стійкість до відмов (fault tolerance). - Здатність підтримувати заданий рівень працездатності при відмовах і порушеннях правил взаємодії з оточенням.

o Здатність до відновлення (recoverability). - Здатність відновлювати певний рівень працездатності і цілісність даних після відмови, необхідні для цього час і ресурси.

o відповідність стандартам надійності (Reliability compliance). - Цей атрибут доданий в 2001 році.

Зручність використання (usability) або практичність. - Здатність ПЗ бути зручним в навчанні і використанні, а також привабливим для користувачів.

o Зрозумілість (understandability). - Показник, зворотний до зусиль, які витрачаються користувачами на сприйняття основних понять ПО і усвідомлення їх застосовності для вирішення своїх завдань.

o Зручність навчання (learnability). - Показник, зворотний зусиллям, що витрачається користувачами на навчання роботі з ПЗ.

o Зручність роботи (operability). - Показник, зворотний зусиллям, яких вживає користувачами для вирішення своїх завдань за допомогою програмного забезпечення.

o Привабливість (attractiveness). - Здатність ПЗ бути привабливим для користувачів. Цей атрибут доданий в 2001 році.

o відповідність стандартам зручності використання (Usability compliance). - Цей атрибут доданий в 2001 році.

Продуктивність (efficiency) або ефективність. - Здатність ПЗ при заданих умовах забезпечувати необхідну працездатність стосовно виділеним для цього ресурсів. Можна визначити її і як відношення одержуваних за допомогою ПЗ результатів до витрачених на це ресурсів усіх типів.

o Тимчасова ефективність (time behaviour). - Здатність ПЗ видавати очікувані результати, а також забезпечувати передачу необхідного обсягу даних за відведений час.

o Ефективність використання ресурсів (resource utilisation). - Здатність вирішувати потрібні завдання з використанням певних обсягів ресурсів певних видів. Маються на увазі такі ресурси, як оперативна і довгострокова пам'ять, мережеві з'єднання, пристрої введення і виведення тощо.

o відповідність стандартам продуктивності (Efficiency compliance). - Цей атрибут доданий в 2001 році.

Зручність супроводу (maintainability). - Зручність проведення всіх видів діяльності, пов'язаних з супровід програм.

o Аналізований (analyzability) або зручність проведення аналізу. - Зручність проведення аналізу помилок, дефектів і недоліків, а також зручність аналізу необхідності змін і їх можливих наслідків.

o Зручність внесення змін (changeability). - Показник, зворотний трудовитрат на виконання необхідних змін.

o Стабільність (stability). - Показник, зворотний ризику виникнення несподіваних ефектів при внесенні необхідних змін.

o Зручність перевірки (testability). - Показник, зворотний трудовитрат на проведення тестування та інших видів перевірки того, що внесені зміни привели до потрібних результатів.

o відповідність стандартам зручності супроводу (Maintainability compliance). - Цей атрибут доданий в 2001 році.

Переносимість (portability). - Здатність ПЗ зберігати працездатність при перенесенні з одного оточення в інше, включаючи організаційні, апаратні і програмні аспекти оточення.

Іноді ця характеристика називається в російськомовній літературі мобільністю. Однак термін "мобільність" варто зарезервувати для перекладу "mobility" - здатності ПО та комп'ютерної системи в цілому зберігати працездатність при її фізичному переміщенні в просторі.

o Адаптованість (adaptability). - Здатність ПЗ пристосовуватися різним оточенням без проведення для цього дій, крім заздалегідь передбачених.

o Зручність установки (installability). - Здатність ПЗ бути встановленим або розгорнутим в певному оточенні.

o Здатність до співіснування (coexistence). - Здатність ПЗ співіснувати з іншими програмами в загальному оточенні, ділячи з ними ресурси.

o Зручність заміни (replaceability) іншого ПО даними. - Можливість застосування даного ПЗ замість інших програмних систем для вирішення тих же завдань в певному оточенні.

o відповідність стандартам переносимості (Portability compliance). - Цей атрибут доданий в 2001 році.

Перераховані атрибути належать до внутрішнього і зовнішнього якості ПЗ згідно ISO 9126. Для опису якості ПО при використанні стандарт ISO 9126-4 [4] пропонує інший, більш вузький набір характеристик.

- Ефективність (effectiveness). - Здатність ПЗ надавати користувачам можливість вирішувати їх завдання з необхідною точністю при використанні в заданому контексті.

- Продуктивність (productivity). - Здатність ПЗ надавати користувачам певні результати в рамках очікуваних витрат ресурсів.

- Безпека (safety). - Здатність ПЗ забезпечувати необхідно низький рівень ризику нанесення шкоди життю і здоров'ю людей, бізнесу, власності або навколишньому середовищу.

- Задоволення користувачів (satisfaction). - Здатність ПЗ приносити задоволення користувачам при використанні в заданому контексті.

Крім перерахованих характеристик і атрибутів якості, стандарт ISO 9126: 2001 визначає набори метрик для оцінки кожного атрибута. Наведемо такі приклади таких метрик.

- Повнота реалізації функцій - Відсоток реалізованих функцій по відношенню до перерахованих у вимогах. Використовується для вимірювання функціональної придатності.

- Коректність реалізації функцій - Правильність їх реалізації по відношенню до вимог. Використовується для вимірювання функціональної придатності.

- Ставлення числа виявлених дефектів до прогнозованого. Використовується для визначення зрілості.

- Ставлення числа проведених тестів до загального їх числа. Використовується для визначення зрілості.

- Ставлення числа доступних проектних документів до зазначеного в їхньому списку. Використовується для вимірювання зручності проведення аналізу.

- Наочність і повнота документації. Використовується для оцінки зрозумілості.

Перераховані характеристики і атрибути якості ПЗ дозволяють систематично описувати вимоги до нього, визначаючи, які властивості ПЗ за даною характеристикою хочуть бачити зацікавлені сторони. Таким чином, вимоги повинні визначати наступне.

- Що ПО має робити, наприклад:

o дозволяти клієнту оформити замовлення і забезпечити їх доставку;

o забезпечувати контроль якості будівництва і відслідковувати проблемні місця;

o підтримувати необхідні параметри автоматизованого процесу виробництва, запобігаючи аварії і оптимальним чином використовуючи наявні ресурси.

- Наскільки воно повинно бути надійно, наприклад:

o працювати 7 днів на тиждень і 24 години на добу;

o допускається непрацездатність протягом не більше 3 годин на рік;

o ніякі введені користувачами дані при відмові не повинні губитися.

- Наскільки їм повинно бути зручно користуватися, наприклад:

o покупець повинен, знаючи назву товару і маючи середні навички роботи в Інтернет, знаходити потрібний йому товар за не більше ніж 2 хвилини;

o інженер за фахом "будівництво мостів" повинен протягом одного дня вміти розібратися в 80% функцій системи.

- Наскільки воно повинно бути ефективно, наприклад:

o підтримувати обслуговування до 10000 запитів в секунду;

o час відгуку на запит при максимальному завантаженні не повинна перевищувати 3 с;

o час реакції на зміну параметрів процесу виробництва не повинно перевищувати 0.1 с;

o на обробку одного запиту не повинно витрачатися більше 1 MB оперативної пам'яті.

- Наскільки зручно повинно бути його супровід, наприклад:

o додавання в систему нового виду запитів не повинно вимагати більше 3 людино-днів;

o додавання підтримки нового етапу процесу виробництва не повинно коштувати більше $ 20000.

- Наскільки воно повинно бути переносимо, наприклад:

o ПО повинно працювати на операційних системах Linux, Windows XP і MacOS X;

o ПО повинно працювати з документами в форматах MS Word 97 і HTML;

o ПО повинно зберігати файли звітів в форматах MS Word 2000, MS Excel 2000, HTML, RTF і у вигляді звичайного тексту;

o ПО повинне сполучатися з існуючою системою запису даних про замовлення.

Наведені атрибути якості закріплені в стандартах, але це не означає, що вони цілком вичерпують поняття якості ПЗ. Так, в стандарті ISO 9126 відсутні характеристики, пов'язані з мобільністю ПО (mobility), Тобто здатністю програми працювати при фізичних переміщеннях машини, на якій вона працює. Замість надійності багато дослідників вважають за краще розглядати більш загальне поняття добротності (dependability), Що описує здатність ПО підтримувати певні показники якості за основними характеристиками (функціональності, продуктивності, зручності використання) із заданими ймовірностями виходу за їх рамки і певним максимальним збитком від можливих порушень. Крім того, активно досліджуються поняття зручності використання, безпеки та захищеності ПО, - вони здаються більшості фахівців набагато складнішими, ніж це описується даним стандартом.

13. Управління процесом розробки програмного забезпечення: завдання, особливості.

Завдання управління проектами

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

Щоб відповісти на питання про те, якими критеріями керуються при оцінці проектів, і чого потрібно домагатися, треба розглянути його з різних аспектів.

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

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

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

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

На рівні кількох незалежних один від одного проектів (таку групу проектів називають програмою), в ході яких створюються і допрацьовуються кілька продуктів на єдиній платформі, а також можуть надаватися різні послуги, пов'язані з цими продуктами, цінності пов'язані, перш за все, з якістю загальної архітектури створюваних продуктів.

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

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

Розробка програмного забезпечення (ПО) являє собою складну систему взаємозв'язку різних процесів реалізації проекту. Сюди слід віднести роботу з вимогами, що висуваються до кінцевого продукту, роботу з технічними ризиками реалізації проекту, комплекс заходів щодо забезпечення і управління якістю, а також інші процеси, які виникають в процесі розробки або мають місце в світі використовується політики проекту організації. Кожен процес має свої специфічні особливості, які також можуть бути регламентовані внутрішньою політикою організації. Це дозволяє говорити про те, що кожна організація має величезним управлінським потенціалом, від якого на певному проекті залежить як наявність тих чи інших процесів розробки, їх специфіки, так і кінцевий результат їх виконання. Успішне завершення кожного процесу розробки ПО може гарантувати більш високу якість кінцевого продукту, велику економічну віддачу (вигоду), підвищення рівня зрілості, як проекту, так і організації в цілому.
 Формування сукупності процесів розробки ПЗ та управління ними окремо і всієї їх сукупністю в цілому дозволяє визначити в якості ключових факторів політики тимчасове диференціювання вузького набору завдань і пріоритизації кожного завдання. При цьому поняття приоритизации пропонується розглядати набагато ширше, оскільки система призначення та управління пріоритетами може поширюватися як на великі завдання, так і на більш дрібні підзадачі, а також цілі процеси з усіма складовими їх механізмами реалізації. Що стосується тимчасового диференціювання, то даний фактор політики управління розробкою ПЗ пропонується розглядати в рамках однієї ітерації, оскільки кількість ітерацій програмного забезпечення часто прямує до нескінченності, а тимчасові рамки при цьому повинні бути уніфіковані відповідно до стратегії розвитку проекту.

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

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

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

Опис специфіки розробки і супроводу внутрішнього ПО в невеликій компанії - не розробника ПЗ

Велике число завдань (більше половини) пов'язано з супроводом, підтримкою і доопрацюванням існуючого ПО;

Завдання, пов'язані з супроводом існуючих систем практично незалежні один від одного, можуть бути вирішені за невеликий час, але виникають часто і вимагають оперативного вирішення;

Розробка і супровід ведеться невеликою групою фахівців, а часто і взагалі однією людиною;

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

Проекти найчастіше не виходять за рамки внутрішнього використання.

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

Загальні рекомендації по організації процесу розробки

Перш, ніж потурбуватися про створення основ технології, необхідно по максимуму вирішити всі організаційні проблеми. У літературі часто розглядається питання організації робочого середовища в компанії-розробника ПЗ, проте, для компанії, в якій відділ розробки зовсім невеликий (1-3 людини), багато хто з цих рекомендацій здадуться зайвими. Проте, таким компаніям рекомендації потрібні не менше. Зі свого досвіду я можу рекомендувати наступне:

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

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

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

4. Виділіть для розробників окремий телефонний номер
 Не привертайте розробників до секретарської роботі. Розробники часто відповідальні і пунктуальні люди - у менеджерів, при всій до них повазі, часто немає часу. Не відчуваючи характер роботи розробника вони можуть, без жодної задньої думки, скинути половину дзвінків на них.

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

6. Вважайте і враховуйте зайнятість розробника
 У світі, що змінюється бізнесу, наприклад, в телекомунікаційному бізнесі, число завдань, пов'язаних з підтримкою існуючих систем залишається приблизно постійним. Невеликі зміни в існуючому ПЗ потрібні регулярно. У процесі розробки нового ПЗ число систем, які необхідно супроводжувати, зростає. Що виходить? Сумарне число завдань зростає з часом. Якщо розробник говорить, що він перестає справлятися з обсягом завдань, швидше за все це так. Візьміть ще одну людину, або замовте розробку і супровід частини ПО іншим організаціям.

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

8. Зрештою, створіть документ, що описує організаційну структуру підприємства
 Який би невеликий не була ваша компанія, такий документ просто необхідний. Як мінімум, він необхідний розробнику, для того, щоб знати, з ким контактувати з якого питання

Виділення основних процесів

Коли організаційні проблеми вирішені на достатньому рівні, можна сконцентруватися на процесі розробки.

Безсумнівно, навряд чи в цьому випадку вдасться реалізувати будь-якої великоваговий процес розробки, і література з даного питання, швидше за все, не сильно допоможе, але формалізувати існуючі процеси і зробити їх більш ефективними постаратися варто.

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

Найбільш ймовірно, що ви зможете виділити наступні процеси:

Поняття складності програмної системи. Оцінка розміру та складності ПЗ. | Розробка вимог


ТЕХНОЛОГІЯ ПРОГРАМУВАННЯ | Етапи розвитку технології програмування. | Життєвий цикл програмного забезпечення. Основні етапи і моделі ЖЦ ПО. | | Блочно-ієрархічний підхід до створення складних систем. | Поняття уніфікованого процесу розробки ПО. Фази проекту по RUP. | Поняття екстремального програмування. | Визначення вимог до програмного забезпечення. Аналіз предметної області. Технічне завдання. | Поняття помилки в ПЗ. Поняття надійності ПЗ. | Специфіка управління персоналом |

© 2016-2022  um.co.ua - учбові матеріали та реферати