1. Four Major Software Development Methodologies  Object-oriented analysis and design developed in 1980s and 1990s  Structured analysis and design developed in late 1960s and 1970s  Functional decomposition and data-flow analysis as key modeling tools.  Use cases and the Unified Modeling Language (UML) as key modeling tools  Agile software development developed in late 1990s and 2000s  Popularity in the software industry as a “lightweight” way to develop software  Aspect-oriented software development developed in 2000s  not a replacement of the other methodologies; deal with scattered crosscutting concerns

2. Software Development: Risk  Many software projects fail because the software developers build the wrong software!  Understand what the client, the customer, and the users expect of the software  As a developer, provide technical insights and suggestions, but remember:  Client satisfaction and customer acceptance are the primary measures of success in a software project.

3. Software Development: Risk Most software development projects have major problems Problems Does not work as expected (FUNCTION) Over budget (COST) Late delivery (TIME) Much of software is wasted (perhaps 50% is never used ) Never used Does the wrong thing Users dislike to use it There are no customers

4. Software Development: Risk What is the penalty to the client if software is: late? over budget? does not work or full of bugs? Examples of risk: car anti-lock brakes (no bugs allowed) web browser in cell phone (no delays in release allowed )  Failures of software development projects can bankrupt companies

5. Software Development: Risk  Many software projects fail because the software developers build the wrong software! Understand what the client, the customer, and the users expect of the software As a developer, provide technical insights and suggestions, but remember:  Client satisfaction and customer acceptance are the primary measures of success in a software project.

6. Minimizing Risk: Short Development Cycle with Frequent Releases  Risk is minimized by short development cycles, with frequent delivery of working software (weeks rather than months).  Client, customers, and users can evaluate the developers' work.  Opportunities to adapt to changing circumstances. This is one of the basic principles of Agile Software Development.

7. Minimizing Risk: Visibility  The people who take the responsibility must know what is happening Managers Must rely on others for reports of progress or difficulties Software Developers Have difficulty evaluating progress Are often too optimistic Consider reporting a waste time etc.  Working software provides excellent visibility.

8. Teams  Most software development is by teams  Effectiveness of team determines success  Most large software projects are built on older ones  It is rare to start a new system from scratch  Building on the work of others is a fundamental skill of software development  Much software is built in increments (sprints), with different teams responsible for the increments

9. Software Process Fundamental Assumption: Good processes lead to good software Good processes reduce risk Good processes enhance visibility Systematic testing is an integral part of all p rocesses

10. Variety of Software Processes Software products are very varied... Therefore, there is no standard process for all software engineering projects BUT successful software development projects all need to address similar issues. This creates a number of process steps and testing steps that should be part of all software projects

11. Basic Process Steps in all Software Development Feasibility and planning Requirements System and program design Implementation Acceptance and release Operation and maintenance These steps may be repeated many times during the development cycle

12. Basic Testing Steps in all Software Development Testing the requirements Testing the system and program design Usability testing Testing the implementation Acceptance testing Bug fixing and maintenance All these steps will be repeated many times during the life of the system

13. Heavyweight and Lightweight Software Development  In a heavyweight process, the development team works through the entire development cycle slowly and systematically, with the aim of delivering a complete software product with minimal changes and revision. Example: the Modified Waterfall Model  In a lightweight process, the development team releases working software in small increments, and develops the plans incrementally, based on experience. Example: Agile Software Development

14. Process Step: Feasibility  A feasibility study precedes the decision to begin a project.  What is the scope of the proposed project?  Is the project technically feasible?  What are the projected benefits?  What are the costs, timetable? A feasibility study leads to a decision: go or no-go.

15. Process Step: Requirements  Requirements define the function of the system from the client's viewpoint. with the client, customers  The requirements establish the system's functionality, constraints and goals by consultation with the client, customers, and users.  The requirements may be developed in a self- contained study, or may emerge incrementally.

16. Process Step: System and Program Design  Design describes the system from the software developers' viewpoint  System design: Establish a system architecture that matches the requirements to hardware or software systems.  Program design: Represent the software functions in a form that can be transformed into one or more executable programs

17. Process Step: Implementation Implementation (coding) The software design is realized as a set of programs or program units. The software components may be wr itten specifically, acquired from elsewhere, or modified.

18. Process Step: Acceptance and Release Acceptance The system is tested against the requirements by the client, often with selected customers and users. Delivery and release The system is delivered to the client and released into production or marketed to customers.

19. Process Step: Operation and Maintenance Operation: The system is put into practical use. Maintenance: Errors and problems are identified and fixed. Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment. Phase out: The system is withdrawn from service. This is sometimes called the Software Life Cyc le

20. Testing User testing A preliminary version of the user interface is tested by users. Their experience may lead to changes in the requirements or the design. Program testing The development team tests components individually (unit testing) or in combination (system testing) to find bugs, etc. Acceptance testing The client tests the final version of the system or parts of the system against the requirements.

21. Sequence of Processes  Sequential: As far as possible, complete each process step before beginning the next. Waterfall model.  Iterative: Go quickly through all process steps to create a rough system, then repeat them to improve the system. Iterative refinement.  Incremental: An extension of iterative refinement in which small increments of software are placed in production (sprints). Agile development.

22. Waterfall Process Simplest process Sequential Basis for others 22

23. Sequential Development: The Waterfall Model Requirements System design Testing Operation & maintenance Program design Implementation (coding) Acceptance & release Requirements Design Implementation Feasibility study

24. Discussion of the Waterfall Model Advantages: Process visibility Separation of tasks Quality control at each step Cost monitoring at each step Disadvantages: Each stage in the process reveals new understanding of the previous stages, which often requires the earlier stages to be revised. The Waterfall Model is not enough!

25. Waterfall Model with Iteration Between Phases Structured Development Method Example

26. Modified Waterfall Model Requirements System design Testing Operation & maintenance Program design Implementation (coding) Acceptance & release Waterfall model with feedback This is better Feasibility study

27. Prototyping During Requirements Phase  When waterfall model is preferred, an important problem is that: “Software requirements are tested late in life cycle”  Solution The usage of throwaway prototyping  Ensure requirements are understood  First attempt at designing system  Design of key file and data structure  Design of user interface  Early design tradeoffs

28. Throwaway Prototying  Used to clarify user requirements.  Particularly useful for getting feedback on the user interface  Used for complex user interfaces  Developed after a preliminary requirements specification  After exercising the prototype, valuable feedback can be obtained  A revised requirements specification can be obtained.

29. Throwaway Prototyping on Software Life Cycle Hassan Gomaa H., Software Modeling and Design 2010 Structured Development Method Example

30. Throwaway Prototyping  An effective solution to the problem of specifying requirements for interactive information systems and for interactive manufacturing applications  Disadvantage is the communication barrier between the users and developers

31. Throwaway Prototyping in Design  Objectives Test design early Experiment with alternative design decisions  Examples of prototyping in design  Algorithm design Experiment with - speed, accuracy  Early performance analysis Measure timing parameters  User interface

32. Throwaway Prototyping on Architectural Design Phase Hassan Gomaa H., Software Modeling and Design 2010 Experimental prototyping of the design If certain algorthms are logically corect, this can be used. Structured Development Method Example

33. Evolutionary Development by Incremental Development Problem Operational system is available late in life cycle Solution Use incremental development Also known as evolutionary prototyping Objective Subset of system working early Gradually build on Prototype evolves into production system

34. Evolutionary Development by Incremental Development  Determines whether the system encounter its performance goals and critical components of the design in testing  Reduces the development risk by spreading the implementation over a longer time frame  Use cases and scenario-based communication diagrams can be used  Real time robot controller system is an example of evolutionary prototyping

35. Incremental Development Software Life Cycle Hassan Gomaa H., Software Modeling and Design 2010 Structured Development Method Example

36. Incremental Development Sprint 1 First release Sprint 2 Sprint 3 Second release Third release first presentationsecond presentationthird presentation

37. Discussion of Iterative Refinement Concept: Initial implementation for client and user evaluation, but not for release, followed by refinement until system is complete. User interface mock-up Throw-away software components Dummy modules Rapid prototyping Successive refinement

38. Iterative Processes: Requirements and Risk Mistakes in the requirements are the most expensive to correct. Requirements are hard to understand until there is an operational system, particularly with user interfaces Create an outline system quickly, review it with clients, test it with users, improve the understanding of the requirements Example: Start-up time of launching a complex application.

39. Incremental Development (Sprints): A simple system with basic functionality is brought quickly into production. Subsequent sprints are based on experience gained from users of each previous release. Advantages Pay-back on investment begins soon. Requirement are more clearly understood in developing subsequent sprints – minimize waste. User feedback can be incorporated in later phases. Challenge A high-level team must establish overall architecture and coordinate increments

40. Incremental Development of Online Systems  When software is released online it is possible to divide it into small increments that are developed and released in quick succession.  This approach is excellent for continual enhancement of a system within an established architecture.  It is not possible for shrink wrapped software, embedded systems, or similar environments.

41. Mixed Processes In practice, many large projects create a process that is suitable for the specific development. For example:  A system may use a sequential process with iteration within the individual process steps. This is sometimes called a spiral development process.  User interfaces have to be tested with users. This forces iterative development, even within an underlying sequential process.  A phase 1 system may be developed by iteration and used as requirements for a phase 2, which is developed sequentially.

42. Examples of Mixed Processes: Iterative Refinement + Waterfall Model: Problem: Add graphics package to a programming environment Phase 1: Iterative refinement Extend current environment with a preprocessor and run-time support package. Test with users. Make several new versions until users are pleased with function. Throw the code away. Phase 2: Modified waterfall Use the results of Phase 1 as the basis for a formal set of requirements. Write new compiler and run-time system incorporating graphics elements. Make minor adjustments to requirements as needed.

43. Corporate Processes Large software development organizations have their own internal processes that are designed for their needs. For example:  Amazon.com (Internet commerce) divides most software development into phases of about four weeks elapsed time.  Lockheed Martin (government contactor) follows a process that fits with the way that the US government manages software contracts.

44. Corporate Processes  SAP (business software) emphasizes the functionality that is seen by their business customers.  Microsoft (PC software) places great emphasis on testing with a very wide variety of equipment and backward compat ibility.

45. Modern Developments in Software Processes Changes during the software development process are expensive. If the requirements are poorly understood, or expected to change, select a process that keeps flexibility. Iterative refinement, sprints, phased implementation. For big software systems with many inter-related components, avoid major changes to the design of a system during development. Sequential process, such as the modified waterfall model. If the market for the software is poorly understood, use an incremental process that gets operational software in front of customers as quickly as possible.

46. Observations about Software Processes Completed projects should have the basic process steps but... the development process is always partly evolutionary. Risk is lowered by: Prototyping key components Frequent releases, dividing large projects into phases Early and repeated testing with users and customers. Following a visible software process Making use of reusable components

47. The Unified Process  In 1999, Booch, Jacobson, and Rumbaugh published a complete object-oriented analysis and design methodology that unified three separate methodologies (Booch’s method, Jacobson’s Objectory, Rumbaugh’s OMT- Object Modeling Tech. )  Original name: Rational Unified Process (RUP)  Next name: Unified Software Development Process (USDP)  Name used today: Unified Process (for brevity)

48. The Rational Unified Process  A modern process model derived from the work on the UML and associated process.  Normally described from 3 perspectives – A practice perspective that suggests good practice. – A dynamic perspective that shows phases over time; – A static perspective that shows process activities ;  It is a product sold by IBM (formerly Rational Software)  Supported by a large array of tools  Configurable  Regularly updated

49. Three Perspectives of RUP  Practice (Best) Perspective. A set of principles which are integrated into the process.  Dynamic Perspective: Phases, iterations, milestones of the process which change over time  Static Perspective The aspects of the process which are present in some form in all dynamic phases: activities, artifacts, roles, workflows.

50. Six Best Perspectives of RUP  Develop software iteratively  It reduces risk by having frequent releases that enable user involvement and feedback.  An iterative approach helps the development team stay focused on producing results and makes it easier to track progress and changes.  Manage requirements  Describes how to elicit, organize, and document requirements.  Use cases are developed to describe specific flows of events through the system

51. The Phases of the Unified Process The increments are identified as phases Object Oriented and Classical Soft.Eng., Schach S.R.

52. The Phases of the Unified Process  Although these phases are consecutive, each phase itself must have multiple iterations  Each iteration delivers some well defined output to an internal or external customer, phase’s milestone This output is often a part of the final deliverable of that phase’s milestone.

53. The RUP Model InceptionElaboration Iter1Iter2 Construction Iter1 Transition Phases Milestones Iter1Iter2 Iter3 Lifecycle Objectives Lifecycle Architecture Initial Operational Capability Product Release

54. Activity Level of Subprocesses in different phases of RUP Core Process Workflows

55. The RUP Model broken into multiple iterations  It is expected that the construction phase will be broken into multiple iterations  Each iteration produces a working system This system can be used for feedback, evaluation, beta- testing etc.  Iterations in construction are done often  It is clear what an iteration in this phase delivers.

56. Static Structure of RUP Answers four questions: who, what, how, when Four components Roles (or Workers): who. Defines the behavior and responsibilities of an individual or group. Roles participate in activities and are owners of artifacts. Artifacts: what. A piece of information produced, modified, or used by a process. Includes design documents, models, code, and executables. Activities: how. A unit of work assigned to a role. Usually expressed in terms of creating or updating some artifact. Workflows: when. A sequence of activities, involving one or more roles, producing an artifact.

57. Extreme Programming (XP) evolution of the traditional waterfal  In many ways RUP represents an evolution of the traditional waterfall approach to accommodate software-specific best practices. rather than design and documentation.  Extreme Programming (XP) and other so-called agile methods focus on code development rather than design and documentation. deliver working softw  They are intended to deliver working software quickly through many short iterative cycles.  They are revolutionary rather than evolutionary.

58. XP Development Cycle XP includes a number of suggested practices which are different from or new to the traditional model. Short cylcle (2 weeks) 1.Meet with clien 1.Meet with client to elicit requirements  User stories and acceptance tests 2.Planning game  Break stories into tasks, estimate cost  Client prioritizes stories to do first 3.Implementation  Write programmer tests  Simplest possible design  Refactor code often  Pair programming 4.Evaluate progress 4.Evaluate progress and repeat from step 1