Функционалды дамыту процесі: Бағдарламалық жасақтаманы әзірлеу әдісі
Feature-driven development
Жаңа бағдарлама жасау процесі: Feature Driven Development (FDD) – жеңіл, итеративті әдіс. Жылдам, жұмыс істейтін бағдарламаны жасауға көмектеседі. Agile негіздері.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Бағдарламалық жасақтаманы әзірлеу процесі
Software development process
Құралдылыққа бағытталған әзірлеу (FDD) – итеративті және инкрементті бағдарламалық жасақтаманы әзірлеу процесі. Бұл бағдарламалық жасақтаманы әзірлеудің жеңіл немесе Agile әдісі. FDD өнеркәсіпте мойындалған бірнеше ең жақсы тәжірибелерді біртұтас жүйеге біріктіреді. Бұл тәжірибелер клиент бағалайтын функционалдық (құралдық) мүмкіндіктерге бағынышты. Оның басты мақсаты – Agile манифестінің принциптеріне сәйкес, уақтылы түрде, қайта-қайта қолданылатын, жұмыс істейтін бағдарламалық жасақтаманы жеткізу.
Feature driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends several industry recognized best practices into a cohesive whole. These practices are driven from a client valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto.
Тарих
FDD бастапқыда Джефф Де Лука 1997 жылы Сингапурдың ірі банкінде 15 айлық, 50 адамнан тұратын бағдарламалық жасақтаманы әзірлеу жобасының нақты қажеттіліктерін қанағаттандыру мақсатымен жасалған. Бұл нәтижесінде жалпы модельді дамытуды, мүмкіндіктерді тізімдеуді, жоспарлауды, жобалауды және құруды қамтитын бес процестен тұратын жиынтық пайда болды. Бірінші процесс Питер Коадтың нысанды модельдеуге қатысты көзқарасымен күшті байланысты. Екінші процесс функционалдық талаптарды және даму тапсырмаларын басқару үшін мүмкіндіктер тізімін пайдалану идеяларын қамтиды. Қалған процестер Джефф Де Луканың тәжірибесінің нәтижесі болып табылады. Сингапур жобасында FDD-нің табысты қолданылуынан кейін, FDD бірнеше рет іске асырылды. FDD сипаттамасы алғаш рет 1999 жылы Питер Коад, Эрик Лефевр және Джефф Де Луканың "UML-мен түсті Java модельдеуі" кітабының 6-тарауында әлемге таныстырылды. Кейін, Стивен Палмер мен Мак Фелсингтің "Мүмкіндіктерге бағытталған әзірлеуге қатысты практикалық нұсқаулық" кітабында (2002 жылы жарық көрген) Java модельдеуінен тәуелсіз, FDD-нің толыққанды сипаттамасы берілді.
FDD was initially devised by Jeff De Luca to meet the specific needs of a 15 month, 50 person software development project at a large Singapore bank in 1997. This resulted in a set of five processes that covered the development of an overall model and the listing, planning, design, and building of features. The first process is heavily influenced by Peter Coad's approach to object modeling. The second process incorporates Coad's ideas of using a feature list to manage functional requirements and development tasks. The other processes are a result of Jeff De Luca's experience. There have been several implementations of FDD since its successful use on the Singapore project. The description of FDD was first introduced to the world in Chapter 6 of the book Java modelling in Color with UML by Peter Coad, Eric Lefebvre, and Jeff De Luca in 1999. Later, in Stephen Palmer and Mac Felsing's book A Practical Guide to Feature Driven Development (published in 2002), a more general description of FDD was given decoupled from Java modelling.
Шолу
FDD – бұл бес негізгі іс-әрекеттен тұратын, модельге бағытталған, қысқа итерациялық процесс. Бағдарламалық қамтамасты дамыту жобасының күйін дәл баяндау және қадағалау үшін, әрбір мүмкіндік бойынша атқарылған жұмысты көрсететін кезеңдер анықталады. Бұл бөлім іс-әрекеттерге жалпы шолу ұсынады. Оң жақтағы суретте осы іс-әрекеттердің мета-процесс моделі көрсетілген. Алғашқы екі тізбекті іс-әрекет кезінде жалпы модельдік пішін қалыптасады. Соңғы үш іс-әрекет әрбір мүмкіндік үшін қайталанады.
FDD is a model driven short iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined. This section gives a high level overview of the activities. In the figure on the right, the meta process model for these activities is displayed. During the first two sequential activities, an overall model shape is established. The final three activities are iterated for each feature.
Жалпы үлгісін әзірлеу
FDD жобасы жүйенің көлемі мен оның контекстін жоғары деңгейде қарап шығудан басталады. Содан кейін, шағын топтар әр модельдеу саласы үшін егжей-тегжейлі домендік модельдерді жасайды және олар өзара бағалау үшін ұсынылады. Ұсынылған модельдердің бірі немесе бірнешесі әр домендік сала үшін модель ретінде таңдалады. Домендік сала модельдері біртіндеп бірыңғай модельге біріктіріледі.
The FDD project starts with a high level walkthrough of the scope of the system and its context. Next, detailed domain models are created for each modelling area by small groups and presented for peer review. One or more of the proposed models are selected to become the model for each domain area. Domain area models are progressively merged into an overall model.
Құралымдар тізімін құру
Бастапқы модельдеу кезінде жиналған білімдер доменді тақырыптық салаларға функционалдық түрде бөлу арқылы ерекшеліктер тізімін анықтау үшін пайдаланылады. Әр тақырыптық сала бизнес-қызметтерді қамтиды, ал әр бизнес-қызметтің ішіндегі қадамдар санатталған ерекшеліктер тізімін құруға негіз болады. Осы тұрғыда ерекшеліктер – клиент үшін құнды функциялардың шағын бөліктері, олар "<әрекет> <нәтиже> <объект>" нысанында беріледі, мысалы: 'сатудың жалпы сомасын есептеу' немесе 'пайдаланушының паролін тексеру'. Ерекшеліктің орындалуы екі аптадан аспауы тиіс, әйтпесе оны кішірек бөліктерге бөлу қажет.
Knowledge gathered during the initial modeling is used to identify a list of features by functionally decomposing the domain into subject areas. Subject areas each contain business activities, and the steps within each business activity form the basis for a categorized feature list. Features in this respect are small pieces of client valued functions expressed in the form "<action> <result> <object>", for example: 'Calculate the total of a sale' or 'Validate the password of a user'. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.
Нысан бойынша жоспар
Құралымдар тізімі толыққаннан кейін, келесі қадам – даму жоспарын әзірлеу және функциялардың (немесе функциялар жиынтығының) жауаптылығын бағдарламашыларға кластар түрінде жүктеу.
After the feature list is completed, the next step is to produce the development plan and assign ownership of features (or feature sets) as classes to programmers.
Құралымы бойынша жобалау
Әрбір мүмкіндік үшін жобалық пакет дайындалады. Бас бағдарламашы екі апта ішінде жасалатын мүмкіндіктердің шағын тобын іріктейді. Тиісті класс иелерімен бірге бас бағдарламашы әрбір мүмкіндік үшін егжей-тегжейлі реттілік схемаларын жасайды және жалпы модельді нақтылайды. Содан кейін класс пен әдіс кіріспелері жазылады, және соңында жобаны сараптау өткізіледі.
A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence diagrams for each feature and refines the overall model. Next, the class and method prologues are written, and finally a design inspection is held.
Құрамына қарай құру
Әрбір мүмкіндікті жасау үшін жобалау сәтті тексерілгеннен кейін, сынып иелері өз сыныптары үшін код жасайды. Бөлімдік тесттен өткізіп, кодты сәтті тексеруден кейін, дайын мүмкіндік негізгі жиынға көшіріледі.
After a successful design inspection for each activity to produce a feature is planned, the class owners develop code for their classes. After unit testing and successful code inspection, the completed feature is promoted to the main build.
Үздік тәжірибелер
Фичаға бағытталған даму – клиентке құнды фичалар тұрғысынан қарағанда, бағдарламалық инженерияның ең жақсы тәжірибелеріне негізделген. Домендік объектілерді модельдеу. Домендік объектілерді модельдеу – шешілуі тиіс мәселенің доменін зерттеу және түсіндіруден тұрады. Нәтижесіндегі домендік объектілер моделі фичаларды қосу үшін жалпы құрылымды ұсынады. Фича бойынша даму. Егер бір функцияны екі апта ішінде жүзеге асыру қиын болса, ол әрбір кіші мәселе фича деп аталатынша кішірек функцияларға бөлінеді. Бұл дұрыс функцияларды жеткізуді және жүйені кеңейтуді немесе өзгертуді жеңілдетеді. Жеке класс (код) меншігі. Жеке класс меншігі – кодтың бөлек бөліктері немесе топтары бір иесіне беріледі дегенді білдіреді. Иесі класс сақталуы, өнімділігі және тұжырымдық толықтығы үшін жауапты болады. Фича командалары. Фича командасы – шағын, динамикалық түрде құрылған, шағын қызметті дамытатын команда. Кез келген жобалау шешіміне бірнеше ой қолданылады және бірін таңдаудан бұрын бірнеше жобалау нұсқасы бағаланады. Тексерулер. Тексерулер, негізінен, ақауларды анықтау арқылы жақсы сапалы жобалау мен кодты қамтамасыз ету үшін жүргізіледі. Конфигурациялық басқару. Конфигурациялық басқару бүгінгі күнгі барлық аяқталған фичалардың бастапқы кодын анықтауға және фича командалары оларды жақсартар кезде классқа енгізілген өзгерістердің тарихын сақтауға көмектеседі. Тұрақты құрастыру. Тұрақты құрастыру клиентке көрсетуге болатын әрқашан жаңартылған жүйенің болуын қамтамасыз етеді және фичалардың бастапқы кодын интеграциялау кезіндегі қателерді ертерек анықтауға көмектеседі. Прогресс пен нәтижелердің көрінуі. Менеджерлер жобаны жобаның ішкі және сыртқы барлық деңгейлерінен жиі, тиісті және нақты прогресс есебін беру арқылы, аяқталған жұмыстарға негізделген басқарады.
Feature driven development is built on a core set of software engineering best practices aimed at a client valued feature perspective. Domain Object modelling. Domain Object modeling consists of exploring and explaining the domain of the problem to be solved. The resulting domain object model provides an overall framework in which to add features. Developing by Feature. Any function that is too complex to be implemented within two weeks is further decomposed into smaller functions until each sub problem is small enough to be called a feature. This makes it easier to deliver correct functions and to extend or modify the system. Individual Class (Code) Ownership. Individual class ownership means that distinct pieces or grouping of code are assigned to a single owner. The owner is responsible for the consistency, performance, and conceptual integrity of the class. Feature Teams. A feature team is a small, dynamically formed team that develops a small activity. Multiple minds are always applied to each design decision, and multiple design options are evaluated before one is chosen. Inspections. Inspections are carried out to ensure good quality design and code primarily by the detection of defects. Configuration Management. Configuration management helps with identifying the source code for all features that have been completed to date and maintaining a history of changes to classes as feature teams enhance them. Regular Builds. Regular builds ensure there is always an up to date system that can be demonstrated to the client and help highlight integration errors of source code for the features early. Visibility of progress and results. Managers steer a project using frequent, appropriate, and accurate progress reporting from all levels inside and outside the project based on completed work.
Метамодель (Метамодельдеу)
Метамодельдеу әдістің процестерін де, деректерін де визуализациялауға көмектеседі. Бұл әдістерді салыстыруға және әдіс инженериясы процесіндегі әдіс фрагменттерін оңай қайта пайдалануға мүмкіндік береді. Бұл техниканы қолдану UML стандарттарымен үйлеседі. Метадеректер моделінің сол жағында FDD қолданылатын бағдарламалық құралды әзірлеу жобасындағы бес негізгі іс-әрекет көрсетілген. Барлық іс-әрекеттер FDD процесінің сипаттамасындағы іс-әрекеттерге сәйкес келетін кіші іс-әрекеттерді қамтиды. Модельдің оң жағында осы іс-әрекеттерге қатысты ұғымдар көрсетілген. Бұл ұғымдар диаграмманың сол жағында бейнеленген іс-әрекеттерден туындайды.
Metamodelling helps visualize both the processes and the data of a method. This allows methods to be compared, and method fragments in the method engineering process can easily be reused. The usage of this technique is consistent with UML standards. The left side of the metadata model shows the five basic activities involved in a software development project using FDD. The activities all contain sub activities that corresponding to sub activities in the FDD process description. The right side of the model shows the concepts involved. These concepts originate from the activities depicted in the left side of the diagram.