Scribd
Upload
20 views

Lecture 7

Uploaded by

muazzam22
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
20 views

Lecture 7

Uploaded by

muazzam22
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 23

Software Process improvement

30/10/2014 Chapter 2 Software Processes 1


Process improvement

 For a newly developed Software house, With so many software rivalries in


industry…. How to compete and make your place
 3 main challenges for software houses:
 cheaper software,
 better software,
 delivered with much tighter deadlines
 Solution:
 Deliver quality product,
 With reduced costs
 And to accelerate their development processes to meet deadlines.

30/10/2014 Chapter 2 Software Processes 2


Process improvement

 Software Process improvement means:


 understanding existing processes
 and changing these processes to increase product quality
 and/or reduce costs and development time.

30/10/2014 Chapter 2 Software Processes 3


Approaches to improvement

 The process maturity approach:


 Focus on improving process and project management
 and introduces good software engineering practice into organizations.
 Defined process maturity levels to measure the reputation of an organization.
 Higher the level of process maturity = good technical and management practice adopted
for software development processes.
 Goals:
• Improve product quality & process predictability
 Generally, for plan driven approaches

30/10/2014 Chapter 2 Software Processes 4


Approaches to improvement

 The agile approach:


 focuses on:
• iterative development
• and the reduction of overheads in the software process.
 Characteristics:
• rapid delivery of functionality
• responsiveness to changing customer requirements.
 Agile follows code development with minimal documentations overhead

30/10/2014 Chapter 2 Software Processes 5


The process improvement cycle

Measure process -> check if improvement would be feasible -> do the change -> measure the impact of changes on process

30/10/2014 Chapter 2 Software Processes 6


Process improvement activities

 Process measurement (identify what to change)


 measure one/more attributes of the software process or product->
 Check if process improvement have been effective -> do improvement -> remeasure the
impact after improvement
 Process analysis (assess weakness & strengths)
 The current process is assessed, and process weaknesses and bottlenecks are
identified.
 Process models (sometimes called process maps) that describe the process may be
developed.
 Process change(change the process)
 Process changes are proposed to address some of the identified process weaknesses.
 These are introduced and the cycle resumes to collect data about the effectiveness of the
changes.
30/10/2014 Chapter 2 Software Processes 7
Process measurement

 Wherever possible, quantitative process data should be collected


 However, where organisations do not have clearly defined process standards this is very
difficult as you don’t know what to measure. A process may have to be defined before
any measurement is possible.
 Process measurements should be used to assess process improvements
 But this does not mean that measurements should drive the improvements. The
improvement driver should be the organizational objectives.

30/10/2014 Chapter 2 Software Processes 8


Process metrics

 Time taken for process activities to be completed


 E.g. Calendar time or effort to complete an activity or process.
 Resources required for processes or activities
 E.g. Total effort in person-days.
 Number of occurrences of a particular event
 E.g. Number of defects discovered.

30/10/2014 Chapter 2 Software Processes 9


The SEI Capability maturity levels

 Rates the maturity of an organization over 5 point scale


 Not a software process model.
 Provides a mean of measuring how well an organization
manages to accomplish the tasks.

30/10/2014 Chapter 2 Software Processes 10


CMM initial stage

 Initial
 Generally the starting point of any software organization
 Unmanaged work
 No proper software documentation
 No effective project management plans (generally, opt build and fix models)
 No cost estimation
 Vast majority of the organizations are at this level
 Challenges:
• Project management, planning and SQA

30/10/2014 Chapter 2 Software Processes 11


CMM Managed stage

 Managed
 Goals associated with project are satisfied
 Defined organizational policies (when which process to be used?)
 Documented project plan with goals
 Resource management is properly done. (technology relevant task force)
 Generally working on same types of software

30/10/2014 Chapter 2 Software Processes 12


The SEI capability maturity model

 Defined
 Process management procedures and strategies defined and used
 Proper teamwork
 Collaborative learning environment
 Managed
 Assess organizational performance.
 Better project management structures.
 Risk analysis and proactive approaches (what if a project fails?)
 Optimising
 Process improvement strategies defined and used.
 More and more adaption to newer trends

30/10/2014 Chapter 2 Software Processes 13


Chapter 3 – Agile Software Development

30/10/2014 Chapter 3 Agile Software Development 14


Rapid software development

 Business needs may change rapidly


-> no stable requirements -> software has to change quickly
to adapt these changes -> rapid development and delivery is
the most important requirement for software systems
 Requirements may change after software delivery as the
UX will help in improving design. Sometimes, external
factors ,may lead to system change.
 For example, a live streaming application with low
bandwidth issue.

30/10/2014 Chapter 3 Agile Software Development 15


Rapid software development

 Plan-driven development:
 Could be helpful for some types of system but it can not meet the
rapidly changing business needs.
 Can be helpful for some safety critical systems
 Using plan driven approach for software that have rapid changing
business requirements might led to a delayed software product
that would become obsolete after deployment.
 Agile development:
 methods emerged in the late 1990s, whose aim was to radically
reduce the delivery time for working software systems

30/10/2014 Chapter 3 Agile Software Development 16


Agile development

 Program specification, design and implementation are


inter-leaved
 The system is developed as a series of versions or
increments with stakeholders involved in version
specification and evaluation
 Frequent delivery of new versions for evaluation every 2-
3 weeks
 Extensive tool support to speedup the development process
(e.g. automated testing tools, configuration/integration tools)
e.g. selenium
 Minimize documentation overhead
30/10/2014 Chapter 3 Agile Software Development 17
Plan-driven and agile development comparison

30/10/2014 Chapter 3 Agile Software Development 18


Agile development

 Agile consider design & implementation as main activity.


 Requirement elicitation & testing are merged into the design
& implementation phase.
 Issue?
 We can’t keep track of the change in requirements as no official
documents have been made
 So plan-driven / Agile ?
 So a better approach is that the plan driven model may work in
increments & agile methodology may focus a bit to documentation as
well.

30/10/2014 Chapter 3 Agile Software Development 19


Agile methods

30/10/2014 Chapter 3 Agile Software Development 20


Agile methods

 Background:
 Dissatisfaction with the overheads in software design methods of
the 80s and 90s led to the creation of agile methods.
 Characteristics:
 Focus on the code rather than the design
 Are based on an iterative approach to software development
 Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
 Aim:
 reduce overheads in the software process (e.g. by limiting
documentation)
 able to respond quickly to changing requirements without
excessive rework.
30/10/2014 Chapter 3 Agile Software Development 21
The principles of agile methods

Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.

People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.

Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.

Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.

30/10/2014 Chapter 3 Agile Software Development 22


Agile method applicability

 Development of a small or medium-sized product for sale.


 Virtually all software products and apps are now developed using an agile approach
 Custom system development within an organization, where there is a clear
commitment from the customer to become involved in the development
process and where there are few external rules and regulations that
affect the software.

30/10/2014 Chapter 3 Agile Software Development 23

You might also like