The document outlines essential concepts in software engineering, including definitions of software, types, attributes of good software, and the importance of software processes and models. It details various software development models such as waterfall, spiral, and agile methodologies, emphasizing their strengths and weaknesses, and highlights the pivotal role of ethics in software engineering practice. The document aims to provide a comprehensive understanding of software production, the implications of the software crisis, and the ethical standards expected from software engineers.

1. CS663
Object Oriented Software
Development
Department of Computer Science
Admas University
Dec, 2020

2. 2
Chapter One
Introduction

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

29. Prototype Model(cont’d)
29
Iterative: re-do the product at each phase

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

33. Spiral Model(cont’d)
33

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