Best Practices of Software Engineering

1. Best Practices of Software Engineering

2. Objectives What we will learn: • Best Practices of Software Engineering

3. Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Ensures users are involved as requirements evolve Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally

4. Each iteration results in an executable release Develop Iteratively • Iterative development produces an executable 3. Requirements 4. Analysis & Design 2. Planning 1. Initial Planning 5. Implementation Management Environment (on-going) 6. Test 8. Evaluation 7. Deployment

5. Managing Requirements Ensures that you • solve the right problem • build the right system by taking a systematic approach to • eliciting • organizing • documenting • managing the changing requirements of a software application.

6. Use Component Architectures Software architecture needs to be:

7. Application- specific Business- specific Middleware System- software Purpose of a Component-Based Architecture • Basis for reuse • Component reuse • Architecture reuse • Basis for project management • Planning • Staffing • Delivery • Intellectual control • Manage complexity • Maintain integrity Component-based architecture with layers

8. SOA

9. Model Visually (UML) • Captures structure and behavior • Shows how system elements fit together • Keeps design and implementation consistent • Hides or exposes details as appropriate • Promotes unambiguous communication • The UML provides one language for all practitioners.

10. Static Diagrams Class Diagrams Use-Case Diagrams Object Diagrams Sequence Diagrams Component Diagrams Communication Diagrams Models Deployment Diagrams State Machine Diagrams Activity Diagrams Visual Modeling with the Unified Modeling Language • Multiple views • Precise syntax and semantics Dynamic Diagrams

11. Continuously Verify Quality Software problems are100 to 1000 times more costlyto find and repair after deployment • Cost to Repair Software • Cost of Lost Opportunities • Cost of Lost Customers Cost Inception Elaboration Construction Transition

12. Testing Dimensions of Quality Usability • Test application from the perspective of convenience to the end user. Functionality Reliability • Test that the application behaves consistently and predictably. • Test the accurate workings of each usage scenario. Supportability Performance • Test the ability to maintain and support the application under production use. • Test the online response under average and peak loading.

13. Configuration Management is more than just check-in and check-out Manage Change • To avoid confusion, have: • Secure workspaces for each developer • Automated integration/build management • Parallel development Workspace Management Process Integration Parallel Development Build Management

14. Manage Change (continued) • Unified Change Management (UCM) involves: • Management across the lifecycle • System • Project management • Activity-based management • Tasks • Defects • Enhancements • Progress tracking • Charts • Reports

15. Rational Unified Process Implements Best Practices Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change

16. Iterative approach Guidance for activities and artifacts Process focus on architecture Use cases that drive design and implementation Models that abstract the system Achieving Best Practices

17. A Team-Based Definition of Process A process defines Who is doing What, When, and How, in orderto reach a certain goal. New or changed requirements New or changed system Software Engineering Process

18. Inception Elaboration Construction Transition Process Structure - Lifecycle Phases The Rational Unified Process has four phases: • Inception – Define the scope of the project • Elaboration – Plan the project; specify features and baseline architecture • Construction – Build the product • Transition – Transition the product into the end-user community Time

19. In an iteration, you walk through all disciplines. Disciplines group activities logically. Bringing It All Together: The Iterative Approach

20. Iterative development and the unified process

21. Objectives What we will learn: • Define an iterative and adaptive process. • Define fundamental concepts in the Unified Process.

22. Unified Process • Iterative development is a skillful approach to software development, and lies at the heart of how OOA/D is presented • The Unified Process is an example iterative process for projects using OOA/D • In particular, the Rational Unified Process or RUP is a detailed refinement of the Unified Process • The UP is very flexible and open, and encourages including skillful practices from other iterative methods, • such as from Extreme Programming (XP), Scrum, and so forth

23. From sequential to iterative lifecycle R: requirements; D: design; C: coding, unit test; T: integration, test R D C T R R R D D D C C C T T T Time

24. Iterative Development • ID is the best practice using the UP to develop software • Development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities.

25. Iterations • Each iteration must result in production quality code. This implies that each iteration includes exhaustive testing! • The code may be incomplete (e.g., with stubs for functions identified but not yet implemented). • Note the contrast with rapid prototyping methodologies. • Early iterations should address high-risk parts of the system.

26. Example in a three-week iteration early in the project, perhaps one hour Monday morning is spent in a kickoff meeting with the team clarifying the tasks and goals of the iteration. Meanwhile, one person reverse-engineers the last iteration's code into UML diagrams (via a CASE tool), and prints and displays noteworthy diagrams. The team spends the remainder of Monday at whiteboards, working in pairs while agile modeling, sketching rough UML diagrams captured on digital cameras, and writing some pseudocode and design notes. The remaining days are spent on implementation, testing (unit, acceptance, usability, …), further design, integration, and daily builds of the partial system. Other activities include demonstrations and evaluations with stakeholders, and planning for the next iteration. We should avoid: • A rush to code • A long drawn-out design step that attempts to perfect all details of the design before programming.

27. Benefits of iterative development • less project failure, better productivity, and lower defect rates • early rather than late mitigation of high risks • early visible progress • early feedback • user engagement, and adaptation, leading to a refined system that more closely meets the real needs of the stakeholders • managed complexity • the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration

28. Agile Methods • Agile development methods usually apply timeboxed iterative and evolutionary development, employ adaptive planning, promote incremental delivery, and include other values and practices that encourage agility rapid and flexible response to change.

29. Agile Process Example

30. The Agile Principles ( Not in Details) • 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • 2. Welcome changing requirements, even late in development. • Agile processes harness change for the customer's competitive advantage. • 3. Deliver working software frequently, from a couple of weeks to a couple of months • 4. Business people and developers must work together daily throughout the project. • 5. Build projects around motivated individuals. • Give them the environment and support they need, and trust them to get the job done. • 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

31. The Agile Principles • 7. Working software is the primary measure of progress. • 8. Agile processes promote sustainable development. • 9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • 10. Continuous attention to technical excellence and good design enhances agility. • 11. Simplicity the art of maximizing the amount of work not done is essential. • 12. The best architectures, requirements, and designs emerge from self-organizing teams. • 13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

32. UP Best Practices and Concepts • tackle high-risk and high-value issues in early iterations • continuously engage users for evaluation, feedback, and requirements • build a cohesive, core architecture in early iterations • continuously verify quality; test early, often, and realistically • apply use cases • model software visually (with the UML) • carefully manage requirements • practice change request and configuration management

33. The UP Phases A UP project organizes the work and iterations across four major phases: • 1. Inception • approximate vision, business case, scope, vague estimates. • 2. Elaboration • refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more realistic estimates. • 3. Construction • iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. • 4. Transition • beta tests, deployment.

34. Schedule-oriented terms in the UP

35. Inception Inception Elaboration Construction Transition Purpose: • Establish some initial common vision for the objectives of the project, • Determine if it is feasible, and • Decide if it is worth some serious investigation in elaboration. • The good idea—specifying the end-product vision and its business case and defining the scope of the project • Concluded by the lifecycle objective (LCO) milestone

36. Inception phase • Lasts for one iteration • Is basically a feasibility study • Doesn't involve requirements analysis • Identify most important Use Cases • Write Vision • Write Business Case & Development Case

37. Objectives of the Inception Phase • Establish the project’s software scope and boundary conditions • Discriminate critical use cases of the system • Exhibit at least one candidate architecture • Estimate overall cost and schedule for entire project • Estimate risks

38. Activities of the Inception Phase • Formulate scope of project • Plan and prepare business case • Evaluate alternatives for risk management, staffing, project plan, and trade-offs between cost, schedule, and profitability • Synthesize candidate architecture • Evaluate trade-offs in design and assess make/buy/reuse decisions so that cost, schedule, and resources can be estimated

39. Outcome of the Inception Phase • Vision document • Use-case model survey • Initial project glossary • Initial business case • Business context • Success criteria • Financial forecast • Initial risk assessment • Project plan, which shows phases / iterations

40. Milestone: Lifecycle Objective Inception Elaboration Construction Transition Lifecycle Objective • Evaluation criteria for inception phase: • Stakeholder concurrence on scope definition and cost and schedule estimates • Requirements understanding – evidenced by fidelity of primary use cases • Credibility of cost and schedule estimates, priorities, risks, and development process • Depth / breadth of any architectural prototype • Actual expenditures versus planned expenditures

41. Rational Unified Process – Inception Time Phases Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Content Deployment Configuration & Change Management Project Management Environment Initial E # 1 E # 2 C # 1 C # 2 C # n T #1 T #2 Iterations

42. Elaboration Phase • Purpose: analyze problem domain, establish a sound architectural foundation, develop project plan, and eliminate project’s highest-risk elements • An executable architecture prototype built in one or more iterations • address critical use cases identified in inception phase – expose project’s major technical risks. Inception Elaboration Construction Transition

43. Elaboration phase • Multiple iterations • Mainly analysis • Flesh out Use Cases • Add more Use Cases • Supplemental specification • Glossary • Lots of customer involvement • Some design • Some implementation • Wide, rather than high, implementation

44. Objectives of the Elaboration Phase • Define, validate, and baseline the architecture as rapidly as practical • Baseline the vision • Baseline a high fidelity plan for the construction phase • Demonstrate that the baseline architecture will support this vision for a reasonable cost in a reasonable time

45. Activities of the Elaboration Phase • Vision is elaborated • A solid understanding is established of the most critical use cases • The process, infrastructure, and development environment are elaborated • The architecture is elaborated and the components are selected

46. Outcomes of the Elaboration Phase • A use-case model in which all use cases have been identified in the use-case model survey, all actors have been identified, and most use-case descriptions have been developed • Supplementary requirements that capture the nonfunctional requirements and any requirements that are not associated with the specific use case

47. Outcomes of the Elaboration Phase (continue) • A software architecture description • An executable architectural prototype • A revised risk list and a revised business case • A development plan for the overall project • An updated development case that specifies the process to be used • A preliminary user manual (optional)

48. Milestone: Lifecycle Architecture • Examine • detailed system objectives and scope • choice of architecture • resolution of major risks Inception Elaboration Construction Transition Lifecycle Architecture

49. Evaluation Criteria • Is the vision of the product stable? • Is the architecture stable? • Does the executable demonstration show that the major risk elements have been addressed and credibly resolved? • Is the construction phase plan sufficiently detailed and accurate? Is it backed up with a credible basis for the estimates? • Do all stakeholders agree: • current vision can be achieved if the current plan is executed to develop the complete system, in the context of the current architecture? • Is the actual resource expenditure versus planned expenditure acceptable?

50. Rational Unified Process – Elaboration Time Phases Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Content Deployment Configuration & Change Management Project Management Environment Initial E # 1 E # 2 C # 1 C # 2 C # n T #1 T #2 Iterations