Dev [elopment of] Art [ifacts]

У нас в кожному мітинг румі висить табличка: "Is this meeting AAA? Attendees, Agenda, Action". Як і концепції SMART , цей девіз дозволяє "зберігати фокусування". Методологія Agile органічно стала частиною моєї проф. діяльності. Чому?

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

Відповідно до концепцій постійного поліпшення процесів, я намагався сформулювати для себе щось аналогічне, але з ухилом і спеціалізацією в бік розробки програмного забезпечення. І якщо звернутися до першоджерел то це проекція деякого симбіозу RUP + Agile на процес розробки.

Is your project FISABCT?

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

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

Результатом кожного етапу має бути відчутний артефакт, який можна передати, використовувати як вхідні дані для наступного етапу або рефаторінга попередніх (SRS, UML, Bug report і т.д).

F eatures (s)

Перший етап. Протягом цього етапу Ви визначаєте, що те, у що виллється розробка буде корисним і принесе прибуток. Для більшості розробників цей етап або приховано, або неявно виражається у вигляді SRS чи інших формах. Але для тих хто хоч раз розробляв власний продукт, це дуже важливий етап. Тут потрібно "відчувати" main-stream прикладного домену та визначати USP вашого продукту системи.

Чи робити стандартну реєстрацію або залишити тільки OpenID?
Undo/Redo операції повинні бути обов'язково реалізовані для WYSIWYG системи!
...

I dea

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

S cope

Етап розумного розширення завдань. Тут, Ви можете включати родинні завдання, передбачити майбутні завдання. Девіз цього етапу - вирішити задачу в максимально загальному вигляді.

A rchitecture

Мета даного етапу - сформувати "Загальну Картину". За його завершення, має бути визначено максимальну кількість сутностей і взаємодій як усередині системи так і на її кордонах.

orthogonal B asis

Мінімально можливий, достатній набір сутностей і взаємодій, в базисі яких повинна бути ефективно виражена архітектура.

C ode

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

T est (s)

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

Комбінаторний вибух

Відповідно до запропонованої схеми діаграма інформаційних потоків виглядає наступним чином

Наявність зворотного зв'язку дозволяє реалізовувати циклічні схеми розробки, але з іншого боку - збільшує комбінаторну складність.

Кожен з переходів важливий і потребує уваги від розробників, але деякі з них маю більший вплив на збільшення термінів і стабільність створюваної системи. Ось деякі з них:

I ->S На цьому етапі ми не тільки препаруємо вимоги і перетворюємо їх в технічні, а й розширюємо список завдань, передбачаючи майбутні запити і оптимізуючи виконання споріднених завдань
A ->B Всі попередні етапи, влючая А, виробляють збір інформації, розширюють межі системи і збільшують її складність. Побудова базису покликане зменшити цю складність
B Перехід, який констатує факт того, що розроблена раніше архітектура і базис, більше не можуть задовольняти всі запити щодо реалізації

Ролі і Артефакти

Для запропонованого базису можна виділити п'ять ролей: Product Owner (PO)/Application Engineer (AE), Architect, Developer, Configuration Manager (CM), Test Engineer (TE). Звичайно в деяких випадках, декілька або навіть всі ролі можуть поєднуватися одним розробником.

Мінімальний набір актефактов за проектом може виглядати наступним чином:

PO, AE : Опис системи з точки зору користувача, наприклад у формі SRS
Architect : Опис архітектури інформаційної системи, наприклад з використанням UML
Developer : Вихідні коди, коментарі
CM : скрипти автоматизації та розгортання
TE : звіти про помилки та виконаних тестах

Що ж дозволяє отримати даний підхід?

Висловити систему в певному базисі
Розмежувати зони відповідальності і затвердити список необхідних артефактів для кожного етапу
Виробити набір реакцій на зміни в кожній конкретній частини системи. Звіт від помилку C , відрізняється від "Epic Fail" B

Опубліковано: 27/07/11 @ 01:41
Розділ Різне

SEO Блог