Preface:
There are many kinds in the development of OOA / D, such as UP, XP, Scrum, DSDM, etc. Refactory of the previous iteration in each iteration. Previously I have seen the articles about OOA / D, the description of the development process, so that I have benefited from a lot, especially in practice. The authors found in a lot of application XP projects, there is currently no success case, just seeing many people claim that XP is being applied. The author's recommendation is to use a more lightweight UP method.
UP features: iterative development, Test Driven Develop, Pair Programing, etc. But how should I operate in practice? This is a UP build process to tell in this article. Always through Refactory and Iteration throughout the building, which is also the essence of UP. This is the application process in practice, of course, is not perfect, hoping to be more perfect in the discussion.
Figure A: Different stages of UP
S: indicates the beginning (START)
R represents optimization (REFINE)
Remarks: Each time ITERATION cycle should remain within 10 to 15 days, you must guarantee deadline. If you can't complete the plan on time, you can delete some requirements to ensure a relatively stable version on time. Two iterative gaps should be retained to fully discuss the REVIEW time to determine that the current phase also requires several iterations, and arranges the Plan (including Refactory) that is about to begin.
First, the demand analysis phase
Demand analysis stages of course are certainly inseparable from USE CASE. There is a USE Case Diagram in UML, which is not very high in the entire UP (this depends on the quantity of the use case and the quantity of the system and the system of the system), which is not important at least in the current phase. The use of Use Case DiaGram is a clear description: the association between USE CASE; the overall architecture of the system, there will be a detailed description. More importantly, Uses Case, which is a description of the text, is an analysis of the demand for the entire system.
1.1, Abstract USE Case Guidelines: (FURPS ):
1. Functional: Features, Ability, Security
2. USAbility: Artificial Factor, Help, Document
3. Reliability: failed frequency, recoverable ability, foreseeable capabilities
4. Performance: Response time, throughput, accuracy, practicality, resources
5. Supportability (support aspect): Adaptable, maintainable capabilities, configuration capabilities
Implementation, interface, operation, packaging
Writing Use Case To consider the above principles, of course, the face is impossible, don't forget that we have both the two weapons of Refactory and Iteration.
1.2, Basic Business Process (EBP: Elementary Business Process):
A Task Performed by One Person in One Place At One Time, In Response To a Business Event, WHICH Adds Measurable Business Value and Leaves The Data I Consistent State. User Case is a written written like the above description.
1.3, Users of Use Case:
Different USE Cases are for different users and often have crude and fine problems in practical applications. Use case is not universal, don't expect to make all things to clear through Use Case.
For example, in CRM applications, the customer manager of a company cares about how to improve response and customer satisfaction, improve sales, etc., for financial manager concerning the improvement of financial computerization, care for financial data Safety, etc .; how the IT manager is concerned about how to implement, the performance of hardware and software; only the general manager may care about the output ratio.
Therefore, the description of the needs of the above person is to be hierarchical, from the lower level:
The river is too detailed, and does not belong to the contents of use case, if there is a thread, socket, etc. in Use case, it is too detailed because it should appear after Domain Model. Therefore, USE Case only includes Sea Level and Fish Level. The general manager will only see Cloud Level and Kite Level. Party A CRM Implementation Group Personnel, Demand Analyst (SA), System Designer (SD), and Programr is the true user of Use case.
Never pay attention to the project is done in multiple Refactory and Iteration, it is impossible to complete the project during a construction process, otherwise it is not UP but Waterfall, the members of the project group will continue to be in the customer needs Change, technical risk, time risk is full of torture, the final product is necessarily true, the system architecture is confusing. I believe who can't forget the feelings of the Once I have moved!
1.3, a writing example of a USE CASE:
So much better, come slowly, next time we talk about Domain Model, you will continue!
