DIN 108-55-1991 Slide projectors and slides straight cartridge 5 × 5-36 and 5 × 5-50 certification scheme《幻灯机和幻灯片 直式片盒5×5-36和5×5-50 鉴定程序》.pdf

《DIN 108-55-1991 Slide projectors and slides straight cartridge 5 × 5-36 and 5 × 5-50 certification scheme《幻灯机和幻灯片 直式片盒5×5-36和5×5-50 鉴定程序》.pdf》由会员分享，可在线阅读，更多相关《DIN 108-55-1991 Slide projectors and slides straight cartridge 5 × 5-36 and 5 × 5-50 certification scheme《幻灯机和幻灯片 直式片盒5×5-36和5×5-50 鉴定程序》.pdf（15页珍藏版）》请在麦多课文档分享上搜索。

1、 Pure Conference Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India; Tel: +91 120 4621080 Page 1 of 15 Agile Unified Process Siddharth Prabhudas United Health Group Unitech Cyber Park Sec-39, Gurgaon Haryana Siddharth_ Abstract Most software development is a chaotic activity, often character

2、ized by the phrase “code and fix“. The software is written without much of an underlying plan, and the design of the system is cobbled together from many short term decisions. This actually works pretty well as the system is small, but as the system grows it becomes increasingly difficult to add new

3、 features to the system. The original movement to try to change this introduced the notion of methodology. These methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient. They do this by developing a detailed

4、 process with a strong emphasis on planning inspired by other engineering disciplines. Engineering methodologies have been around for a long time, theyve not been noticeable for being terribly successful. Agile methodologies developed as a reaction to these methodologies. These new methods attempt a

5、 useful compromise between no process and too much process, providing just enough process to gain a reasonable payoff. The result of all of this is that agile methods have some significant changes in emphasis from engineering methods. The most immediate difference is that they are less document-orie

6、nted, usually emphasizing a smaller amount of documentation for a given task. Is tailoring required for implementation of Agile Methodology? The answer is YES. This article will emphasize on the best practices of Agile Methodology and Rational Unified Process in the name AGILE UNIFIED PROCESS. It sp

7、eaks about SCRUM A disciplined Management Methodology. It will also define a framework where AUP can be integrated with CMM and ISO. Keywords RUP: Rational Unified Process, AUP: Agile Unified Process, Usage model, Domain Model, Interface Model, ROI: Return on Investment, TDD: Test Driven Design, Re-

8、factoring, Acceptance Test, FLOOT :Full Lifecycle Object-Oriented Testing 1. Introduction Agile Unified Process is a simplified version of Rational Unified Process which takes the best practices of RUP and Agile Methodology. AUP is nothing but looking at RUP from an agile practitioners point of view

9、. RUP is considered to be a rigid artifact driven replacement for waterfall. But its software development processes and practices can be made flexible to fit into the right size of methodology of your project. Similarly Agile Pure Conference Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India

10、; Tel: +91 120 4621080 Page 2 of 15 Methodology is characterized by an emphasis on people, communication, working software, and responding to change, what it does not speaks about is documentation. So I am advocating for a middle line between RUP and Agile which can fit into any software engineering

11、 practices starting from product development to service oriented companies. 2. Business Model for AUP I am redefining the phases of RUP to fit into Agile Unified process 2.1 Inception: 1. Project Scope is established for a new project. 2. If it is an existing project then along with the new requirem

12、ent, all associated and existing defects are also studied as a part of the scope. 3. Requirements are prioritized and Requirement Stack is maintained. 4. Architectural vision is identified. 5. A high level estimation is made which includes modeling. 2.2 Elaboration: 1. Requirements are further analy

13、zed in detail level. This phase is very critical as we are concentrating on model. At this level we should do three kinds of modeling: Usage model to explore how users will work with your system, Domain Model which identifies fundamental business entity types and the relationships between them and I

14、nterface Model which speaks about the interaction of one system with other systems. 2. Initial Architecture Modeling is given importance here This is nothing but the effort to try to identify an architecture that has a good chance of working. 3. Use Case Model, Domain Model, Interface Model and init

15、ial architecture models takes better shape in further iterations but then the goal is not to freeze the documents but to give the team something so that they can start working. 4. Based on the detail requirement, estimation is also revisited. 5. As the picture shows, this is again a multi iteration

16、activity. 2.3 Construction: 1. Model storming should be encouraged. Its always advisable to model storm for several minutes and then code. Model storming requires very few audience but then the goal is to work towards solving the issues and come up with solutions. This is typically a Q N A session.

17、2. Model storming should be done using agile practices like Test Driven Design (TDD) and Re-factoring. This works because model storming helps you to think in cross functional and cross application perspective, test driven design helps you focus on a particular entity and re-factoring means you evol

18、ve your design through small steps to ensure that you deliver high quality work. Pure Conference Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India; Tel: +91 120 4621080 Page 3 of 15 3. Agile encourage detail modeling through executable specification and acceptance tests. Acceptance tests ca

19、n be considered as detail requirement and developer tests can be considered as detail design. Both when combined give the flexibility to the developer to document less. 4. Agile Unified Process speaks about model but then it does not speak how. It all depends upon the user to choose whether feature

20、driven or use case driven model or both is/are beneficial to them. 5. Testing and Development which forms the major part of this phase are not two separate activities, test and develop approach should be followed. Bugs from one iteration becomes the input to the next iteration and in terms a robust

21、architecture is formed. Testers and developers are part of the same team and should work towards a common goal. 6. Stake holders should also be part of this phase and should actively participate as a team. 7. There is a very close relation between Inception and Construction phase and artifacts produ

22、ced during these phases are dependent on the outputs of both the phases. 8. Depending on the need and based on the product back log we can go for number of iterations in the same phase. 2.4 Transition: This is nothing but a transition phase. Defects which could not be catered to in the current relea

23、se are passed on to future releases. One of the major activities of this phase is to sign off the artifacts so that they can be base lined for the future releases. Pure Conference Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India; Tel: +91 120 4621080 Page 4 of 15 Iteration 0 INCEPTIONIniti

24、al Requirement Envisioning for a new project Old Defect Analysis and New Requirement Study for an existing projectMultiple Iteraion ELABORATIONFunctional Requirement ClarificationArchitectural EnvisioningModellingArchitectural DocsModelling docsMultiple Iteraion CONSTRUCTIONDevelopment TestingTest S

25、cenarios/CasesThese docsare subjecttomodificationTRANSITIONUAT Testing N Shipment of the productSign off ArtefactsDefect AnalysisInitial EffortScope DocumentThis color shows the artifacts are WIP and are signed off in Construction phase.Business Model for AUPTest Result /Defect LogBugs Pure Confere

26、nce Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India; Tel: +91 120 4621080 Page 5 of 15 3.0 Best practices of AUP 1. Sign off Artifacts: Artifacts are not signed off till the Transition Phase. They get updated as and when required. 2. Need based Artifact: Produce Artifacts which are very mu

27、ch required for the success of the project. 3. Discuss Visualize and Write: If you are thinking of producing an artifact, first discuss then visualize and the last thing that you should do is to document. 4. Single Repository: Try to store all the artifacts in a single repository. 5. Requirement pri

28、oritization: The most important thing in agile world is to prioritize your requirements based on the ROI. 6. Stakeholder participation: Stakeholders should participate in each and every phase and in a timely manner. 7. Requirement Envisioning: At the beginning of the project, quality time needs to b

29、e invested in defining the scope of the project and to create the initial prioritized stack of requirements. If it is a new project, new and executable requirements will be studied and if it is an existing project, a good amount of time should be invested in studying the existing defects/issues rela

30、ted to the scope requirement which becomes the part of the final scope. 8. Executable specifications: Specifications should be written in executable form so that design and coding can be carried out effectively. 9. Model Storming: In iterations, its advisable to do little bit of model storming for f

31、ew minutes to explore the details behind a requirement or to think through a design issue. 10. Model in advance: Plan your modeling. If a complex requirement is popping up in the priority queue, then model for that requirement in the previous iteration. 11. Multiple Models: Nobody is perfect; each a

32、nd every model has its own advantages and disadvantages. So developers should be provided with a wide range of models to choose from, so that they can effectively utilize those models at right time and at right place. 12. Effective Communication: There is no hierarchy maintained for communication. S

33、takeholders, developers, analysts, testers and management working on a project are part of the team. So anybody can reach out to anyone to get clarification. 13. Accept Change: Change is always inevitable and should be acceptable in the software world. Multiple iterations, multiple modeling and abov

34、e all little bit of planning in terms of effort also justify for accepting change in requirement. 4.0 AUP Software Development (How it works) Agility is the ability to both create and respond to change in order to profit in a turbulent business environment. Agile software development is an approach

35、to software development that is people oriented, that enables people to respond effectively to change Pure Conference Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India; Tel: +91 120 4621080 Page 6 of 15 and that result in the creation of working systems that meets the needs of its stakehold

36、ers. I would like to iterate AUP Software Development is not: “Code and fix” An excuse not to document An excuse not to model An excuse to short-change quality An excuse to ignore enterprise concerns Agile Software Development Values Individuals and interactions Working software Customer Collaborati

37、on Respond to Change Over Processes and tools Comprehensive documentation Contract negotiation Following a plan When I am talking so much about AUP I should define its Principles: 1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2 Welcome

38、changing requirements, even late in development. Agile processes harness change for the customers competitive advantage. 3 Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4 Build projects around motivated individuals. Give

39、 them the environment and support they need, and trust them to get the job done. 5 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 6 Agile processes promote sustainable development. The sponsors, developers, and users sh

40、ould be able to maintain a constant pace indefinitely. 7 Simplicity-the art of maximizing the amount of work not done-is essential. 8 The best architectures, requirements, and designs emerge from self-organizing teams. 5.0 AUP Software Development Methods There are two basic agile software developme

41、nt methodologies. One is XP and the other is Scrum. For AUP, I will say Scrum will be the best methodology. Scrum is one of the AUP methods for project management. It has been called a “hyper-productivity tool“, and has been documented to dramatically improve productivity in teams previously paralyz

42、ed by heavier methodologies. Its intended use is for the management of software Pure Conference Solution Pvt Ltd., A-108B, Sector 58, NOIDA 201301, India; Tel: +91 120 4621080 Page 7 of 15 development projects, and it has been successfully used to “wrap“ Extreme Programming and other development me

43、thodologies. However, it can theoretically be applied to any context where a group of people need to work together to achieve a common goal - such as setting up a small school, scientific research projects or planning a wedding. 5.1 Best practices of Scrum 1. Customer is always a part of the develop

44、ment team. 2. Frequent intermediate deliveries with a working functionality are MUST. 3. Frequent mitigation and risk plans are being developed by the DEVELOPMENT TEAM. 4. Daily status discussion with the team is DONE on a daily basis. 5. Things included in the daily discussion are: a. What did you

45、do from yesterday? b. What are you planning to do tomorrow? c. Do you have any problems? 6. Transparency is ALWAYS there in planning and different modules. 7. If a feature has a problem, no delivery shall take place. 8. A frequent stakeholder meeting, to see the progress, is a MUST. 9. No problems a

46、re buried under the carpet. No one is penalized for a problem. 10. Energized workplace and working hours is a MUST. “More number of hours“ does not mean more “output.“ I will not be taking much time in introducing the audience about how sprint works because it depends upon the flexibility of the aud

47、ience as to how they want to make it work. However, I would like to make the user aware of Project Execution using AUP: 1. Create the Product Backlog Product owner creates the product Backlog by prioritizing the organizational values. 2. Create a Release Backlog It is selected by team at outset of S

48、print which keeps on changing during Sprint as information is discovered. 3. Plan the 30-day sprint with a Sprint Planning Meeting. 4. Create the Sprint goal and the Sprint Backlog This is generally done during the Sprint planning meeting. 5. Manage the daily sprints through the Daily Scrum and Spri

49、nt Burn down Charts. 6. Remove Impediments. 7. Deliver Product increment. 8. Review product increment as part of Sprint Review meeting. 9. Update the Product Backlog. Since you are now introduced to the scrum process, you can better understand how the requirement can be managed through Scrum Whenever a new requirement comes or the p