Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Агильді модельдеу (AM) – ең жақсы тәжірибелерге негізделген бағдарламалық жүйелерді модельдеу және құжаттау әдістемесі. Бұл (агильді) бағдарламалық жасақтаманы әзірлеу жобасына қолданылатын құндылықтар мен қағидалар жиынтығы. Бұл әдістеме дәстүрлі модельдеу әдістерінен гөрі икемдірек, сондықтан үнемі өзгеріп отыратын ортаға жақсы сай келеді. Ол агильді бағдарламалық жасақтаманы әзірлеу құралдарының бір бөлігі болып табылады. Агильді модельдеу Scrum, экстремалды бағдарламалау (XP) және Рационалды біріктірілген процесс (RUP) сияқты басқа да агильді даму әдістемелеріне толықтыру болып табылады. Бұл тәртіпті агильді жеткізу (DAD) шеңберінің құрамына нақты түрде енгізілген. 2011 жылғы статистика бойынша, агильді модельдеу барлық агильді бағдарламалық жасақтаманың 1% құрады. Агильді модельдеу – Agile модельдік инженерияның (Agile MDE) бір түрі, ол веб-қосымшаларды әзірлеу, қаржы және автомобильдік жүйелер сияқты бірнеше қолдану салаларында қабылданған.
Agile modeling (AM) is a methodology for modeling and documenting software systems based on best practices. It is a collection of values and principles that can be applied on an (agile) software development project. This methodology is more flexible than traditional modeling methods, making it a better fit in a fast changing environment. It is part of the agile software development tool kit. Agile modeling is a supplement to other agile development methodologies such as Scrum, extreme programming (XP), and Rational Unified Process (RUP). It is explicitly included as part of the disciplined agile delivery (DAD) framework. As per 2011 stats, agile modeling accounted for 1% of all agile software development. Agile modeling is one form of Agile model driven engineering (Agile MDE), which has been adopted in several application areas such as web application development, finance, and automotive systems
Құжаттамалық
Үнемі құжаттау. Құжаттама шешімнің қалған бөлігімен бірге, өмірлік цикл бойында жасалады. Кешіктіріп құжаттау. Құжаттама мүмкіндігінше соң жасалады, өзгеріп қалуы мүмкін болжамдық ойлардан аулақ болып, тұрақты ақпаратқа басымдық беріледі. Орындалатын талаптар. Талаптар орындалатын "тәжірибелік тесттер" түрінде беріледі, орындалмастан "статикалық" құжаттаманың орнына. Бір дереккөзді ақпарат. Ақпарат (модельдер, құжаттама, бағдарламалық жасақтама) "дұрыс" нұсқасы/ақпарат туралы сұрақтар тудырмау үшін бір ғана жерде сақталады.
Document continuously. Documentation is made throughout the life cycle, in parallel to the creation of the rest of the solution. Document late. Documentation is made as late as possible, avoiding speculative ideas that are likely to change in favor of stable information. Executable specifications. Requirements are specified in the form of executable "customer tests", instead of non executable "static" documentation. Single source information. Information (models, documentation, software), is stored in one place and one place only, to prevent questions about what the "correct" version / information is.
Модельдеу
Белсенді мүдделі тараптардың қатысуы. Модельдеуге алынатын шешімнің/бағдарламалық құралдың мүдделі тараптары осы процеске белсенді түрде қатысуы керек. Бұл Extreme Programming-нің клиенттермен жұмыс істеу тәжірибесінің кеңейтілген нұсқасы. Архитектураны көз алдымен елестету. Команда жобаның басында жеңіл салмақты, жоғары деңгейдегі модельдеуді (JBGE) жүргізеді, бұл команданың жұмыс істейтініне сенетін архитектуралық стратегияны зерттеу үшін жасалады. Кіріктірілген құралдар. Модельдеу үшін ақ тақталар мен қағаз сияқты пайдалануға оңай құралдарды қолдануға басымдық беру керек (олар кіріктірілген). Итерациялық модельдеу. Егер талап/жұмыс элементі алдын ала қарау арқылы толыққанды зерттелмесе, команда оны итерация/спринт жоспарлау кезінде зерттеуге тырысуы мүмкін. Мұндай қажеттілік көбінесе команданың жеткілікті алдын ала зерттеу жүргізбегенін көрсетеді. Жеткілікті түрде жақсы (JBGE). Барлық артефакттар, модельдер мен құжаттарды қоса алғанда, қолдағы міндетті орындау үшін жеткілікті болуы керек. JBGE контексттік сипатқа ие, модель үшін бұл модель сипаттайтын мәселенің күрделілігі мен аудиторияның біліктілігіне байланысты анықталады. Алдын ала модельдеу. Жеңіл команда талаптың/жұмыс элементінің жұмыс істеуге дайын екеніне көз жеткізу үшін бір немесе бірнеше итерация/спринт алдын ала қарап шығады. Бұл Scrum-да "артта қалғанды өңдеу" немесе "артта қалғанды жетілдіру" деп те аталады. Модельдеу шабуылы. Қысқа, көбінесе спонтанды, шапшаң модельдеу сессиясы. Модельдеу шабуылы сессиялары талаптың немесе дизайныңыздың бір қырының егжей-тегжейлі зерттеуі үшін өткізіледі. Көптеген модельдер. Шапшаң модельдеушілер әртүрлі модель түрлерін (мысалы, пайдаланушы оқиғалары, оқиға карталары, дерек модельдері, Бірыңғай модельдеу тілі (UML) диаграммалары және т.б.) қалай жасау керектігін білуі керек, осылайша қолдағы жағдайға ең қолайлы модельді қолдануға болады. Басымдық берілген талаптар. Талаптар басымдық ретімен орындалуы керек. Талаптарды болжау. Команда жобаның басында мүдделі тараптардың талаптарын зерттеу үшін жеңіл салмақты, жоғары деңгейдегі модельдеуді (JBGE) жүргізеді.
Active stakeholder participation. Stakeholders of the solution/software being modeled should be actively involved with doing so. This is an extension of the on site customer practice from Extreme Programming. Architecture envisioning. The team performs light weight, high level modeling that is just barely good enough (JBGE) at the beginning of a software project so as to explore the architecture strategy that the team believes will work. Inclusive tools. Prefer modelling tools, such as whiteboards and paper, that are easy to work with (they're inclusive). Iteration modeling. When a requirement/work item has not been sufficiently explored in detail via look ahead modeling the team may choose to do that exploration during their iteration/sprint planning session. The need to do this is generally seen as a symptom that the team is not doing sufficient look ahead modeling. Just barely good enough (JBGE). All artifacts, including models and documents, should be just sufficient for the task at hand. JBGE is contextual in nature, in the case of the model it is determined by a combination of the complexity of whatever the model describes and the skills of the audience for that model. Look ahead modeling. An agile team will look down their backlog one or more iterations/sprints ahead to ensure that a requirement/work item is ready to be worked on. Also called "backlog grooming" or "backlog refinement" in Scrum. Model storming. A short, often impromptu, agile modeling session. Model storming sessions are held to explore the details of a requirement or aspect of your design. Multiple models. Agile modelers should know how to create a range of model types (such as user stories, story maps, data models, Unified Modeling Language (UML) diagrams, and more) so as to apply the best model for the situation at hand. Prioritized requirements. Requirements should be worked on in priority order. Requirements envisioning. The team performs light weight, high level modeling that is JBGE at the beginning of a software project to explore the stakeholder requirements.