1. Teaching slides
Chapter 1

2. Chapter 1: software engineering
Contents
- No software engineering methodology
Waterfall software engineering methodology
Rational unified process (RUP) software engineering methodology
Agile software engineering methodology
Extreme programming software engineering methodology
Scrum software engineering methodology

3. Chapter 1: software engineering
No software engineering methodology
Without knowledge and experience, it is difficult to do many jobs. Designing and creating a software product requires specialized skills and experience. In early days of computers, not many people had skills and experience to build software products. This used to result in software project failures.
Example of a process flow to find out tasks and effort and cost estimate involved for a paint job is depicted in the figure given on next slide. The paint job planning here is nothing but example of a project planning. A project planning involves applying methodology (knowledge and experience) to accomplish a job.

4. Chapter 1: software engineering
No software engineering methodology
Find size of house
Find wall area
If windows & doors need paint
Find color of paint
Find effort required
Find material cost
Find out effort cost
Find total time for paint job
Find total cost for paint job

5. Chapter 1: software engineering
Waterfall software engineering methodology
Waterfall software engineering methodology is one of the earliest software engineering methodologies developed for software projects. Waterfall model is based on creating a solid project planning. That is why it is also known as plan driven software engineering methodology. Since a project plan provides good visibility across the entire project; things for project tasks can be planned well in advance. The drawback of this model is that project planning for most software projects is difficult. For example; how much effort is required to create a particular software design may not be easy for the project team. Thus even after putting good effort in creating a project plan; project execution will face lot of problems. One more problem on Waterfall projects is that, it is not market driven. Once software requirements are fixed at the beginning of the project; it is difficult to change them if market demands it. One more problem on Waterfall projects is that, it takes too long for a software product to be built.
The Waterfall model and resource requirements on a Waterfall projects are depicted in the next two slides.

6. Chapter 1: software engineering
Waterfall software engineering methodology
Requirement engineering
Software design
Software maintenance
Software construction
Software testing

7. Chapter 1: software engineering
Waterfall software engineering methodology – resource requirements at various stages
Requirement engineering
Software design
Software maintenance
Software construction
Software testing
Business analysts
Business analysts, software designers, software developers, software testers
Software designers
Software developers
Software testers

8. Chapter 1: software engineering
Rational unified process (RUP)
One problem associated with Waterfall model is that it is inflexible. Rational unified process (RUP) tries to address this problem by incorporating iterations in project phases. For example; if software design appears to be complex and more clarity will be needed than normally required then one or more additional iterations will be provided in the project plan for software designing. The drawback with RUP is that, it is not known in advance as to how many iterations will be involved in a project phase. So project planning is still a problem in RUP.

9. Chapter 1: software engineering
Agile software engineering methodologies
Plan driven software engineering methodologies are not suitable for many types of software projects. These software projects are difficult to plan and most often project plans fail because of difficulty associated with estimating effort required on these projects. Agile software engineering methodologies like Extreme programming and Scrum avoid creating project plans. They take a software project as a series of small steps. Iterations (Sprints) are used to build a bunch of software product features from a small set of software requirements (user stories). Planning at this level is much better. Agile models also take a time boxing concept. They assign priority to each user story. High priority user stories are implemented first. Since time is fixed for each sprint, high priority user stories are implemented first. Lower priority user stories are taken only if time permits. Otherwise they are carried forward to next Sprint.
The figure in next slide depicts the idea of Agile methodologies.

10. Chapter 1: software engineering
Agile software engineering methodologies
Requirement engineering
Software design
Software construction
Software testing
Iteration 3
Iteration 2
Iteration 1

11. Chapter 1: software engineering
Extreme programming software engineering methodologies
Extreme programming is one of the popular Agile software engineering methodologies. In extreme programming, software development activities are taken to the extreme. Unit testing is done to ensure business logic is being implemented correctly before writing any code. Pair programming is used to ensure there are no errors in implementing a piece of business logic.
Extreme programming has the same kind of benefits and drawbacks as any Agile software engineering methodology may have.

12. Chapter 1: software engineering
Scrum
Scrum is a very popular Agile software engineering methodology because of its simple framework. Here there are only 3 types of roles involved: project team, Scrum master and customer. Customer provides software requirements in form of user stories. All the user stories are kept in a repository which is known as a product backlog. Project planning is not done in Scrum. Instead; a Release planning is done for creating the software product incrementally over many software product releases in the market. A release planning is broken down into many Sprints. Time span for each Sprint is fixed. It can last from a week to 3-4 weeks. Whenever a new Sprint starts; the customer takes out a bunch of user stories and sets priorities for each of these user stories. This bunch of user stories is known as Sprint backlog. The customer then gives this Sprint backlog to the project team. Each project team member self assigns the project work to implement these user stories. They estimate the effort required and make task plans. They start implementing user stories with the highest priority. Since time is fixed for a Sprint, it may not be possible to implement all user stories. Lower priority user stories can be moved to the next Sprint if they could not be implemented in the current Sprint.

13. Chapter 1: software engineering
Scrum
In Scrum, the project team does not consists of specialists. Each team member can work on any project task. The work being done in a Sprint do not look to follow a strict upstream – downstream pattern as we observe in Waterfall projects. It is because each team member may be doing some project work related to implementing the user story he/she has self assigned. Also since testing at many levels are done so; a testing activity (e.g. unit testing) may be performed before implementing a business logic. At the same time, a team member may have completed implementing a task like business logic for a user story earlier than some other team member for the same task for some other user story. So at any given point of time, all types of project activities like user interface design, database design, business logic implementation, software testing etc. may be going on in a Sprint. This type of scenario is depicted in the next slide.

14. Chapter 1: software engineering
Scrum

15. Chapter 1: software engineering
Scrum
In Scrum, planning extends up to a daily level. When each team member self assigns project work; they create plans for all the project work for the current Sprint. They plan as to what they will do each day of the Sprint. This level of planning ensures that no project work gets delayed and if any pending work remains from a previous day then it is completed the next day. Thus productivity of each team member remains high. In the next slide, Release, Sprint and daily planning is depicted.

16. Chapter 1: software engineering
Scrum

17. Chapter 1: software engineering
Scrum
In Scrum, as software is developed incrementally; there are many software product releases. For each release, there can be many Sprints. Inside each Sprint, there can be many daily plans.
In the next slide, it is shown as to how a software product is built using 2 release. Each of these releases may have many Sprints. Again each of these Sprints may have many daily plans.

18. Chapter 1: software engineering
Scrum