Scribd
Upload
5 views

Week 02 SE

kokdspokcfdokodkcopkdopckdsop

Uploaded by

nourin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
5 views

Week 02 SE

kokdspokcfdokodkcopkdopckdsop

Uploaded by

nourin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 28

Chapter 2 cont.

…
Coping with changing requirements

What to do when the user is not exactly sure of the requirements?

30/10/2014 Chapter 2 Software Processes 2


Any idea

30/10/2014 Chapter 2 Software Processes 3


Coping with changing requirements

 System prototyping
 Incremental delivery

30/10/2014 Chapter 2 Software Processes 4


Software prototyping

 A prototype is:
 an initial version of a system
 used to demonstrate concepts and
 Show design options.
 Find out about any possible requirements’ problems
 Predict their solutions
 A prototype can be used in anticipating changes in the process:
 Used to refine the requirements elicitation and validation phase;
 In design processes to explore options and develop a UI design;
 In the testing process to run back-to-back tests.

30/10/2014 Chapter 2 Software Processes 5


Benefits of prototyping

 Improved system usability


 A closer match to users’ real needs.
 Improved design quality. ~
 Improved maintainability. Reduced development effort. ~ as lesser
maintenance required.

30/10/2014 Chapter 2 Software Processes 6


The process of prototype development

30/10/2014 Chapter 2 Software Processes 7


Prototype development

 To reduce prototyping cost & accelerate the deployment schedule it’s


important to select what to involve in the prototype.
 May involve leaving out functionality
 Prototype should focus on areas of the product that are not well-understood
 Error checking and recovery may not be included in the prototype;
 Focus on functional requirements like core module implementation.
 Nonfunctional requirements like response time and memory utilization are ignored.

30/10/2014 Chapter 2 Software Processes 8


Prototype Development

Is it good to proceed further with a prototype?

30/10/2014 Chapter 2 Software Processes 9


Throw-away prototypes

 Prototypes should be discarded after development as they are not a


good basis for a production system
 It may be impossible to tune the system to meet non-functional requirements;
 Prototypes are normally undocumented;
 The prototype structure is usually degraded through rapid change; so, it is not good to
proceed further with the prototype.
 The prototype probably will not meet normal organizational quality standards.(as it may
have lesser response time, no error handling and all)

30/10/2014 Chapter 2 Software Processes 10


Incremental delivery

 Rather than deliver the system as a single delivery, the software


development and delivery is broken down into increments, with each
increment delivering part of the required functionality.
 User requirements are prioritized by user himself
 and the highest priority requirements are included in early increments.
 When an increment is under development then its requirements are
frozen.
 though requirements for later increments can continue to evolve.

30/10/2014 Chapter 2 Software Processes 11


Incremental development and delivery

 Incremental development
 Develop the system in increments
 and evaluate each increment before proceeding to the development of the next
increment;
 Normal approach used in agile methods;
 Evaluation is done by user/customer.
 Incremental delivery
 Deploy an increment for use by end-users;
 More realistic evaluation about practical use of software;
 Difficult to implement for replacement systems as increments have less functionality than
the system being replaced.

30/10/2014 Chapter 2 Software Processes 12


Incremental delivery

30/10/2014 Chapter 2 Software Processes 13


Incremental delivery advantages

 Customer value can be delivered with each increment so system


functionality is available earlier.
 Early increments act as a prototype to help elicit requirements for later
increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the most testing.
As the first increment is a highly prioritized system that will be tested with
every later increment.

30/10/2014 Chapter 2 Software Processes 14


Incremental delivery problems

 Most systems require a set of basic facilities that are


used by different parts of the system. ~ dependence
between increments
 As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities
that are needed by all increments.
 The essence of iterative processes is that the
specification is developed in conjunction with the
software.
 However, this conflicts with the procurement model of many
organizations, where the complete system specification is
part of the system development contract.

30/10/2014 Chapter 2 Software Processes 15


Software Process improvement

30/10/2014 Chapter 2 Software Processes 16


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 17


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 18


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 19


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 20


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 21


Process improvement activities

 Process measurement (identify what to change)


 Process analysis (assess weakness & strengths)
 Process change(change the process)

30/10/2014 Chapter 2 Software Processes 22


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 23


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 24


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 25


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 26


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 27


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 28

You might also like