1. Systems Design Approaches The Waterfall vs. Iterative Methodologies

2. Traditional Systems Development Lifecycle (“The Waterfall Model”) Planning

3. Planning Analysis

4. Planning Analysis LogicalDesign

5. Planning Analysis LogicalDesign PhysicalDesign

6. Planning Analysis LogicalDesign PhysicalDesign Implementation

7. Database Development Process Planning Analysis LogicalDesign PhysicalDesign Implementation enterprise data model

8. Database Development Process Planning Analysis LogicalDesign PhysicalDesign Implementation enterprise data model conceptual data model

9. Database Development Process Planning Analysis LogicalDesign PhysicalDesign Implementation enterprise data model conceptual data model logical data model

10. Database Development Process Planning Analysis LogicalDesign PhysicalDesign Implementation enterprise data model conceptual data model logical data model technologymodel

11. Database Development Process Planning Analysis LogicalDesign PhysicalDesign Implementation enterprise data model conceptual data model logical data model technologymodel databases and repositories

12. Rational Unified Process 

13. Why do so many projects fail? Characteristics of failed projects – Inaccurate understanding of end-user needs – Inability to deal with changing environments – Late discovery of serious project flaws – Poor software quality – Modules that do not fit together – Unacceptable software performance These are just symptoms of deeper underlying problems

14. Root Causes for Project Failure Ad hoc requirements management Ambiguous and imprecise communication Overwhelming complexity Insufficient testing Subjective assessment of project status Uncontrolled change propagation Insufficient automation

15. Software Development: Best Practices 1.Develop software iteratively 2.Manage requirements 3.Use component-based architectures 4.Visually model software 5.Continuously verify software quality 6.Control changes to software

16. 1. Develop Software Iteratively Planning Analysis Logical Design Physical Design Implementation The “classic” waterfall lifecycle

17. 1. Develop Software Iteratively Planning Analysis Logical Design Physical Design Implementation Risk Time Risk pushed forward in time

18. Iterative Approach Planning Requirements Analysis and Design Implementation Deployment Test Evaluation Initial Planning -continuous discovery and implementation --each iteration results in an executable

19. Advantages of the iterative process Misunderstandings made evident early Encourages user feedback Continuous testing allows objective status assessment Inconsistencies between analysis, design, and implementation detected early Workload spread evenly (especially testing)

20. 2. Manage Requirements Requirements are conditions or capabilities that a system must meet Requirements of a system are dynamic Identifying a system’s requirements is a continuous process Impossible to exhaustively state a systems requirements before start of development Managing requirements involves – Eliciting, organizing, documenting requirements – Evaluating changes to requirements – Tracking and documenting trade-offs and decisions

21. 3. Use Component-based architecture Many people are involved in the development of a system – End users, analysts, developers, testers, technical writers, project managers… Each stakeholder views the system in a different way during the course of a project System architecture allows management of views Architecture covers structure and behavior of software elements, usage, functionality, performance, reuse, aesthetics, etc.

22. Component-based development (CBD) Allows reuse and customization of components from thousands of available sources Can use new, existing, or third-party components and strap them together to achieve desired functionality In an iterative approach, each cycle produces an executable architecture – Can be measured, tested, evaluated against requirements – Allows developers to attack risks continuously

23. Advantages of CBD architectures Components facilitate strong and flexible architectures Modularity enables separation of elements that are subject to change Components provide a natural basis for configuration management Visual modeling tools can be used for automation

24. 4. Visually Model Software A model is a simplification of reality that describes system from specific perspective Models help teams visualize, specify, construct, and document system Improves ability to manage system complexity Communication is improved through the use of a common modeling language (such as UML)

25. Viewing a system from different perspectives Model Scenario Diagrams State Diagrams Deployment Diagrams Component Diagrams Use Case Diagrams Class Diagrams

26. Advantages of Visual Modeling Use-cases and scenarios clearly specify system behavior Inflexible architectures quickly exposed Detail can be hidden when necessary Unambiguous designs show inconsistencies easily Visual Modeling tools support UML

27. 5. Continuously verify software quality Cost Time Software problems can be thousands of times more expensive to find and repair after deployment than if discovered earlier in the project - Software problems can be thousands of times more expensive to find and repair after deployment than if discovered earlier in the project

28. Testing and Quality Testing involves – Creating tests for systems key scenarios – Assessing functionality by asking which scenarios failed – Testing at every iteration, continuously improving quality

29. 6. Control Changes to Software Complex systems typically involve – Multiple developers – Multiple teams – Multiple sites – Multiple releases, platforms, and products Can quickly degenerate into chaos

30. To control changes… Must establish repeatable workflow for managing changes A tested baseline is released at the end of every iteration By developing iteratively, the process of change control is continuous and traceable

31. Advantages of Formal Change Control Change requests facilitate unambiguous communication Change rate statistics are good metric for project status Change propagation is controlled All outputs are in a single location – provides for consistency

32. So…..

33. Guide the order of a team’s activities Specify which artifacts (deliverables) must be produced and when they must be produced Direct activities of both individuals and teams Monitor and measure project activities Any software development process must:

34. The Rational Unified Process  - software development process that attempts to ensure quality systems developed in a repeatable and predictable way

35. RUP

36. What is RUP? The Rational Unified Model is a software engineering process Both process and product Provides a common project knowledge base that may be accessed by team members – Ensures consistency of communication – Commonality of project vision – Enhances productivity Focuses on the development and maintenance of models Reflect the best practices of software development

37. Software Development: Best Practices 1.Develop software iteratively 2.Manage requirements 3.Use component-based architectures 4.Visually model software 5.Continuously verify software quality 6.Control changes to software

38. RUP

39. Agile Development Click slide title for the video