unit 4.pptx very needful and important p

Chapter 8 – Software Testing

Topics covered
 Development testing
 Test-driven development
 Release testing
 User testing

Program testing
 Testing is intended to show that a program does what it is
intended to do and to discover program defects before it is put
into use.
 When you test software, you execute a program using
artificial data.
 You check the results of the test run for errors, anomalies or
information about the program’s non-functional attributes.
 Can reveal the presence of errors NOT their
absence.
 Testing is part of a more general verification and validation
process, which also includes static validation techniques.

Program testing goals
 To demonstrate to the developer and the customer that
the software meets its requirements.
 For custom software, this means that there should be at least
one test for every requirement in the requirements document.
For generic software products, it means that there should be
tests for all of the system features, plus combinations of these
features, that will be incorporated in the product release.
 To discover situations in which the behavior of the
software is incorrect, undesirable or does not conform to
its specification.
 Defect testing is concerned with rooting out undesirable system
behavior such as system crashes, unwanted interactions with
other systems, incorrect computations and data corruption.

Validation and defect testing
 The first goal leads to validation testing
 You expect the system to perform correctly using a given set of
test cases that reflect the system’s expected use.
 The second goal leads to defect testing
 The test cases are designed to expose defects. The test cases in
defect testing can be deliberately obscure and need not reflect
how the system is normally used.

Testing process goals
 Validation testing
 To demonstrate to the developer and the system customer that
the software meets its requirements
 A successful test shows that the system operates as intended.
 Defect testing
 To discover faults or defects in the software where its behaviour
is incorrect or not in conformance with its specification
 A successful test is a test that makes the system perform
incorrectly and so exposes a defect in the system.

An input-output model of program testing

Verification vs validation
 Verification:
"Are we building the product right”.
 The software should conform to its specification.
 Validation:
"Are we building the right product”.
 The software should do what the user really requires.

V & V confidence
 Aim of V & V is to establish confidence that the system is
‘fit for purpose’.
 Depends on system’s purpose, user expectations and
marketing environment
 Software purpose
• The level of confidence depends on how critical the software is to
an organisation.
 User expectations
• Users may have low expectations of certain kinds of software.
 Marketing environment
• Getting a product to market early may be more important than
finding defects in the program.

Inspections and testing
 Software inspections Concerned with analysis of
the static system representation to discover problems
(static verification)
 May be supplement by tool-based document and code
analysis.
 Discussed in Chapter 15.
 Software testing Concerned with exercising and
observing product behaviour (dynamic verification)
 The system is executed with test data and its operational
behaviour is observed.

Software inspections
 These involve people examining the source
representation with the aim of discovering anomalies and
defects.
 Inspections not require execution of a system so may be
used before implementation.
 They may be applied to any representation of the system
(requirements, design,configuration data, test data, etc.).
 They have been shown to be an effective technique for
discovering program errors.

Advantages of inspections
 During testing, errors can mask (hide) other errors.
Because inspection is a static process, you don’t have to
be concerned with interactions between errors.
 Incomplete versions of a system can be inspected
without additional costs. If a program is incomplete, then
you need to develop specialized test harnesses to test
the parts that are available.
 As well as searching for program defects, an inspection
can also consider broader quality attributes of a
program, such as compliance with standards, portability
and maintainability.

Inspections and testing
 Inspections and testing are complementary and not
opposing verification techniques.
 Both should be used during the V & V process.
 Inspections can check conformance with a specification
but not conformance with the customer’s real
requirements.
 Inspections cannot check non-functional characteristics
such as performance, usability, etc.

A model of the software testing process

Stages of testing
 Development testing, where the system is tested during
development to discover bugs and defects.
 Three types of development testing: unit testing,
component testing, system testing
 Release testing, where a separate testing team test a
complete version of the system before it is released to
users.
 Types of release testing: requirement based and
performance based
 User testing, where users or potential users of a system
test the system in their own environment.
 Types of user testing are: alpha, beta, acceptance testing

Development testing
 Development testing includes all testing activities that
are carried out by the team developing the system.
 Unit testing, where individual program units or object classes are
tested. Unit testing should focus on testing the functionality of
objects or methods.
 Component testing, where several individual units are integrated
to create composite components. Component testing should
focus on testing component interfaces.
 System testing, where some or all of the components in a
system are integrated and the system is tested as a whole.
System testing should focus on testing component interactions.

Unit testing
 Unit testing is the process of testing individual
components in isolation.
 It is a defect testing process.
 Units may be:
 Individual functions or methods within an object
 Object classes with several attributes and methods
 Composite components with defined interfaces used to access
their functionality.

Object class testing
 Complete test coverage of a
class involves
 Testing all operations associated
with an object
 Setting and interrogating all object
attributes
 Exercising the object in all possible
states.
 Inheritance makes it more
difficult to design object class
tests as the information to be
tested is not localised.

Automated testing
 Whenever possible, unit testing should be automated so
that tests are run and checked without manual
intervention.
 In automated unit testing, you make use of a test
automation framework (such as JUnit) to write and run
your program tests.
 Unit testing frameworks provide generic test classes that
you extend to create specific test cases. They can then
run all of the tests that you have implemented and
report, often through some GUI, on the success of
otherwise of the tests.

Automated test components
 A setup part, where you initialize the system with the
test case, namely the inputs and expected outputs.
 A call part, where you call the object or method to be
tested.
 An assertion part where you compare the result of the
call with the expected result. If the assertion evaluates to
true, the test has been successful if false, then it has
failed.

Choosing unit test cases
 The test cases should show that, when used as
expected, the component that you are testing does what
it is supposed to do.
 If there are defects in the component, these should be
revealed by test cases.
 This leads to 2 types of unit test case:
 The first of these should reflect normal operation of a program
and should show that the component works as expected.
 The other kind of test case should be based on testing
experience of where common problems arise. It should use
abnormal inputs to check that these are properly processed and
do not crash the component.

Testing strategies
 Partition testing, where you identify groups of inputs
that have common characteristics and should be
processed in the same way.
 You should choose tests from within each of these groups.
 Guideline-based testing, where you use testing
guidelines to choose test cases.
 These guidelines reflect previous experience of the kinds of
errors that programmers often make when developing
components.

Partition testing
 Input data and output results often fall into different
classes where all members of a class are related.
 Each of these classes is an equivalence partition or
domain where the program behaves in an equivalent
way for each class member.
 Test cases should be chosen from each partition.

Testing guidelines (sequences)
 Test software with sequences which have only a single
value.
 Use sequences of different sizes in different tests.
 Derive tests so that the first, middle and last elements of
the sequence are accessed.
 Test with sequences of zero length.

General testing guidelines
 Choose inputs that force the system to generate all error
messages
 Design inputs that cause input buffers to overflow
 Repeat the same input or series of inputs numerous
times
 Force invalid outputs to be generated
 Force computation results to be too large or too small.

Component testing
 Software components are often composite components
that are made up of several interacting objects.
 For example, in the weather station system, the reconfiguration
component includes objects that deal with each aspect of the
reconfiguration.
 You access the functionality of these objects through
the defined component interface.
 Testing composite components should therefore focus
on showing that the component interface behaves
according to its specification.
 You can assume that unit tests on the individual objects within
the component have been completed.

Interface testing or component testing
 Objectives are to detect faults due to interface errors or
invalid assumptions about interfaces.
 Interface types
 Parameter interfaces Data passed from one method or
procedure to another.
 Shared memory interfaces Block of memory is shared between
procedures or functions.
 Procedural interfaces Sub-system encapsulates a set of
procedures to be called by other sub-systems.
 Message passing interfaces Sub-systems request services
from other sub-systems

Interface errors in interface testing
 Interface misuse
 A calling component calls another component and makes an
error in its use of its interface e.g. parameters in the wrong
order.( no. of parameters should always match, parameter name
and value should match )
 Interface misunderstanding
 A calling component embeds assumptions about the behaviour
of the called component which are incorrect. ( no problem in
coding part, eg binary search- input should be ordered, passing
unordered list should not happen)
 Timing errors
 The called and the calling component operate at different speeds
and out-of-date information is accessed. (synchronisation
between calling and called component especially shared data
and shared memory especially timming )

Interface testing guidelines
 Design test cases so that parameters to a called
procedure are at the extreme ends of their ranges.
 Always test pointer parameters with null pointers.
 Design tests which cause the component to fail.
 Use stress testing in message passing systems
(maximum range of inputs beyond range)
 In shared memory systems, vary the order in which
components are activated.

System testing
 System testing during development involves integrating
components to create a version of the system and then
testing the integrated system.
 The focus in system testing is testing the interactions
between components.
 System testing checks that components are
compatible, interact correctly and transfer the right
data at the right time across their interfaces.
 System testing tests the emergent behaviour of a
system.

System and component testing
 During system testing, reusable components that have
been separately developed and off-the-shelf systems
may be integrated with newly developed components.
The complete system is then tested.
 Components developed by different team members or
sub-teams may be integrated at this stage. System
testing is a collective rather than an individual process.
 In some companies, system testing may involve a separate
testing team with no involvement from designers and
programmers.

Use-case testing
Mainly focused on interaction between one subsystem to
another subsystem
 The use-cases developed to identify system
interactions can be used as a basis for system testing.
 Each use case usually involves several system
components so testing the use case forces these
interactions to occur.
 The sequence diagrams associated with the use case
documents the components and interactions that are
being tested.

Collect weather data sequence chart

Test cases derived from sequence diagram
 An input of a request for a report should have an
associated acknowledgement. A report should ultimately
be returned from the request.
 You should create summarized data that can be used to check
that the report is correctly organized.
 An input request for a report to WeatherStation results in
a summarized report being generated.
 Can be tested by creating raw data corresponding to the
summary that you have prepared for the test of SatComms and
checking that the WeatherStation object correctly produces this
summary. This raw data is also used to test the WeatherData
object.

Test-driven development
 Test-driven development (TDD) is an approach to
program development in which you inter-leave testing
and code development.
 Tests are written before code and ‘passing’ the tests is
the critical driver of development.
 You develop code incrementally, along with a test for that
increment. You don’t move on to the next increment until
the code that you have developed passes its test.
 TDD was introduced as part of agile methods such as
Extreme Programming. However, it can also be used in
plan-driven development processes.

TDD process activities
 Start by identifying the increment of functionality that is
required. This should normally be small and
implementable in a few lines of code.
 Write a test for this functionality and implement this as
an automated test.
 Run the test, along with all other tests that have been
implemented. Initially, you have not implemented the
functionality so the new test will fail.
 Implement the functionality and re-run the test.
 Once all tests run successfully, you move on to
implementing the next chunk of functionality.

Benefits of test-driven development
 Code coverage
 Every code segment that you write has at least one associated test
so all code written has at least one test.
 Regression testing (tdd do not test the functionality as a whole)
 A regression test suite is developed incrementally as a program is
developed.
 Simplified debugging
 When a test fails, it should be obvious where the problem lies. The
newly written code needs to be checked and modified.
 System documentation
 The tests themselves are a form of documentation that describe what
the code should be doing.

Regression testing
 Regression testing is testing the system to check that
changes have not ‘broken’ previously working code.
 It’s a continuous process. Everytime we will be
repeating with all the tests on all the increments that we
are going to implement
 Keeping track of all the test is not so easy so In a
manual testing process, regression testing is
expensive but, with automated testing, it is simple
and straightforward. All tests are rerun every time a
change is made to the program.
 Tests must run ‘successfully’ before the change is
committed.

Release testing
 Release testing is the process of testing a particular release
of a system that is intended for use outside of the
development team.
 The primary goal of the release testing process is to
convince the supplier of the system that it is good
enough for use.
 Release testing, therefore, has to show that the system delivers
its specified functionality, performance and dependability, and
that it does not fail during normal use.
 Release testing is usually a black-box testing process
where tests are only derived from the system
specification.

Release testing and system testing
 Release testing is a form of system testing.
 Important differences:
 A separate team that has not been involved in the system
development, should be responsible for release testing. System
testing is done by development team.
 System testing by the development team should focus on
discovering bugs in the system (defect testing).
 The objective of release testing is to check that the system
meets its requirements and is good enough for external use
(validation testing).

Requirements based testing
 Requirements-based testing involves examining each
requirement and developing a test or tests for it.
 Mentcare system requirements:
 If a patient is known to be allergic to any particular medication,
then prescription of that medication shall result in a warning
message being issued to the system user.
 If a prescriber chooses to ignore an allergy warning, they shall
provide a reason why this has been ignored.

Requirements tests
 Set up a patient record with no known allergies. Prescribe medication
for allergies that are known to exist. Check that a warning message is not
issued by the system.
 Set up a patient record with a known allergy. Prescribe the medication to
that the patient is allergic to, and check that the warning is issued by the
system.
 Set up a patient record in which allergies to two or more drugs are
recorded. Prescribe both of these drugs separately and check that the
correct warning for each drug is issued.
 Prescribe two drugs that the patient is allergic to. Check that two
warnings are correctly issued.
 Prescribe a drug that issues a warning and overrule that warning.
Check that the system requires the user to provide information explaining
why the warning was overruled.

A usage scenario for the Mentcare system
George is a nurse who specializes in mental healthcare. One of his responsibilities is to visit patients
at home to check that their treatment is effective and that they are not suffering from medication
side effects.
On a day for home visits, George logs into the Mentcare system and uses it to print his schedule of
home visits for that day, along with summary information about the patients to be visited. He
requests that the records for these patients be downloaded to his laptop. He is prompted for his key
phrase to encrypt the records on the laptop.
One of the patients that he visits is Jim, who is being treated with medication for depression. Jim
feels that the medication is helping him but believes that it has the side effect of keeping him awake
at night. George looks up Jim’s record and is prompted for his key phrase to decrypt the record. He
checks the drug prescribed and queries its side effects. Sleeplessness is a known side effect so he
notes the problem in Jim’s record and suggests that he visits the clinic to have his medication
changed. Jim agrees so George enters a prompt to call him when he gets back to the clinic to make
an appointment with a physician. George ends the consultation and the system re-encrypts Jim’s
record.
After, finishing his consultations, George returns to the clinic and uploads the records of patients
visited to the database. The system generates a call list for George of those patients who He has to
contact for follow-up information and make clinic appointments.

Features tested by scenario
 Authentication by logging on to the system.
 Downloading and uploading of specified patient records
to a laptop.
 Home visit scheduling.
 Encryption and decryption of patient records on a mobile
device.
 Record retrieval and modification.
 Links with the drugs database that maintains side-effect
information.
 The system for call prompting.

Performance testing
 Part of release testing may involve testing the emergent
properties of a system, such as performance and
reliability.
 Tests should reflect the profile of use of the system.
 Performance tests usually involve planning a series of
tests where the load is steadily increased until the
system performance becomes unacceptable.
 Stress testing is a form of performance testing where the
system is deliberately overloaded to test its failure
behaviour.

User testing
 User or customer testing is a stage in the testing process
in which users or customers provide real time input
and advice on system testing.
 User testing is essential, even when comprehensive
system and release testing have been carried out.
 The reason for this is that influences from the user’s working
environment have a major effect on the reliability, performance,
usability and robustness of a system. These cannot be replicated
in a testing environment.

Types of user testing
 Alpha testing
 Users of the software work with the development team to test the
software at the developer’s site.
 Beta testing
 A release of the software is made available to users to allow
them to experiment and to raise problems that they discover with
the system developers.
 Acceptance testing
 Customers test a system to decide whether or not it is ready to
be accepted from the system developers and deployed in the
customer environment. Primarily for custom systems.

The acceptance testing process

Stages in the acceptance testing process
 Define acceptance criteria
 Plan acceptance testing
 Derive acceptance tests
 Run acceptance tests
 Negotiate test results
 Reject/accept system

Agile methods and acceptance testing
 In agile methods, the user/customer is part of the
development team and is responsible for making decisions
on the acceptability of the system. (user is involved in all
the stages of development and in all the decision making
situations and also in testing process)
 Tests are defined by the user/customer and are integrated
with other tests in that they are run automatically when
changes are made.
 There is no separate acceptance testing process.
 Main problem here is whether or not the embedded user is
‘typical’ and can represent the interests of all system
stakeholders. (particular user is going to represent the
entire team once software is deployed)

Chapter 22 – Project Management
Topics covered:
I. Risk management
II. Managing people
III. Teamwork

Software project management
 Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.
 Project management is needed because software
development is always subject to budget and schedule
constraints that are set by the organisation developing
the software.

Success criteria
 Deliver the software to the customer at the agreed time.
 Keep overall costs within budget.
 Deliver software that meets the customer’s expectations.
 Maintain a coherent and well-functioning development
team.

Software management distinctions
 The product is intangible.
 Software cannot be seen or touched. Software project managers
cannot see progress by simply looking at the artefact that is
being constructed.
 Many software projects are 'one-off' projects.
 Large software projects are usually different in some ways from
previous projects. Even managers who have lots of previous
experience may find it difficult to anticipate problems.
 Software processes are variable and organization
specific.
 We still cannot reliably predict when a particular software
process is likely to lead to development problems.

Factors influencing project management
 Company size
 Software customers
 Software size
 Software type
 Organizational culture
 Software development processes
 These factors mean that project managers in different
organizations may work in quite different ways.

Universal management activities
 Project planning
 Project managers are responsible for planning. estimating and
scheduling project development and assigning people to tasks.
 Covered in Chapter 23.
 Risk management
 Project managers assess the risks that may affect a project,
monitor these risks and take action when problems arise.
 People management
 Project managers have to choose people for their team and
establish ways of working that leads to effective team
performance.

Management activities
 Reporting
 Project managers are usually responsible for reporting on the
progress of a project to customers and to the managers of the
company developing the software.
 Proposal writing
 The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work. The
proposal describes the objectives of the project and how it will be
carried out.

Risk management
 Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
 Software risk management is important because of the
inherent uncertainties in software development.
 These uncertainties stem from loosely defined requirements,
requirements changes due to changes in customer needs,
difficulties in estimating the time and resources required for
software development, and differences in individual skills.
 You have to anticipate risks, understand the impact of
these risks on the project, the product and the business,
and take steps to avoid these risks.

Risk classification
 There are two dimensions of risk classification
 The type of risk (technical, organizational, ..)
 what is affected by the risk:
 Project risks affect schedule or resources;
 Product risks affect the quality or performance of the
software being developed;
 Business risks affect the organisation developing or
procuring the software.

Examples of project, product, and business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
finished.
Management change Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been underestimated.
CASE tool
underperformance
Product CASE tools, which support the project, do not
perform as anticipated.
Technology change Business The underlying technology on which the system
is built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.

The risk management process
 Risk identification
 Identify project, product and business risks;
 Risk analysis
 Assess the likelihood and consequences of these risks;
 Risk planning
 Draw up plans to avoid or minimise the effects of the risk;
 Risk monitoring
 Monitor the risks throughout the project;

Risk identification
 May be a team activities or based on the individual
project manager’s experience.
 A checklist of common risks may be used to identify risks
in a project
 Technology risks.
 Organizational risks.
 People risks.
 Requirements risks.
 Estimation risks.

Examples of different risk types
Risk type Possible risks
Estimation The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
Organizational The organization is restructured so that different management are responsible for
the project. (6)
Organizational financial problems force reductions in the project budget. (7)
People It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Requirements Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Technology The database used in the system cannot process as many transactions per
second as expected. (1)
Reusable software components contain defects that mean they cannot be reused
as planned. (2)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)

Risk analysis
 Assess probability and seriousness of each risk.
 Probability may be very low, low, moderate, high or very
high.
 Risk consequences might be catastrophic, serious,
tolerable or insignificant.

Risk types and examples
Risk Probability Effects
Organizational financial problems force reductions in the
project budget (7).
Low Catastrophic
It is impossible to recruit staff with the skills required for the
project (3).
High Catastrophic
Key staff are ill at critical times in the project (4). Moderate Serious
Faults in reusable software components have to be repaired
before these components are reused. (2).
Moderate Serious
Changes to requirements that require major design rework
are proposed (10).
Moderate Serious
The organization is restructured so that different
management are responsible for the project (6).
High Serious
The database used in the system cannot process as many
transactions per second as expected (1).
Moderate Serious

Risk types and examples
Risk Probability Effects
The time required to develop the software is
underestimated (12).
High Serious
Software tools cannot be integrated (9). High Tolerable
Customers fail to understand the impact of requirements
changes (11).
Moderate Tolerable
Required training for staff is not available (5). Moderate Tolerable
The rate of defect repair is underestimated (13). Moderate Tolerable
The size of the software is underestimated (14). High Tolerable
Code generated by code generation tools is inefficient (8). Moderate Insignificant

Risk planning
 Consider each risk and develop a strategy to manage
that risk.
 Avoidance strategies
 The probability that the risk will arise is reduced;
 Minimization strategies
 The impact of the risk on the project or product will be reduced;
 Contingency plans
 If the risk arises, contingency plans are plans to deal with that
risk;

What-if questions
 What if several engineers are ill at the same time?
 What if an economic downturn leads to budget cuts of
20% for the project?
 What if the performance of open-source software is
inadequate and the only expert on that open source
software leaves?
 What if the company that supplies and maintains
software components goes out of business?
 What if the customer fails to deliver the revised
requirements as predicted?

Strategies to help manage risk
Risk Strategy
Organizational financial
problems
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business and presenting
reasons why cuts to the project budget would not be cost-
effective.
Recruitment problems Alert customer to potential difficulties and the possibility of
delays; investigate buying-in components.
Staff illness Reorganize team so that there is more overlap of work and
people therefore understand each other’s jobs.
Defective components Replace potentially defective components with bought-in
components of known reliability.
Requirements changes Derive traceability information to assess requirements
change impact; maximize information hiding in the design.

Strategies to help manage risk
Risk Strategy
Organizational
restructuring
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Database
performance
Investigate the possibility of buying a higher-performance
database.
Underestimated
development time
Investigate buying-in components; investigate use of a
program generator.

Risk monitoring
 Assess each identified risks regularly to decide whether
or not it is becoming less or more probable.
 Also assess whether the effects of the risk have
changed.
 Each key risk should be discussed at management
progress meetings.

Risk indicators
• Risk monitoring is the process of checking that your
assumptions about the product,, and business risks have not
changed.
• You should regularly assess each of the identified risks to
decide whether or not that risk is becoming more or less
probable.
• You should also think about whether or not the effects of the
risk have changed.
• You should monitor risks regularly at all stages in a project. At
every management review, you should consider and discuss
each of the key risks separately. You should decide if the risk is
more or less likely to arise and if the seriousness and
consequences of the risk have changed.

Risk type Potential indicators
Estimation Failure to meet agreed schedule; failure to clear reported defects.
Organizational Organizational gossip; lack of action by senior management.
People Poor staff morale; poor relationships amongst team members; high
staff turnover.
Requirements Many requirements change requests; customer complaints.
Technology Late delivery of hardware or support software; many reported
technology problems.
Tools Reluctance by team members to use tools; complaints about CASE
tools; demands for higher-powered workstations.

Managing people
 People are an organisation’s most important assets.
 The tasks of a manager are essentially people-oriented.
Unless there is some understanding of people,
management will be unsuccessful.
 Poor people management is an important contributor to
project failure.

People management factors
 Consistency
 Team members should all be treated in a comparable way
without favourites or discrimination.
 Respect
 Different team members have different skills and these
differences should be respected.
 Inclusion
 Involve all team members and make sure that people’s views are
considered.
 Honesty
 You should always be honest about what is going well and what
is going badly in a project.

Motivating people
 An important role of a manager is to motivate the people
working on a project.
 Motivation means organizing the work and the working
environment to encourage people to work effectively.
 If people are not motivated, they will not be interested in the work
they are doing. They will work slowly, be more likely to make
mistakes and will not contribute to the broader goals of the team
or the organization.
 Motivation is a complex issue but it appears that their are
different types of motivation based on:
 Basic needs (e.g. food, sleep, etc.);
 Personal needs (e.g. respect, self-esteem);
 Social needs (e.g. to be accepted as part of a group).

Need satisfaction
 In software development groups, basic physiological and
safety needs are not an issue.
 Social
 Provide communal facilities;
 Allow informal communications e.g. via social networking
 Esteem
 Recognition of achievements;
 Appropriate rewards.
 Self-realization
 Training - people want to learn more;
 Responsibility.

Personality types
 The needs hierarchy is almost certainly an over-
simplification of motivation in practice.
 Motivation should also take into account different
personality types:
 Task-oriented people, who are motivated by the work they do. In
software engineering.
 Interaction-oriented people, who are motivated by the presence
and actions of co-workers.
 Self-oriented people, who are principally motivated by personal
success and recognition.

Personality types
 Task-oriented.
 The motivation for doing the work is the work itself;
 Self-oriented.
 The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel etc.;
 Interaction-oriented
 The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.

Motivation balance
 Individual motivations are made up of elements
of each class.
 The balance can change depending on personal
circumstances and external events.
 However, people are not just motivated by personal
factors but also by being part of a group and culture.
 People go to work because they are motivated by the
people that they work with.

Teamwork
 Most software engineering is a group activity
 The development schedule for most non-trivial software projects
is such that they cannot be completed by one person working
alone.
 A good group is cohesive and has a team spirit. The
people involved are motivated by the success of the
group as well as by their own personal goals.
 Group interaction is a key determinant of group
performance.
 Flexibility in group composition is limited
 Managers must do the best they can with available people.

Group cohesiveness
 In a cohesive group, members consider the group to be
more important than any individual in it.
 The advantages of a cohesive group are:
 Group quality standards can be developed by the group
members.
 Team members learn from each other and get to know each
other’s work; Inhibitions caused by ignorance are reduced.
 Knowledge is shared. Continuity can be maintained if a group
member leaves.
 Refactoring and continual improvement is encouraged. Group
members work collectively to deliver high quality results and fix
problems, irrespective of the individuals who originally created
the design or program.

The effectiveness of a team
 The people in the group
 You need a mix of people in a project group as software
development involves diverse activities such as negotiating with
clients, programming, testing and documentation.
 The group organization
 A group should be organized so that individuals can contribute to
the best of their abilities and tasks can be completed as
expected.
 Technical and managerial communications
 Good communications between group members, and between
the software engineering team and other project stakeholders, is
essential.

Selecting group members
 A manager or team leader’s job is to create a cohesive
group and organize their group so that they can work
together effectively.
 This involves creating a group with the right balance of
technical skills and personalities, and organizing that
group so that the members work together effectively.

Assembling a team
 May not be possible to appoint the ideal people to work on
a project
 Project budget may not allow for the use of highly-paid staff;
 Staff with the appropriate experience may not be available;
 An organisation may wish to develop employee skills on a
software project.
 Managers have to work within these constraints especially
when there are shortages of trained staff.

Group composition
 Group composed of members who share the
same motivation can be problematic
 Task-oriented - everyone wants to do their own thing;
 Self-oriented - everyone wants to be the boss;
 Interaction-oriented - too much chatting, not enough work.
 An effective group has a balance of all types.
 This can be difficult to achieve software engineers are
often task-oriented.
 Interaction-oriented people are very important as they
can detect and defuse tensions that arise.

Group organization
 The way that a group is organized affects the decisions
that are made by that group, the ways that information is
exchanged and the interactions between the
development group and external project stakeholders.
 Key questions include:
• Should the project manager be the technical leader of the group?
• Who will be involved in making critical technical decisions, and how
will these be made?
• How will interactions with external stakeholders and senior company
management be handled?
• How can groups integrate people who are not co-located?
• How can knowledge be shared across the group?

Group organization
 Small software engineering groups are usually organised
informally without a rigid structure.
 For large projects, there may be a hierarchical structure
where different groups are responsible for different sub-
projects.
 Agile development is always based around an informal
group on the principle that formal structure inhibits
information exchange

Informal groups
 The group acts as a whole and comes to a consensus
on decisions affecting the system.
 The group leader serves as the external interface of the
group but does not allocate specific work items.
 Rather, work is discussed by the group as a whole and
tasks are allocated according to ability and experience.
 This approach is successful for groups where all
members are experienced and competent.

Group communications
 Good communications are essential for effective group
working.
 Information must be exchanged on the status of work,
design decisions and changes to previous decisions.
 Good communications also strengthens group cohesion
as it promotes understanding.

Group communications
 Group size
 The larger the group, the harder it is for people to communicate
with other group members.
 Group structure
 Communication is better in informally structured groups than in
hierarchically structured groups.
 Group composition
 Communication is better when there are different personality
types in a group and when groups are mixed rather than single
sex.
 The physical work environment
 Good workplace organisation can help encourage
communications.

unit 4.pptx very needful and important p

More Related Content

Similar to unit 4.pptx very needful and important p (20)

Recently uploaded (20)

unit 4.pptx very needful and important p