Relationship to Textbook

• This lecture is based on material in the first part of Chapter 2 of the Jalote textbook

But first…

• The model-based approach to software development can be both useful and powerful
• BUT
• It may not be easy!
  • Models are mathematical in nature and may require specialized training to develop and maintain
  • Depending on the behavior being modeled, specialized knowledge from other domains may be required to create the model
  • By analogy: consider an engineer that would like to model a heating/cooling system for a house
    • Needs to model physical layout
    • Needs to model placement of vents and air returns
    • Needs to model strength of furnace
    • Needs to model air flow through house
    • May need to model furniture, rooms with lots of windows, etc.
    • All to answer the question will this system efficiently heat and cool its associated house
  • In software development, we will focus on modeling some aspect of a program's run-time behavior and will have to deal with (potentially)
    • non-determinism
    • large state spaces
    • partially understood requirements
    • hard to quantify attributes, such as robustness

Software Process

• A process is distinct from the product it produces: a product is the outcome of executing a process in a software development project
• As mentioned earlier, software engineering focuses on process, to help transform software development into an engineering discipline
• Premise: A proper process will help achieve a project's objectives of achieving high quality and productivity

Process, continued

• Process: a series of actions or steps taken in order to achieve a particular end
• Software Process: An ordered set of steps to produce a high quality software system

Since there are many different activities that occur during a software development project, it is better to think of a software process as being composed of sub-processes or component software processes. Each of these processes may be performed by different people playing different roles.

Software Process at a high-level

• For any software development project, there are two main component processes
  • Product Engineering Process: Charged with creating the software system
  • Process Management Process: Charged with monitoring the other processes and improving them over time
• The product engineering process can then be broken down into several other processes, including
  • Development Process: Specifies the order of development activities and the products produced by each step
  • Project Management Process: Charged with planning and controlling the development process
  • Software Configuration Management Process: Charged with managing the evolution of software artifacts
  • Requirements Change Management Process: Charged with handling change during the development process
  • Inspection Process: Charged with specifying the steps to inspect artifacts created during development
  • …
• These processes and their relationships are shown below:
  
• Different people with different roles will collaborate to perform these processes
  • Managers will work on the project management process
  • Designers, developers, and testers will work on the development process, the change process, and the inspection process
  • Build managers (configuration controllers) will work on configuration management

Process Specification

• A process is a set of steps
• Each step takes a set of inputs and produces a set of outputs (generically called work products)
  • Each output should be a formal and tangible artifact that can be verified in some fashion
• Each step might employ a different set of methodologies designed for that particular stage in the process
• One approach to process specification is known as ETVX (Entry Criteria, Task, Verification and eXit criteria)
  • Entry Criteria: what conditions must be satisfied before initiating this step
  • Task: what work is to be performed during this step
  • Verification: what checks must be performed on the outputs of this step
  • Exit Criteria: what conditions must be satisfied before this step is over
  • In addition, each step must specify what information is generated for management during this step. This information should provide visibility into the state of the process such that management can take suitable actions, when necessary, to keep the process under control
• Visually, a step in the ETVX approach looks like this:
  

Desired Characteristics of Software Process

• Predictability
• Support Testability and Maintainability
• Support Change
• Support Early Defect Removal
• Support Feedback and Process Improvement

Predictability

• We want our software processes to produce predictable results
• Predictable processes are important since they aid in the task of making estimates for new projects
  • The last 5 projects of this size and scope, using this process, cost approximately $1.5M USD. Thus we predict that this current project will cost the same.
• Predictable processes are also important to help us gauge the acceptability of various quality attributes
  • Imagine a project which discovers 10 errors per 100 LOC during testing
  • Is this acceptable?
  • If previous projects using this process had a similar error rate, then yes, otherwise no
• Predictable processes are said to be under statistical control. A process is under statistical control if following the same process produces similar results—results will have some variation due to random causes not process issues
  

Support Testability and Maintainability

• A software process needs to produce testable and maintainable code because
  • development projects spend a significant amount of time in the testing phase
  • most of the costs associated with a software system occur after a system is deployed and is in active use
• As a result, the focus in early development should be can this software be easily tested and can this software be easily modified
• To back this up, (since most people don't think of testing and maintenance as being more important than coding) Jalote cites studies that show in a typical software development project, effort in the initial development phase is split like this:

  Requirements	10%
  Design	10%
  Implementation	30%
  Testing	50%

• Indeed, Fred Brooks in The Mythical Man-Month says that few [projects] planned on spending 50% of their time on testing, but most spent 50% of their time on testing and that most of these projects were on schedule when testing began!
• Furthermore, Jalote sites two studies, one by Bell Labs that determined that their programmers spent only 13% of their time coding, and one by Barry Boehm that found that developers spent less than 20% of their work time programing.
• As a result, software engineers need to avoid placing undue importance on the implementation phase and think about what they can do to lower costs in the testing and maintenance steps of their software development process

Support Change

• A software process needs to be able to respond to a change in a system's requirements
• Software systems model the application domains of the organizations that use them
  • If an organization's application domain undergoes rapid change (common in business environments), the software supporting that organization must also change
• As a result, software processes must have features that allow them to embrace change as a natural part of software development. Processes that encourage iterative development are better suited to handling change, since change requests can be received and scheduled for subsequent development cycles.

Support Early Defect Removal

• The greater the delay in detecting an error after it occurs in a software development process, the more expensive it is to correct it
  
• The increase in cost is associated with re-work. How much of the existing software artifacts need to be changed in order to correct the error?
  • If you find an error in the requirements document during the requirements phase, then the cost to fix the bug is small... simply change the requirements document
  • But, if you find an error in the requirements document during the testing phase, then the cost to fix the bug is large because after you change the requirements document, you must update the design document, then the code, and then the test cases!
• It is for this reason that the ETVX model specifies that each step in a software process has a verification step that looks for bugs in the artifacts produced by that step
• This is also why process improvement is important, if it can be determined that a particular step of a software process introduced a lot of defects into the system, then that step should be changed for future projects. This type of activity is sometimes viewed as defect prevention.

Support Feedback and Process Improvement

• No process is going to be perfect. And it should not be expected that a process used by one organization can be transferred to another organization without modification
• As a result, a process should provide mechanisms for obtaining feedback about its various steps, as well as be open to change in order to improve the process based on that feedback
• Improving the quality and reducing the cost of products is fundamental to any engineering discipline
  • Since the productivity (hence cost) and quality of a project is determined by its process, software engineers much improve the process in order to achieve these goals of quality improvement and cost reduction
• As a result, an organization must provide its workers with a mechanism for supplying feedback about the processes that it uses; this feedback must flow to people charged with making changes to the official processes and distributing those changes in a manner such that they are adopted by subsequent projects
  • This means that the organization needs to have a culture in which the employees actually follow the organization's specified processes

Development Process

• As mentioned above, a set of ordered development activities that produces a sequence of artifacts culminating in a delivered software system (code+docs)
• Why have multiple steps?
  • To allow engineers to apply the divide and conquer strategy of solving problems
    • Each step solves a different part of the problem
  • To allow for continuous testing (validation and verification)
• Commonly has these activities
  • Requirements Analysis
  • Design
  • Implementation
  • Testing
  • Deployment
  • Maintenance

Requirements Analysis

• To understand the problem domain and to state the problem precisely
• Produces a requirements document that serves as a basis of agreement between clients and developers
  • Specifies WHAT a system needs to do, not HOW it does it
• Not an easy task, as application domains are often complex, developers are not experts, and clients (who are the experts) often don't know what they want out of a software sytem

Design

• Create a solution to the problem defined by the requirements
  • The design of the system specifies HOW a system will meet the needs identified in the requirements
• Three main tasks
  • Architecture Design — What is the overall structure of the system, what are its main components and connectors?
  • High-Level Design — What modules and data structures are needed to implement the architecture
  • Low-Level Design — What are the interfaces of the identified modules, what algorithms should be used to implement the desired functionality
• Most methodologies focus on the first two tasks; the output of this phase is a design document that specifies the results of each of these tasks

Implementation

• Map the design into an implementation in one or more programming languages
• Goal: Implement the design with well structured, easy-to-understand code
• Output: the set of source files that implements the design

Testing

• Testing is required since defects can be introduced into the system by each of the previous steps
• Not a distinct step but a phase that should be present in all of the previous steps
• Outputs are test plans and the results of applying the developed tests

Common Software Development Processes

• Waterfall Model — the oldest model and the one most widely used
• Prototyping
• Iterative — also widely used, especially in Agile Methods
• Timeboxing

Waterfall Model

• Linear sequence of stages/phases
  • Requirements – HLD – DD – Code – Test – Deploy
• 
• In the strictest application of this process, a phase starts only when the previous phase has completed; there is no feedback to earlier phases
  • There are multiple variations of the waterfall model, many which are not this strict and allows returning to earlier phases to respond to feedback from subsequent phases

Waterfall Advantages

• Conceptually simple, cleanly divides the problem into distinct phases that can be performed independently
• Natural approach to problem solving
• Easy to administer in a contractual setting — each phase is a milestone

Waterfall disadvantages

• Assumes that requirements can be specified and frozen early
• May force hardware and other technology choices too early in the development phase
• Follows the “big bang” approach – all or nothing delivery; too risky
• Very document oriented, requiring documents at the end of each phase

Prototyping

• Prototyping addresses the requirement specification limitation of the waterfall model
• Instead of freezing requirements only by discussions, a prototype is built to understand the requirements
• Helps to alleviate the risk of not understanding the requirements early in a development project
• A small waterfall model replaces the requirements stage
  

Development of Prototype

• Starts with initial requirements
• Only key features which need better understanding are included in prototype
• No point in including those features that are well understood
• Feedback from users taken to improve the understanding of the requirements
• Critical Need: users must be educated that what they are seeing is ONLY a prototype
  • Users must understand that the prototype is going to be thrown away
  • Otherwise, they will wonder why the development process is taking so long!

Managing Costs

• Costs can be kept low by only building features needing clarification
• Team can make use of rapid application development tools, scripting, etc.
• Quality of prototype is not important, understanding user requirements is more important
• Knowledge gained building prototype will be useful in design and implementation

Iterative Development

• Counters the “all or nothing” drawback of the waterfall model
• Combines benefit of prototyping and waterfall
• Develop and deliver software in increments
• Each increment is complete in itself
• Can be viewed as a sequence of waterfalls
• Feedback from one iteration is used in future iterations

• After an initial requirements phase, a project control list is created that lists the features of the desired system
• A set of features is selected for the first iteration and the developers design, code, and test an implementation of those features.
• The result is then analyzed and the project control list is updated.
• Repeat until project control list is empty
• Note: the time of each iteration may vary depending on the number of features selected for that iteration.

Spiral Model

• An alternative iterative development model based on risks
• 
• Each cycle in the spiral begins with the identification of objectives for that cycle
• The different alternatives for achieving those objectives are considered and constraints are identified
• Next, the risks facing the project at this stage are evaluated
• Next, activities are performed to resolve uncertainties and reduce risk (including changing the objectives)
• Next, software is developed and tested, keeping in mind the identified risks and avoiding them, if possible
• Finally, the last step consists of planning for the next loop of the spiral

Timeboxing

• The iterative process model employs a linear sequence of iterations
• Each iteration is a mini-waterfall process — select features, design, code, test, deploy
  • It is assumed that the same team performs all of these different sub-steps
• The timeboxing model of development attempts to make iterative development amenable to parallelism.
  • The basic unit of development is a time box, which is of fixed duration
  • This means that the team must be careful to always select a set of features that can be built within the specified duration
  • Timeboxing changes the perspective of development and makes the schedule a non-negotiable and high-priority commitment
    • Completion time is fixed, the functionality actually delivered is flexible
  • Each time box is divided into a sequence of steps. Each step performs a clearly defined task.
  • Each step has a dedicated team, that team will perform that step for each time box!
    • If you did design work for time box 1, you'll be doing design work for time box 2, …
  • With this set-up, you can now apply pipelining of the different iterations!

Timeboxing Illustrated

• In the figures below, we have three stages within a single time box
• 
• 
• If a time box takes T days to complete, then the first iteration finishes at time T
• The second iteration finishes at T + T/3, the third at T + 2(T/3), etc.
• In steady state, there is a delivery every T/3 days
• If T is 3 weeks, then the first delivery of the software is at 3 weeks, the 2nd delivery at 4 weeks, the 3rd delivery at 5 weeks, etc.
• Contrast with linear iterations, delivery times would be 3 weeks, 6 weeks, 9 weeks, etc.

Implications

• Duration of each iteration is the same
• Total work performed in an iteration is the same
• BUT, average delivery time has been reduced by a third! (assuming teams can finish their work for each step on time!)

Team Size

• The timeboxing method has an impact on development team size
• In the iterative method, the same team performs all steps
• If each stage has a team of S, in the iterative method the team size is S
• In pipelined execution, the team size is N * S, where N is the number of steps per timebox
• Thus, total team size in timeboxing is larger but this reduces the cycle time

Advantages and Disadvantages

• Advantages
  • Shortened delivery times
  • Plus all the benefits of iterative development
• Disadvantages
  • Larger teams (increased costs)
  • Project management is harder
  • High Synchronization is needed (can be difficult to achieve)
  • Configuration management is harder

Summary

• Software Process is a means for producing high quality software systems with high productivity
• A software process has many sub-processes performed by multiple people playing different roles
• Many different types of development processes have been proposed
  • with different strengths and weaknesses
  • one model will not necessarily be suitable for every organization

Summary of Development Processes

Coming Up Next

• Lecture 5: Processes and Threads
• Lecture 6: Software Process: Part 2