Original: http://www.ndpsoftware.com/softwareDevMaturityModel.php
Переписування buggiest функцію в системі пропонує набагато більше користі, ніж працювати на відносно стабільному районі. Те ж саме відноситься і до організаціям: якщо продавці закрити десятки угод, але немає програмістів, щоб створити фантомне, витрачати більше грошей, навчання продавців не допоможе. Закріпити команду розробників. Це очевидно, але поняття виявлення слабкості займається розробкою програмного забезпечення була зародком ідеї, викладеної нижче.
Я працював з десятками організацій протягом багатьох років, і всі вони мають свої сильні і слабкі сторони. Мене попросили кілька разів, щоб оцінити “, як наш процес розробки програмного забезпечення відбувається?” Я можу, звичайно, копати і побачити свої слабкості, але мають зовнішню систему класифікації, як і в таблиці нижче, дозволяє більш аргументованого рекомендацію.
У наступній таблиці наведено категорії зрілості розробки програмного забезпечення в рамках організації. Він був натхненний КІМ (здатність моделі зрілості), але ні в якій мірі намагається наслідувати його.
Щоб використовувати цю таблицю, спочатку оцінити, де ця організація по відношенню до кожної області. Виходячи з мого досвіду, більшість організація не буде відповідати просто в один рівень зрілості, а різні рівні в різних областях. Вони краще на деякі речі більше, ніж інші. Наприклад, це поширене мати контроль вихідного коду працює добре, але не помилка системи стеження.
Після того, як ви зробили цю оцінку, сильні і слабкі сторони організації будуть більш очевидними. CMM відлуння, що перш ніж стати зрілим в одній області, і організація повинна охоплювати інші області в першу чергу. Це просто означає, зосередитися на поліпшенні тих областях, де ви найслабше. Зосередження уваги на найслабших місць забезпечить максимальну користь для інвестицій зміни організаційної. Це була ідея покласти цю таблицю разом.
Рівень 1 найнижчий рівень. Часто вона характеризується “сюрпризів”. Він позначається програмної організацією, яка поставила частина програмного забезпечення, і, на жаль, багато організацій не на цьому рівні.
2-го рівня організації поставили програмне забезпечення неодноразово, але не без значних гикавки. Часто вона характеризується “розчарування”. Є осічки, занедбані проекти, але програмне забезпечення виходить.
Рівень 3 є зрілою організацією програмне забезпечення, яке має людей і проекти вирівняні. Можливості визначені, створені програмне забезпечення, і клієнти були задоволені. Там будуть помилки, але вони ідентифіковані як можна раніше.
Вимоги, продукт і управління проектами
Рівень 1
робоче програмне забезпечення описує вимоги; майбутні потреби можуть бути ідентифіковані, але вони не-пріоритети, неповні; процес є хаотичним або спеціальної; швидко змінюється бачення продукту; Успіх може зажадати героїки; невдачі; занедбані проекти
Рівень 2
активне управління проектами, послідовні успіхи; опубліковані, пріоритетні вимоги (або призначені для користувача історії); в поєднанні з пожежних навчань, наприкінці або баггі-релізів; процес розробки продукту визначається, хоча і не обов’язково слідують або ефективним
Рівень 3
передбачуваним успіхом; гнучкою, ефективною, максимізації вартості; інституціоналізації, оптимізації; як стратегічні і тактичні плани, з можливістю бути опортуністичних; рідко будують функції малоцінних; загального розуміння процесу; здатність ефективно змінити пріоритети вимог; надійні оцінки; Управління ризиками
Програмування команди
Рівень 1
окремі особи будують продукти
Рівень 2
функціональна команда, володіння кодом, код керівництво по стилю; загальний дизайн у міру необхідності
Рівень 3
загальний володіння кодом, спільно розробляє програмне забезпечення, моделі і стратегії; коду стилю відповідності, перевірки коду; професійний розвиток, перехресне навчання
Код
Рівень 1
“Гей, це працює!”; Бункер-ед знань; код мінно-поля і баггі областях; доморощені рішення; Нередагована успадковані ділянки
Рівень2
працює добре; Деякі застарілі проблемні області; основні концепції бізнесу перевірені і документовані; дублювати рішення тих же проблем
Рівень 3
колективна власність; консистенція; організовані; сучасні моделі і інструменти; інтегровані сучасні інструменти
Контроль якості
Рівень 1
Система відстеження дефектів включає в себе після його і списки справ; для контролю якості, всі фішки в, або “команда продажів виглядає його на”
Рівень 2
дефект системи стеження, план забезпечення якості; функціональні тести; може мати деякий автоматизоване тестування, тестування модулів; більшість змін пройти тестування системи, але може бути екстрені виправлення, які пропускають процес
Рівень 3
інтегрований в процесі розвитку; безперервна інтеграція, метрики покриття коду, інші метрики програмного забезпечення в міру необхідності; План забезпечення якості на місці і виконані
Інструменти програмування
Рівень 1
інструменти (редактори, компілятори і т.д.)
Рівень 2
сучасні, професійні інструменти
Рівень 3
уніфіковані, сучасні та професійні інструменти
Управління вихідним кодом і будує (управління конфігурацією)
Рівень 1
є вихідний код в руці, резервні копії, пронумерованих випусків
Рівень 2
сучасний інструмент, такий як SVN, CVS, Git, Р4 і т.д.; в основному сценаріїв в стані збірки
Рівень 3
ув’язка змін коду вимогам і помилок; видимість і метрики в код; повністю скриптових і автоматизоване складання;
Процес вивільнення
Рівень 1
визначається (або із затримкою) за якістю програмного забезпечення та завершення художнього
Рівень 2
заплановано на основі завершення ознак через регулярні проміжки часу; ранні ознаки жертвопринесення планування; пізно жертва якості або корабля датою
Рівень 3
завжди виділяється якість; підтримувати якість і дата випуску; жертвувати особливості малоцінних
