A Research and Practice of Agile Unified Requirement Modeling

Transcription

1 2009 International Symposium on Intelligent Ubiquitous Computing and Education A Research and Practice of Agile Unified Requirement Modeling Huang ShuiYuan, Duan LongZhen, Xie Jun, Tao JunCai, Chen GuiXiang Department of Computer Science, Nanchang University, Nanchang China huangshuiyuan@163.com Abstract To reduce the practicing defects in ration unified process, this paper introduces a new requirement modeling process, which is based on the analysis of rational unified process with the combination of agile modeling technique. Contents of this process includes: getting the requirement in a general way, planning the developing schedule according to the requirement priority and simplifying requirement modeling of little incremental iteration etc., and the practice of this process implemented in a social insurance system showed it can improve the developing efficiency and the software quality. Keyword: Agile modeling; Software engineering; RUP; Requirement modeling 1.Introduction There are a lot of software can not be accomplished in time currently. The widely used rational unified process(rup) is the representative software developing process which tries to solve the problem[1]. As for software modeling, agile modeling(am) has an outstanding thinking in comparison with traditional modeling method, but it does not have a complete theory. The practice of agile modeling needs to be combined with concrete software developing processes. The easy cutting characteristic of RUP enables this combination to be realized. Because efficiency of requirement modeling is the premise of other phases in RUP, so it is the key point in improving the efficiency of developing and software quality. Thus, it is very necessary to do the research of requirement modeling. Due to the complexity and volatility of social insurance systems, we chose requirement modeling as the requirement analysis technique. The experimental result shows it can simplify the wok of requirement specification and has good adaptability in the case of requirement changing, so that the quality of software development is also improved. 2.Agile Rational Unified Process Agile modeling is a group of principles which can be used to direct software modeling. It is abstracted and summarized by Scott W. Ambler, which is based on multiple agile methodologies. The primary goal of AM is the software and another goal is the software maintenance. A summary and comparison of four kernel practices of AM thinking in software projects is listed in the following. Simple modeling with incremental iteration: 1) using appropriable products: each product has its advantages and disadvantages. We need to use different products for different purposes. The practice of RUP is using UML in most of the cases, but UML can not satisfy all kinds of requirements, such as the modeling of user interface; 2) creating multiple models concurrently and iterating to other products: there is no model can satisfy all kinds of modeling. For the same business, we need to use different model to acquire the requirements of different aspects; 3) little incremental modeling: a large quantity of work can be divided into some little increments spanned from several weeks to one or two months according to the time schedule. The practice is opposed with the before design thinking of current RUP practices. It can prevent the disadvantage of a long time modeling and document writing; 4) using simple tools to create simple models: this practice is a good supplement of the tools and models in current RUP practices. Effective team-working: coordination modeling, model opening and the deep participation of users can accelerate the generation of a well designed system framework. Modeling verification: due to the requirement of quick submit in agile developing, coding is the best method to verify models; while coding is after a large quantity of modeling, audit and modification in current RUP practices. Practice of agile documents: discarding temporary models, updating models when it is harmful, normalization of contact models. Current RUP practices always try to update all models and documents in time to keep the system consistency. RUP is a case-driven and incremental iteration process, and its kernel is the system architecture. Most of the developers think RUP as a complicated process, while they ignore its primary character of easy cutting. From the above analysis of AM and RUP practices, we can find all of the problems existing in current RUP practices can be solved with AM practices. AM practices can be blended with RUP practices in order to reduce the developing cycle and improve the software quality, which is called AM-RUP. AM-RUP is an easy changing sequential software developing process of user-centric, requirement driven and little incremental iteration. 3. Requirement modeling in AM-RUP /09 $ IEEE DOI /IUCE

2 A system modeling scheme is introduced according to the kernel thinking of AM-RUP, which is composed of getting the requirement in a general way, planning the developing schedule based on the requirement priority and simple requirement modeling of little incremental iteration. The scheme is shown in Figure1. Figure 1. Requirement modeling process of AM-RUP The requirement modeling in Figure 1 is compatible with the workflow sequence and iteration in RUP. The key difference between them is making little incremental iteration plan. Making little incremental plan can be easily used in AM. Moreover, it can reduce the contents of modeling and simplify the boring working of changing requirements, so that the improvement of software development can be ensured. 4.Requirement modeling practice in a social insurance system 4.1 Business modeling in social insurance systems-get the general requirement Workflow of business According to the principle of deep participation of users in AM-RUP, we invited our clients to take part in the modeling. The client is required to provide all details of a whole business procedure; this can avoid wasting time caused by the misunderstanding of developers. Since all business logic has been well described in the business procedure, it is easy to divide the whole system into modules and the priority of all modules can be also easily determined. Figure 2 shows the business procedure of the social insurance system. Although Figure 2 is not a complete flow diagram, it well illustrates the whole business existing in the social insurance system, and this work is directed by the simplification principle in AM-RUP. Figure 2.Operation flow diagram of social insurance Use case modeling For a better understanding of the high level requirements in the business modules described in section 3.1.1, several use-case models are created according to the target modeling practice of AM-RUP, as shown in Figure3. Figure 3. primary use case diagrams of social insurance business Business object modeling We decide to create business object models in order to get a better participation of clients into finishing business entities. Index cards and pens are used to create CRC models(each index card loads a CRC model)[6] during the modeling meeting, and the content of CRC can be altered in this way. Moreover, each CRC card can shift among all the cases of business modules, since most of the modules are deeply coupled because of many identical business objects. 181

3 Figure 4. some CRC cards in the social insurance system The CRC card in Figure4 describes the entities in the file creating: the creating operator, employee, retired employee, responsibility of enterprise (i.e. the necessary data and entity action) and other entities can help to finish the responsibility. As for the work of how these entities work with each other, it can be transferred to detailed analysis in the requirement modeling. In this way, we can get a clear understanding of the social insurance business through the discussion with clients Writing supplements of business specification In order to tackle the new emerging requirement in the future, a developing team does not need to create any model according to simplification principle of AM-RUP. So a simple product of changing case can be used to describe the potential requirements, as shown in Table1, which can be included in the supplement of business specification. Table1.Changing example of the social insurance system Figure4.use case diagram of individual insurance operations Determining business priority and making little incremental iteration plan Determining business priority and making little incremental iteration plans is the key steps in the practice of requirement modeling in AM-RUP. After all the little incremental iteration plans have been finished, all developers can focus on their responsible tiny business modules in order to implement simple modeling practice and improve the efficiency of software development. The determination rule of priority is based on the importance, stablibility, performance and cost of the business, as shown in Table2. According to the rule, there are 4 priorities existing in 8 social insurance sub-business. Table2-Priority classification Contents of changing cases are also the basis of making the iteration plan of developing. 4.2 Determining business priority and making little incremental iteration plan Dealing with new emerging requirement quickly The client suddenly put forward a special business for the individual insurance during our discussions of business priority, which can not be contained within the enterprise business, so we immediately created a simple use-case model for the individual insurance, as shown in Figure4. The positive attitude in dealing with new emerging requirement enables us to use simple models to communicate with clients, and initial agreements above on the new requirements are easily reached. This is the practice of Creating simple models and quick feedback in AM-RUP. Priority Description & business examples Key business which must be implemented first. Such as file creating, management of the insurance changing, application computing of treatment, management of payments and receivables, register and accounting of payments and receivables, individual insurance etc. Necessary business has the second importance and good stability. There can be delayed if necessary. Such as the dealing in the end of a year. Obscure Business need to be realized but not necessary, these will be delayed. Such as management of user authority. The enhancement of performance and quality, which will be advanced if all conditions can be satisfied. 182

4 The 8 sub-business will be divided into 3 phases according to the number of developers and business priority. In the same phase, target modules can be partitioned into different groups to develop; all groups must communicate with each other because of the connections among all modules. If new business emerged during the developing, the disposal method can be classified into two types: if it is the new business requirement in the same phase, then it will be iterated in the workflow in AM-RUP; if not, it will be transferred and audit in the next time of making iteration plan. In this way, the developing of current phase will not be affected and the new business requirements also get a suitable arrangement. 4.3 Requirement modeling of the social insurance system According to the little incremental iteration plans confirmed in Section 3.2, the first period of simple requirement modeling for all tiny sub-business modules can be started. We will take the individual insurance as an example to analyze the requirement modeling practice of AM-RUP Explore requirements of the individual insurance Because clients are also in the initialization phase in the individual insurance and are not clear with every potential business, a requirement acquiring method to lead the client and developers in a step-by-step way is needed. Thus, we introduce the SC-G technique according to the principle of using appropriate products. SC-G is a requirement acquiring method of mutual goal modeling and scene setting. The key structure of SC-G is the requirement chunk, which is denoted by<goal G, scene SC>[2]. There are 3 connection ways among all requirement chunks[3]: extracting relationship, composing relationship<and> and optional relationship<or>. Through the mutual discussions and the assistance of SC-G technique, 8 goals of the individual insurance system are confirmed. Here the GUI user interface of each goal can be drawn and the exploration task of uncertain business is also finished well. Figure 5.Modules of individual insurance requirements Detailed analysis of the requirement of individual insurance To clearly describe how to implement all the above 7 system interfaces in the individual insurance business, this paper selects the product modeling with robust diagram, as shown in Figure 6. Robust diagram can describe boundary/boundary objects(user interface elements), entity objects(the object in business field, such as the employee) and control/procedure objects[5]. The control objects are used to control the last two objects and their interaction logic. Robust diagram is simpler than the sequence diagram in UML and is not suitable for the modeling of complex logic; this is also accord with the selecting appropriate products practice of AM-RUP. Figure 6 shows that there are 9 control objects, 6 entity objects and 7 boundary objects needs to be created in the individual insurance business. These can probably be improved in a deeper and detailed analysis, if this happened, we can go back to the workflow and amend them. The creating simple contents and the iteration among workflows in AM-RUP enhance the adaptability of developers in tackling changes. In the aspect of interface requirement modeling, the information in the robust diagram can be iterated into the raw product of user interface, and this is the iterating to other products principle of AM practices. Using raw user interface models the developer can discuss with clients directly. Actually it is also an iteration technique, it can be not only used to analyze interface requirement, but also improve the convenience of requirement verification. 183

5 Figure 6.Robust diagram of individual insurance business 5. Conclusion This paper introduces a new requirement modeling process of AM-RUP. AM-RUP is a combination of the practice of AM and RUP. Some modules of a social insurance system are taken as a case to describe how to combine the requirement modeling technique of AM and RUP. The case can well illustrate the characteristic of AM-RUP requirement modeling: good adaptability of requirement content changing, quick feedback etc. AM is an efficient way to enhance the requirement modeling of RUP, and we are sure that more and more unified process software will be benefited from the extract of agile modeling. References [1] ScottWAmbler, Agile modeling: effective practice of extreme programming and unified process, Beijing mechanical industry press, [2] Liu Penghui, Agile method: new method of software engineering, Journal of Baojing art and science institute, vol23, No.4. [3] Dong Bin, Using requirement modeling technique to explore goals from scenes. Journal of Anhui agriculture university, 2004,31(1). [4]Yao Heng, Wei Zheng, Using agile developing method to prolong software lifetime, Times of Computer, Vol3, [5]Software Requirements, Second Edition by Karl E. Wiegers, Microsoft press [6]CRC Modeling: Bridging the communication gap between developers and users Scott W.Ambler