Lecture 1 SE.pptx

Dr. Syed Ali Raza
Assistant Professor
Department of Computer Science
GC University Lahore

Lecture 2
Introduction to SE
Slide Set to accompany
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Used w. extensive rework,
but later abandoned
20%
Used as delivered
2%
Usable w. rework
3%
Delivered, but never
successfully used
45%
Paid for, but
not delivered
30%
Take a look at the Standish Report (The “Chaos” Report)

 Software is:
 (1) instructions (computer programs) that when
executed provide desired features, function, and
performance;
 (2) data structures that enable the programs to
adequately manipulate information and
 (3) documentation that describes the operation and
use of the programs.

 Software is developed or engineered, it is not
manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward
component-based construction, most software
continues to be custom-built.

 system software
 application software
 engineering/scientific software
 embedded software
 product-line software
 WebApps (Web applications)
 AI software

 Open world computing—pervasive, distributed computing
 Ubiquitous computing—wireless networks
 Netsourcing—the Web as a computing engine
 Open source—”free” source code open to the computing community (a
blessing, but also a potential curse!)
 Also … (see Chapter 31)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies

 Why must it change
 software must be adapted to meet the needs of new
computing environments or technology.
 software must be enhanced to implement new business
requirements.
 software must be extended to make it interoperable with
other more modern systems or databases.
 software must be re-architected to make it viable within
a network environment.

 Some realities:
 a concerted effort should be made to understand the
problem before a software solution is developed
 design becomes a pivotal activity
 software should exhibit high quality
 software should be maintainable
 The seminal definition:
 [Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works
efficiently on real machines.

 The IEEE definition:
 Software Engineering: (1) The application of a
systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software;
that is, the application of engineering to software. (2)
The study of approaches as in (1).

Software Engineering
a “quality” focus
process model
methods
tools

 Analysis: Understand the nature of the problem and break
the problem into pieces
 Synthesis: Put the pieces together into a large structure
For problem solving we use
 Techniques (methods):
 Formal procedures for producing results using some well-
defined notation
 Methodologies:
 Collection of techniques applied across software development
and unified by a philosophical approach
 Tools:
 Instrument or automated systems to accomplish a technique

 Process framework
 Framework activities
 work tasks
 work products
 milestones & deliverables
 QA checkpoints
 Umbrella Activities

 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

• A generic process framework
for software engineering
defines five framework activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
• In addition, a set of umbrella
activities are applied throughout
the process
• Project tracking and control
• Risk management
• Quality assurance
• Configuration management
• Technical reviews
How the framework activities and the actions and tasks that occur
within each activity are organized with respect to sequence and time?

 the overall flow of activities, actions, and tasks and the
interdependencies among them
 the degree to which actions and tasks are defined within each
framework activity
 the degree to which work products are identified and required
 the manner which quality assurance activities are applied
 the manner in which project tracking and control activities are applied
 the overall degree of detail and rigor with which the process is
described
 the degree to which the customer and other stakeholders are
involved with the project
 the level of autonomy given to the software team
 the degree to which team organization and roles are prescribed

 Polya suggests:
1.Understand the problem (communication and analysis).
2.Plan a solution (modeling and software design).
3.Carry out the plan (code generation).
4.Examine the result for accuracy (testing and quality
assurance).

22
 Who has a stake in the solution to the problem?
 That is, who are the stakeholders?
 What are the unknowns?
 What data, functions, and features are required to
properly solve the problem?
 Can the problem be compartmentalized?
 Is it possible to represent smaller problems that may
be easier to understand?
 Can the problem be represented graphically?
 Can an analysis model be created?

 Have you seen similar problems before?
 Are there patterns that are recognizable in a potential solution? Is there
existing software that implements the data, functions, and features that
are required?
 Has a similar problem been solved?
 If so, are elements of the solution reusable?
 Can sub-problems be defined?
 If so, are solutions readily apparent for the sub-problems?
 Can you represent a solution in a manner that leads to effective
implementation?
 Can a design model be created?

 Does the solution conform to the plan?
 Is source code traceable to the design model?
 Is each component part of the solution provably
correct?
 Has the design and code been reviewed, or better,
have correctness proofs been applied to algorithm?

 Is it possible to test each component part of the
solution?
 Has a reasonable testing strategy been implemented?
 Does the solution produce results that conform to the
data, functions, and features that are required?
 Has the software been validated against all
stakeholder requirements?

 1: The Reason It All Exists
 2: KISS (Keep It Simple, Stupid!)
 3: Maintain the Vision
 4: What You Produce, Others Will Consume
 5: Be Open to the Future
 6: Plan Ahead for Reuse
 7: Think!

27
 SafeHome:
 Every software project is precipitated by some
business need—
 the need to correct a defect in an existing application;
 the need to the need to adapt a ‘legacy system’ to a
changing business environment;
 the need to extend the functions and features of an existing
application, or
 the need to create a new product, service, or system.

 Heterogeneity
 Increasingly, systems are required to operate as
distributed systems across networks that include
different types of computer and mobile devices.
 Business and social change
 Business and society are changing incredibly quickly as
emerging economies develop and new technologies
become available. They need to be able to change their
existing software and to rapidly develop new software.
 Security and trust
 As software is intertwined with all aspects of our lives, it
is essential that we can trust that software.

 Management myths
 Standards and procedures for building software
 Add more programmers if behind the schedule
 Customer myths
 A general description of objectives enough to start coding
 Requirements may change as the software is flexible
 Practitioner myths
 Task accomplished when the program works
 Quality assessment when the program is running
 Working program the only project deliverable

 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 behaviour is more than simply upholding the
law but involves following a set of principles that are
morally correct.

 Confidentiality
 Engineers should normally respect the confidentiality of
their employers or clients irrespective of whether or not
a formal confidentiality agreement has been signed.
 Competence
 Engineers should not misrepresent their level of
competence. They should not knowingly accept work
which is outwith their competence.

 Intellectual property rights
 Engineers should be aware of local laws governing the use of
intellectual property such as patents, copyright, etc. They should be
careful to ensure that the intellectual property of employers and
clients is protected.
 Computer misuse
 Software engineers should not use their 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).

 Pressman Slides
 Sommerville Slides
 Whitten-Bentley Slides

Lecture 1 SE.pptx

More Related Content

Similar to Lecture 1 SE.pptx

More from MaryamMahjabeenYouni

Recently uploaded

Lecture 1 SE.pptx