Module 1 Introduction to Software Engineering Badariah Solemon 2010 CSEB233 Fundamentals of Software Engineering

Module 1Introduction to Software Engineering

Badariah Solemon 2010

CSEB233Fundamentals of

Software Engineering

Objectives

• To define SE-related terminologies: ‘software’, ‘software engineering’, etc.

• To explain several software application domain.

• To describe the four Polya’s essence of SE practices.

• To explain the seven Hooker’s SE principles.• To describe several software myths.


What is ‘software’?

• 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.


Example Software


Software …• Is developed or engineered, it is not

manufactured in the classical sense.– How things are manufactured?– How software are developed or engineered?

• Software doesn't "wear out" but it deteriorates because of errors do occur in software due to errors in requirements, design, construction or through out the development process.

• Most software continues to be custom-built, although the industry is moving toward component-based construction.


Wear vs. Deterioration

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects

idealized curve

change

actual curve

Failurerate

Time

increased failurerate due to side effects


Software Application Domain System software Application software Engineering/scientific software Embedded software Product-line software Web applications (WebApps) AI software


Software Application Domain Matrix

Domain Characteristic Example Software

System Software • Generally, programs written to service other programs

• Heavy interaction with computer hardware

• Heavy usage by multiple users• Concurrent operation that

requires scheduling• Resource sharing and

sophisticated process management

• Complex data structures• Multiple external interfaces

• OS – MS Windows, Linux Ubuntu

• Drivers – printer driver• Networking software -

wireless networking software

• Telecommunication software – messaging system such as sms, mms

• Compilers – Borland C++, Turbo C

Application Software • Point-of-sale (POS)


Software Application Domain Matrix (cnt’d)

Domain Characteristic Example Software

Engineering/Scientific Software

• Flight simulator

Embedded Software • Software to control robots’ movement

Production-line Software

• Ms Word

WebApps • Uniten Online Application System

AI Software • Expert system – Diagnostic Medical expert system


New Software Domain 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!)

Data mining Grid computing Cognitive machines Software for nanotechnologies


The realities..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.


What is ‘Software Engineering’?

• IEEE: – (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).


SE realities …

• SE is a join effort should be made to understand the problem before a software solution is developed.

• Design, which is a crucial activity.• Software should exhibit high

quality.• Software should be maintainable.


Layers in SE

a “quality” focusa “quality” focus

process modelprocess model

methodsmethods

toolstools


Layer: Process Model• Software process is a collection of

activities, actions, and tasks that are performed to develop or maintain a software product.

• Framework activities: – generic activities that are applicable to all

software projects, regardless of their size or complexity.

• Umbrella activities:– complementary activities applied

throughout a software project and help manage and control progress, quality, change, and risk.

process modelprocess modelBadariah Solemon 2010

Essential SE Practices

• Polya suggests:1. Understand the problem (communication and

modeling).2. Plan a solution (planning and design).3. Carry out the plan (construction and

deployment).4. Examine the result for accuracy (testing and

quality assurance).


Understand the problem• 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?


Plan a solution• 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 subproblems be defined? If so, are solutions readily apparent for the subproblems?

• Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?


Carry out the plan

• 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?


Examine the result for accuracy

• 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?


Hooker’s General SE Principles

1. The Reason It All Exists2. KISS (Keep It Simple, Stupid!)3. Maintain the Vision4. What You Produce, Others Will Consume 5. Be Open to the Future 6. Plan Ahead for Reuse7. Think!


1. The Reason It All Exists

• software exists to provide value to its users and all decision should be made with this in mind.


2. KISS

• There are many factors to consider in any design effort.

• Thus, all software design should be as simple as possible but not simpler to ease understanding and maintenance of the software/system.


3. Maintain the Vision

• because a clear vision is essential to the success of a software project.

• Compromising the architectural vision of a software systems weakens and break even well-designed systems.


4. What You Produce, Others Will Consume

• Consume - (use, maintain, document or depend on)

• So, always specify, design, and implement knowing others will have to understand what you are doing.


5. Be Open to the Future

• True “industrial-strength” software systems must endure long lifetime.

• Hence, design the software systems:– to solve the general problem (not just

the specific one), – to be ready to adapt to changes (in

hardware, computing platform etc), and

– to be reused.Badariah Solemon 2010

6. Plan Ahead for Reuse

• because reuse reduces the cost and increases the value of the reused components and the systems into which they are incorporated.


7. Think

• Because when you think about something (placing clear, complete thought before action), you are more likely to do it right (more importantly, the first time).


Software Myths• Software myths – erroneous beliefs about

software and the process that is used to build it.

• Misleading attitudes that have caused serious problems for managers and practitioners.

• Classifications of software myths:– Management myths– Customer myths– Practitioner myths


Management Myth

• Myth: We already have a book that’s full of

standards and procedures for building software. Won’t that provide my people with everything they need to know?

• Reality:– The book of standards may exist, but is it

used? Are practitioners’ aware of its existence? Does it reflect modern SE practices? Is it complete? Is it adaptable?


Customer Myth

• Myth: Software requirements continually change,

but change can be easily accommodated because software is flexible.

• Reality:– The impact of change varies with the time at

which it is introduced. The cost of impact of changes in early stage of software project is relative small. However, changes introduced at a later development stage may requires a lot of resources and major design modification.


Practitioner Myth

• Myth: “Once we write the program and get it

work, our job is done.”

• Reality:– Some once said the “the sooner you

begin ‘writing code’, the longer it’ll take you to get done.”


Summary• You have learned about:

– Definitions of software and software engineering.– Software deteriorates but never wear out.– Several software application domain – system software,

engineering/scientific software, AI software, embedded software, etc.

– The Polya’s essence of SE practices – understand the problem, plan a solution, execute the plan and examine the result for accuracy.

– SE principles - The Reason It All Exists; KISS (Keep It Simple, Stupid!); Maintain the Vision; What You Produce, Others Will Consume ; Be Open to the Future; Plan Ahead for Reuse; Think!

– Software myths have caused serious problems for the software industry.


References and credit:

• Contents in the slides are adopted from the book and the slides that accompanied the book by R.S. Pressman, Software Engineering: A Practitioner’s Approach, 7th. Edition, McGraw Hill, 2009.


Documents

Module 1 Introduction to Software Engineering Badariah Solemon 2010 CSEB233 Fundamentals of Software Engineering