fter Completing this chapter you should be able to:
understand what software engineering is and why it is important;
understand the concepts of software processes and software process models;
Compare and contrast a variety of models
understand some ethical and professional issues that are important for software engineers;
3. Objectives
After Completing this chapter you should be able to:
understand what software engineering is and why it is
important;
understand the concepts of software processes and software
process models;
Compare and contrast a variety of models
understand some ethical and professional issues that are
important for software engineers;
3
4. Content
Software and Software Engineering
Software Crisis
OO Software Development Activities
Software Process Models
Software Engineering Ethics
4
5. What is Software?
Software can be defined as a collection of programs,
documentation and operating procedures.
Software encompasses: (1) instructions (computer
programs) that when executed provide desired
features, function, and performance; (2) data
structures that enable the programs to adequately
store and manipulate information and (3)
documentation that describes the operation and use
of the programs.
5
6. The Nature of Software
6
Software is intangible
Hard to understand development effort
7. The Nature of Software
Software is easy to reproduce
Cost is in its development
in other engineering products, manufacturing is the costly stage
The industry is labor-intensive
Hard to automate
Software is easy to modify
People make changes without fully understanding it
Software does not ‘wear out’
It deteriorates by having its design changed:
erroneously, or
in ways that were not anticipated, thus making it complex
7
8. Types of Software
Custom
For a specific customer
Generic
Sold on open market
Often called
COTS (Commercial Off The Shelf)
Embedded
Built into hardware
Hard to change
8
9. Types of Software (cont’d)
Real time software
E.g. control and monitoring systems
Must react immediately
Safety often a concern
Data processing software
Used to run businesses
Accuracy and security of data are key
Some software has both aspects
9
10. Attributes of good software
Functionality
degree of performance of the software against its intended
purpose
Reliability
It does what it is required to do without failing
Efficiency
It doesn’t waste resources such as CPU time and memory
Maintainability
It can be easily changed
Usability
Users can learn it fast and get their job done easily
10
11. Attributes of good software (cont’d)
Portability
the ease with which software developers can transfer software
from one platform to another, without (with minimum) changes.
Robustness
the extent to which software can continue to operate correctly
despite the introduction of invalid input
Integrity
the extent to which unauthorized access or modifications of
software or data can be controlled in the computer system
(security level)
Each can conflict; In an increase efficiency can
reduce maintainability and vice versa
11
12. What is software engineering?
Software engineering is an engineering discipline
which is concerned with all aspects of software
production
Engineering discipline
Using appropriate theories and methods to solve problems
bearing in mind time and financial constraints.
All aspects of software production
Not just technical process of development. Also project
management and the development of tools, methods etc. to
support software production.
The application of a systematic, disciplined,
quantifiable approach to the development, operation,
and maintenance of software; that is, the application
of engineering to software.
from IEEE , issued in 1993. 12
13. What is software engineering? (cont’d)
Modeling activity
deal with complexity through modeling, by focusing at any one
time on only the relevant details and ignoring everything else.
Problem solving activity
Knowledge acquisition activity
software engineers collect data, organize it into information,
and formalize it into knowledge
Rational driven activity
software engineers need to capture the context in which
decisions were made and the rationale behind these
decisions.
13
14. Software Crisis
The CHAOS study published in 1995 by The Standish Group
found that although the U.S spent over $250 billion on IT
projects, approximately…
31% were cancelled before completion
53% were completed but over budget, over schedule, & did not meet
original specifications
For mid-size companies, average cost overruns were 182%, while
average schedule overruns were 202%!
Most of software products are being delivered late, over budget,
and with residual faults.
14
15. Summary of the Chaos Studies from
2004 to 2012
15
Software engineer has to acquire a broad range of skills, both
technical and managerial to deliver software on time.
These skills have to be applied not just to programming but to
every step of software
16. OO Software Development Activities
Development activities included:
Requirement elicitation
During requirements elicitation, the client and developers define
the purpose of the system.
Analysis
The client’s requirements are analyzed and presented in the form
of the specification document, “what the product is supposed to
do.”
Design
Implementation: write source code & test
Maintenance: changes to the product once the product has
been delivered
16
17. Software Process
A software process is a set of related activities that leads to the
production of a software system.
Different types of software requires specialized software
engineering techniques
No universally applicable software process but all involve:
Software specification defining what the system should do.
Software development The software to meet the specification must
be produced.
Software validation Checking that it does what the customer wants.
Software evolution The software must evolve to meet changing
customer needs.
17
18. Plan-driven and agile processes
Plan-driven processes are processes where all of the
process activities are planned in advance and
progress is measured against this plan.
Not suitable for rapid software development and delivery
In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
In practice, most practical processes include elements
of both plan-driven and agile approaches.
There are no right or wrong software processes.
18
19. Software Process Models
A software process model(software engineering paradigm) is a
framework that describes the sequence of activities performed at each
stage of a software development project, and relative order of these
activities.
Covers the entire lifetime of a product
Software models:
Code-and-fix life-cycle model
Waterfall model
V-Model
Prototype model
Spiral model
Agile model
In practice, most large systems are developed using a process that
incorporates elements from all of these models.
19
20. Code-and-Fix Life-Cycle Model
This model starts with an informal general product idea and just
develops code until a product is “ready” (or money or time runs
out)
Work “well” on short programming
20
21. Code-and-Fix Life-Cycle Model(cont’d)
Strengths:
No administrative overhead
Sign of progress (code) early
Low expertise, anyone can use it
Useful for small “proof of concept” projects, e.g. as part of risk reduction
Problems:
Unsatisfactory for products of any reasonable size
No resource planning; No deadlines
Maintenance of a product can be extremely difficult
Impossible for large projects: communication breakdown, chaos
The code-and-fix model is the easiest way to develop software—and
by far the worst way
21
22. Waterfall Model
22
Sequential approach: a phase has to be complete before moving onto
the next phase.
Unidirectional, “no way back”; finish this phase before moving to the next
Plan-driven process: plan and schedule all of the process activities
before starting software development
Requirements - defines needed
information, function, behavior &
performance
Design - data structures,
architecture, algorithmic details
Implementation – source code, DB
Deployment &
Maintenance
Requirements
Design
Implementation
Testing
Waterfall
method “Swimming
upstream”
23. Waterfall Model Strengths
Easy to understand, easy to use
Sets requirements stability
Provides structure to inexperienced staff
Milestones are well understood
Good for management control(plan, staff, track).
Works well when quality is more important than cost or
schedule
Reinforces good habits: define-before-design, design-before
code.
Document driven, RAD, SDD, etc.
23
24. Waterfall Model Problems
Idealized, doesn’t match reality well
Real projects rarely follow the sequential flow that the model
proposes
In reality, software has to be flexible and accommodate change as it
is being developed.
It is often difficult for the customer to state all requirements at the
beginning of the project
Difficult to respond to changing customer requirements. It requires
documents produced to be modified to reflect the required changes
Can give a false impression of progress
Software is delivered late in project, delays discovery of serious
errors.
24
25. When to use Waterfall Model?
When the requirements are well-understood and changes will be
fairly limited during the design process.
Technology is understood
New version of existing product
Critical systems where problems in analysis and design are very
expensive to correct at implementation stage.
For large systems engineering projects where a system is
developed at several sites.
In those circumstances, the plan-driven nature of the waterfall model
helps coordinate the work.
25
26. The V-Model
26
A variant of the waterfall that provides a way
of visualizing how verification and validation
actions are applied to earlier engineering work
Test of the product is planned in parallel with
a corresponding phase of development.
Strengths:
Emphasize planning for verification and
validation of the product in early stages of
the product development.
Project management can track progress
by milestone
Easy to use
Weakness:
Doesn’t easily handle concurrent events.
Doesn’t not easily handle dynamic
changes in requirements.
27. When to use the V-Shaped model?
Excellent choice for systems requiring high reliability-
hospital patient control applications
All requirements are known up-front.
Solution and technology are known.
27
28. Prototype Model
It is the act of building a small-scale, representative or
working model of the users’ requirements.
Identify basic requirements
Include input and output information
Details(e.g. security) generally ignored.
Develop initial prototype
UI first
Review
Customers review and give feedback
Revise and enhance the prototype
Negotiation about scope of contract may be necessary
At any stage, if the user is not satisfied with the prototype,
it can be discarded and an entirely new system developed.
28
30. Strengths and Problems
Strengths:
Users are actively involved in the development
users get a better understanding of the system being
developed -> allows to provide better feedback.
Quick user feedback is available leading to better solutions
Final product more likely to satisfy their desired look/feel
Errors can be detected much earlier
Problems:
Leads to implementing and then repairing way of building
systems - time consuming.
May increase the complexity of the system as scope of the
system (user requirements) may expand beyond original
plans.
30
31. When to use prototyping?
Usually used when a system does not exist or in case of a
large and complex system where there is difficult to
determine the requirements
Used to determine what the client’s real needs are
For system that will have many interactions with end
users
Good for designing good human-computer interaction
31
32. Spiral Model
Couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
An iterative model that adds risk analysis and risk management
into waterfall model.
Key idea: on each iteration identify and solve sub-problems with
the highest risk.
Since end-user requirements are hard to obtain/define, it is
natural to develop software in an experimental way: e.g.
Build some software
See if it meets customer requirements
If no, go to 1, else stop
This loop approach gives rise to structured iterative lifecycle
models.
32
34. Spiral Model(cont’d)
Each loop in the spiral is split into four sectors
Objective setting
Specific objectives for the phase are identified
Risk assessment and reduction
Risks are assessed and activities put in place to reduce the key
risks
Development and validation
This quadrant of the spiral model corresponds to the classical
waterfall model
Planning
The project is reviewed and the next phase of the spiral is planned
34
35. Spiral Model(cont’d)
Advantages
Risk management (risk analysis and resolution)
Early and frequent feedback from users
Users see the system early because of rapid prototyping tools.
Disadvantages
Risk assessment and its resolution is not an easy task-
requires technical expertise in risk analysis
the model is not applicable for small and low-risk projects
Difficult to estimate budget
35
36. When to use Spiral Model?
For medium to high risk projects
Requirements are complex
New product line
Significant changes are expected(research and
exploration)
36
37. Agile Model
Agile methods are designed to produce useful
software quickly
What is “Agility”?
Effective (rapid and adaptive) response to change
Effective communication among all stakeholders
Drawing the customer onto the team
Organizing a team so that it is in control of the work performed
Yielding …
Rapid, incremental delivery of software
Goal: to satisfy the customers
Speed up or bypass one or more life cycle phases
Used for time-critical applications
37
38. The Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
Individuals and interactions OVER processes and tools
Working software OVER comprehensive documentation
Customer collaboration OVER contract negotiation
Responding to change OVER following a plan
That is, while there is value in the items on the right, we value the
items on the left more.”
Some agile methods:
Extreme programming(XP)
Scrum
Crystal
Rational Unified Process (RUP)
Dynamic software development method(DSDM)
38
Agile Model(cont’d)
39. Extreme Programming(XP) Model
Software development team determines the various features
(stories - something like use cases) client would like the
product to support.
Complex stories are broken down into simpler ones(tasks).
Stories are used to estimate the required amount of work
Stories are used to create acceptance tests.
Test-drive development (TDD)
Tests are developed along with the requirements before
development starts. This helps the testers and developers to
understand the requirements and ensures that there are no delays
as test cases are created
The customer is always available.
39
40. XP (cont’d)
Refactoring (improve and restructure) is done constantly -
reduce structural degradation and general code messiness
Programming and integration in pairs.
Continuous planning, change, delivery(every 2 or 3 weeks)
Each day begins with a stand-up meeting to share
problems and concerns.
40
41. XP Model Strengths
Lightweight methods suit small-medium size projects
Emphasis final product
Test-based approach to requirements and quality
assurance
Iterative
41
42. XP Model Weakness
Difficult to scale up to large projects where
documentation is essential
Needs experience and skill if not to degenerate into
code-and-fix
Test case construction is a difficult and specialized
skill.
42
43. Ethics in Software Engineering
Software engineering involves wider responsibilities
than simply the application of technical skills
Software engineers must behave in an honest and
ethically responsible way if they are to be respected
as professionals
Ethical behavior is more than simply upholding the
law but involves following a set of principles that are
morally correct.
Issues of professional responsibility:
Confidentiality
Competence
Intellectual property rights
Computer misuse 43
44. Ethics in Software Engineering (cont’d)
Confidentiality
You should respect the confidentiality of your employers or
clients regardless of whether or not a formal confidentiality
agreement has been signed.
Competence
You should not misrepresent your level of competence. You
should not knowingly accept work that is outside your
competence.
44
45. Ethics in Software Engineering (cont’d)
Intellectual property rights
You should be aware of local laws governing the use of
intellectual property such as patents & copyright. You should
be careful to ensure that the intellectual property of employers
and clients is protected.
Computer misuse
You should not use your technical skills to misuse other
people’s computers. Computer misuse ranges from relatively
trivial (game playing on an employer’s machine, say) to
extremely serious (dissemination of viruses).
45
46. ACM/IEEE Code of Ethics
Professional societies and institutions have an
important role to play in setting ethical standards.
ACM/IEEE task force has produced a Software
Engineering Code of Ethics and Professional
Practices
The Code contains Eight Principles related to the
behaviour of and decisions made by professional
software engineers, including practitioners, educators,
managers, supervisors and policy makers, as well as
trainees and students of the profession.
46
47. ACM/IEEE Code of Ethics
PUBLIC
Software engineers shall act consistently with the public
interest.
CLIENT AND EMPLOYER
Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the
public interest.
PRODUCT
Software engineers shall ensure that their products and
related modifications meet the highest professional
standards possible.
47
48. ACM/IEEE Code of Ethics(cont’d)
JUDGMENT
Software engineers shall maintain integrity and independence
in their professional judgment.
MANAGEMENT
Software engineering managers and leaders shall subscribe to
and promote an ethical approach to the management of
software development and maintenance.
PROFESSION
Software engineers shall advance the integrity and reputation
of the profession consistent with the public interest.
48
49. ACM/IEEE Code of Ethics(cont’d)
COLLEAGUES
Software engineers shall be fair to and supportive of their
colleagues.
SELF
Software engineers shall participate in lifelong learning
regarding the practice of their profession and shall promote an
ethical approach to the practice of the profession.
49
50. What is Next?
Form a group of 3 members and submit on the next
session
Identify project title
50
Editor's Notes
Waterfall approach assumes that a complete system will be delivered after the linear sequence is completed. Prototype is not designed to deliver a production system. The evolutionary nature of software is not considered in either of these classic software engineering paradigms.