Software Process Models - Lecture Slides | CMSC 132, Study notes of Computer Science

Download Software Process Models - Lecture Slides | CMSC 132 and more Study notes Computer Science in PDF only on Docsity! 1 CMSC 132: Object-Oriented Programming II Software Process Models Department of Computer Science University of Maryland, College Park Overview Software process models Waterfall Iterative Choosing a software process model Level of understanding Cost of change 2 Software Process Models Software methodology Codified set of practices Repeatable process for producing quality software Software process model Methodology for organizing software life cycle Major approaches Waterfall model Iterative development Formal methods Waterfall Model Approach Perform steps in order Begin new step only when previous step is complete Result of each step flow into next step 5 Unified Software Life Cycle Model Agile Software Development Agile approach Based on iterative development Short iterations (timeboxes) lasting 1- 4 weeks Working software as principal measure of progress Produced at end of each iteration Adds a more people-centric viewpoint Face-to-face communication preferred Co-locate programmers, testers, “customers” Relies on adapting to feedback rather than planning as the primary control mechanism Less specification & documentation 6 Extreme Programming (XP) Prominent example of Agile methodology Iterative, adaptive software development Describes set of day-to-day practices Followed by managers & programmers Intended to encourage a set of values Appropriate for environments with Small teams Rapidly-changing requirements Extreme Programming Values Communication Rapidly building & disseminating institutional knowledge among programming team Simplicity Implement simplest code needed by customer without emphasis on future versions Feedback From testing, team members, customers Courage Willingness to rewrite / refactor software to add or change features 7 Extreme Programming Practices Pair programming Pairs of programmers combine software development efforts at one computer Especially useful for novice programmers Test-driven development Tests are designed first, before writing software Continuous integration Tests performed throughout development process On-site customer Customer available at all times to answer questions Formal Methods Mathematically-based techniques for Specification, development, and verification Software and hardware systems Intended for high-integrity systems Safety Security Levels 0 – Informal implementation of formal specifications 1 – Formal code development & verification 2 – Theorem prover to ensure correctness 10 Sometimes, Change Is Still Expensive Expensive to change software that Is key nexus in a large system Affects many lines of code Interacts with co-designed hardware May need to change hardware design Interacts with software being developed externally Can’t easily change API once published How Many People Interact With Its Design? People interacting with software design Part of the cost of change Need to alert / consult people on design change Design changes that interact with a lot of people Expensive and need to be minimized Try to get design choices right early and documented 11 How Easy Is Software To Understand? When building and developing software, you need to understand it (at least, parts of it) For 100 lines of code, just read the code Doesn’t work for 100,000 lines of code Need to have ways of documenting the requirements & design at a higher level