CS 360 Lecture 3

 The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software processes lead to good software.  Good software processes reduce risks. 2

 Feasibility and planning  Requirements  System and program design  Implementation  Acceptance and release  Maintenance 3

 Feasibility and planning  Requirements  System and program design  Implementation  Acceptance and release  Maintenance  It is important to distinguish among these process steps and to be clear which you are doing at any given moment. 4 These steps may be repeated many times during the development cycle.

 Validating the requirements  Validating the system and program design  Usability testing  Program testing  Acceptance testing  Bug fixing, feature enhancements, and maintenance 5

 Validating the requirements  Validating the system and program design  Usability testing  Program testing  Acceptance testing  Bug fixing, feature enhancements, and maintenance 6 Some of these steps will be repeated many times during the life of the system.

 The term “testing” is used in several different contexts, which can be confusing:  User testing:  Versions of the user interface are tested by users and clients.  Their experience may lead to changes in the requirements or design.  Program testing:  The development team tests components individually (unit testing) or in combination (system testing) against the design to find bugs, etc.  Acceptance testing:  The client tests the final version of the system or parts of the system against the requirements. 7

 The feasibility study:  What is the scope of the proposed project?  Is the project technically feasible?  What are the projected benefits?  What are the costs?  Expected timeline?  What resources are needed?  What are the risks and how can they be managed? 8

 Requirements define the function of the system from the client’s viewpoint.  Requirements establish:  System functionality  Constraints  Goals 9

 The requirements step is divided into tasks:  Requirements analysis  Requirements definition  Requirements specification  The project’s requirements may be developed in a self-contained study, or developed incrementally.  Failure to agree on the requirements and define the adequately is one of the main causes of software projects failing. 10

 The requirements step is divided into tasks:  Requirements analysis  Meetings, documentation, process specifications, use cases, etc.  Requirements definition  Description of the services that the system should provide.  Requirements specification  Functional requirements  Inputs, behavior, outputs  Non-functional requirements  Criteria used to judge the operation of the system  Ex: accessibility, compliance, privacy, performance, reusability, stability, usability, etc.  The project’s requirements may be developed in a self-contained study, or developed incrementally.  Failure to agree on the requirements and define the adequately is one of the main causes of software projects failing. 11

 Design describes the system from the software developers’ viewpoint.  System design:  Establish a system architecture, both hardware and software, that matches requirements.  Program design:  Represent the software functions in a form that can be transformed into one or more executable programs.  Preliminary user testing can be carried out as part of the design step.  Models are used to represent requirements, system architecture, and programming design.  This course covers the basic concepts of the Unified Modeling Language (UML). 12

 Implementation (coding):  The software design is realized as a set of programs.  These software components may be written by the development team, or modified from existing components.  Program testing:  Individual components (unit testing) should be tested against the design documentation.  All components are integrated and tested against the design as a complete system (system testing). 13

 Acceptance testing:  The system is tested against the requirements by the client.  Can be done in weekly meetings, or after each milestone delivery.  Delivery:  After successful acceptance testing, the system is finally delivered to the client and released into production. 14

 Operation:  The system is moved from the developmental phase into practical use.  Maintenance:  Errors and problems are identified and fixed.  Evolution:  The system evolved over time as requirements change.  Add new functionality  Increased stability  Adapt to changing technical environment  Phase out:  The system is withdrawn from service.  This is generally called the Software Life Cycle. 15

 Every software project will include the previous basic processes, in some shape or form, but:  The steps may be formal or informal  The steps may be carried out in different order  Your job as the software development team is to implement, in as much detail as possible, the processes described in order to develop a good software product. 16

 In this course, we will look at three categories of software development processes:  Sequential:  As much 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 to improve the system.  Prototype, test, analyze, refine, repeat..  Iterative refinement, entire system  Incremental:  Variation of the iterative refinement in which small increments of software are placed in production (sprints).  Prototype, test, analyze, repeat..  Agile refinement, adding individual features during each phase. 17

 Deliverables:  A deliverable is some work product that is given to the client.  Each process step mentioned previously creates a deliverable.  Documentation, source code, etc.  For this course, the deliverables include:  Presentations  Software process documentation(s)  Software and/or hardware resources 18

 The basic process steps can be combined in many ways to create a successful software process for development.  Three types of software process:  Sequential ((modified) waterfall model), plan-driven  Iterative refinement  Incremental (agile) 20

 Plan-driven processes have all process activities described in advance and progress is measured against this plan.  Agile processes have incremental planning stages, where change can be accommodated more easily to reflect updated client requirements.  In practice, most approaches include elements of both plan- driven and agile development processes. 21

22

 The waterfall model requires full documentation at each process step.  Advantages:  Process visibility  Separation of tasks  Quality control at each step  Cost monitoring at each step  Disadvantages:  In practice, each process stage reveals new understanding of the previous stages.  Often requires earlier stages to be revised. 23

 A pure sequential model is impossible  Example:  A feasibility study can’t cerate a proposed budget and schedule without a study of the requirements and initial design.  Detailed design and implementation reveal gaps in the requirement specifications.  Requirements and/or technology may change during project development.  Solution:  Modified waterfall model 24

25

 Sequential processes work best when the requirements are well understood, and the design is straightforward.  Ex:  Conversions of existing manual data processing systems.  New models of a product based on earlier versions or similar products.  Parts of a larger system where components are clearly defined. 26

 Concept:  Create a prototype system early in the development process  Review the prototype with clients and test it with users  To improve the understanding of the requirements  Clarify the design  Requirements can be difficult to understand until there is an operational system.  Mistakes in the requirements are the most expensive to correct. 27

28

 Iterative processes require documentation refinement during each phase.  This type of software process enables the client to review the planned system early during development:  Software/hardware mock-ups  Sandbox modules  Rapid prototyping  Feature refinement  The goal is to get something working as quickly as possible, for client and user evaluation, but do not release it. 29

 The project is divided into a large number of small tasks, known as sprints.  For each sprint, the team works through a full software development cycle: planning, requirements, analysis, design, coding, testing, acceptance testing, and release.  Each spring is completed in a fixed time period, or milestone.  The size of a sprint is based on team size  4-7 people. 30

31

 Completed projects should have included all of the basic process steps, but the development process is always partly evolutionary.  Risks are lowered by:  Prototyping key components  Frequent releases, or dividing into phases  Early and repeated testing with users and clients  Making use of reusable components 32

33

34

35