Агилно моделирање

Од Википедија — слободната енциклопедија

Агилното моделирање (АМ) — методологија за моделирање и документација на софтверски системи засновани на најдобрите практики. Тоа е колекција на вредности и принципи, што може да се примени на (агилен) проект за развој на софтвер. Оваа методологија е пофлексибилна од традиционалните методи на моделирање, што овозможува подобро да се вклопи во средина што брзо се менува.[1] Дел е од агилниот развој на софтвер.

Агилното моделирање е додаток на другите агилни методологии за развој како што се Scrum, extreme programming (XP) и Rational Unified Process (RUP). Експлицитно е вклучен како дел од рамката за disciplined agile delivery (DAD). Според статистичките податоци за 2011 година, агилното моделирање сочинува 1% од целиот агилен развој на софтвер.[2]

Основни практики[уреди | уреди извор]

Постојат неколку основни практики:

Документација[уреди | уреди извор]

  1. Документирајте постојано. Документацијата се прави во текот на целиот животен циклус, паралелно со создавањето на остатокот од решението.
  2. Задоцнета документација. Документацијата се прави што е можно подоцна, избегнувајќи шпекулативни идеи кои веројатно ќе се променат во корист на стабилна информација.
  3. Спецификации што може да се извршат. Барањата се наведени во форма на извршни „тестови на клиенти“, наместо неизвршна „статичка“ документација.
  4. Информации од еден извор. Информациите (модели, документација, софтвер), се чуваат на едно место и само на едно место, за да се спречат прашања за тоа што е „точната“ верзија/информација.

Моделирање[уреди | уреди извор]

  1. Активно учество на засегнатите страни. Заинтересираните страни на решението/софтверот што се моделира треба активно да се вклучат во тоа. Ова е продолжение на практиката за клиенти на лице место од Екстремно програмирање.
  2. Замислување на архитектурата. Тимот изведува моделирање на мала тежина и високо ниво, што е само едвај доволно добро (JBGE) на почетокот на софтверскиот проект за да се истражи стратегијата за архитектура за која тимот верува дека ќе успее.
  3. Инклузивни алатки. Претпочитајте алатки за моделирање, како што се бели табли и хартија, со кои е лесно да се работи.
  4. Моделирање на повторување. Кога одредено барање/работна ставка не е доволно детално истражено преку моделирање од напред, тимот може да избере да го направи тоа истражување за време на нивната сесија за планирање на итерација. Потребата да се направи ова генерално се гледа како симптом дека тимот не прави доволно моделирање однапред.
  5. Едвај доволно добро (JBGE). Целиот артефакт, вклучително и моделите и документите, треба да бидат доволно доволни за задачата што е предмет. JBGE е од контекстуална природа, во случај на моделот, тоа се определува со комбинација на сложеност на кој било модел што го опишува и вештините на публиката за тој модел.
  6. Моделирање од напред. Агилен тим ќе ги разгледа своите заостанати една или повеќе итерации прво за да осигура дека за барање/работна ставка е подготвена да се работи. Исто така наречено „заостанување на дотерување“ или „рафинирање на заостанат број“ во Scrum.
  7. Модерно невреме. Кратка, честопати импровизирана, агилна сесија за моделирање. Се одржуваат моделски сесии за бура за да се истражат деталите за барање или аспект на вашиот дизајн.
  8. Повеќе модели. Агилните моделири треба да знаат како да создадат низа типови модели (како што се кориснички приказни, мапи со приказни, модели на податоци, дијаграми на унифициран јазик за моделирање (UML) и многу повеќе) за да го применат најдобриот модел за ситуацијата во која се наоѓаат.
  9. Приоритетни барања. На барањата треба да се работи по редослед по приоритет.
  10. Предвидени барања. Тимот изведува моделирање со мала тежина и високо ниво што е JBGE на почетокот на софтверскиот проект за истражување на барањата на засегнатите страни.

Ограничувања[уреди | уреди извор]

Постои значителна зависност од лична комуникација и соработка со клиенти. Агилното дисциплини за моделирање може да биде тешко да се применат.

  • На големи тимови (да речеме 30 или повеќе) без соодветна поддршка за инструменти.
  • Каде што членовите на тимот не се во можност да споделуваат и да соработуваат на модели (што воопшто би го отежнило агилниот развој на софтвер).
  • Кога вештините за моделирање се слаби или недостасуваат.

Поврзано[уреди | уреди извор]

  • Моделирање водено од приказни
  • Агилен развој на софтвер
  • Дијаграм на робусност

Наводи[уреди | уреди извор]

  1. Agile modeling (AM) home page, effective practices for modeling and documentation
  2. „State of Agile Development Survey Results, 2011“. Архивирано од изворникот на 2015-07-17. Посетено на 2021-02-20.

Надворешни врски[уреди | уреди извор]