Teaching slides Chapter 1

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

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.

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

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.

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

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

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.

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.

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

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.

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.

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.

Chapter 1: software engineering Scrum

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.

Chapter 1: software engineering Scrum

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.

Chapter 1: software engineering Scrum