You are on page 1of 35

Chapter -1

Importance of Software Engineering:


Software’s Dual Role
 Software is a product
 Delivers computing potential of hardware and networks
 Transforms information :Produces, manages, acquires,
modifies, displays, or transmits information
 Software is a vehicle for delivering a product
 Supports or directly provides system functionality
 Controls other programs (e.g., an operating system)
 Effects communications (e.g., networking software)
 Helps build other software (e.g., software tools)
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
What is Software?
Software is a logical rather than a physical system element. Therefore,
software has characteristics that are considerably different than those of
hardware.
 software is engineered, not manufactured
 software doesn’t wear out
 software is complex
teams of software specialists, each focusing on one
part of the technology required to deliver a complex
application.
Hardware vs Software
Hardware Software

 Manufactured Developed/engineered
 Wears out  Deteriorates
 Built using  Custom built
components  Complex
 Relatively simple
Manufacturing vs. Development
 Once a hardware product has been manufactured, it is difficult
or impossible to modify. In contrast, software products are
routinely modified and upgraded.
 In hardware, hiring more people allows you to accomplish
more work, but the same does not necessarily hold true in
software engineering.
 Unlike hardware, software costs are concentrated in design
rather than production.
Wear vs. Deterioration

Hardware wears out over time


Wear vs. Deterioration

Software deteriorates over time


Component Based vs. Custom Built

 Hardware products typically employ many standardized


design components.
 Most software continues to be custom built.
 The software industry does seem to be moving (slowly)
toward component-based construction.
The Cost of Change

60-100x

1.5-6x
1x

Definition Development After release


Software costs

 Software costs often dominate system costs. The costs of


software on a PC are often greater than the hardware cost
 Software costs more to maintain than it does to develop. For
systems with a long life, maintenance costs may be several
times development costs
 Software engineering is concerned with cost-effective software
development
Software Poses Challenges

 How do we ensure the quality of the software that we produce?


 How do we meet growing demand and still maintain budget
control?
 How do we upgrade an aging “Software plant?”
 How do we avoid disastrous time delays?
 How do we successfully institute new software technologies?
What is software engineering?

 Software engineering is an engineering discipline which is


concerned with all aspects of software production
 Software engineers should
 adopt a systematic and organised approach to their work and
 use appropriate tools and techniques
 depending on the problem to be solved, the development
constraints and the resources available
Software engineering vs. Computer
science

 Computer science is concerned with theory and fundamentals;


software engineering is concerned with the practicalities of
developing and delivering useful software
 Computer science theories are currently insufficient to act as a
complete underpinning for software engineering
Software engineering vs. System
engineering
 System engineering is concerned with all aspects of computer-
based systems development including hardware, software and
process engineering. Software engineering is part of this
process
 System engineers are involved in system specification,
architectural design, integration and deployment
What are the attributes of good
software?

 The software should deliver the required functionality and


performance to the user and should be maintainable,
dependable and usable
 Maintainability
 Software must evolve to meet changing needs
 Dependability
 Software must be trustworthy
 Efficiency
 Software should not make wasteful use of system resources
 Usability
 Software must be usable by the users for which it was
designed
What are the key challenges facing
software engineering?
 Coping with legacy systems, coping with increasing diversity
and coping with demands for reduced delivery times
 Legacy systems
 Old, valuable systems must be maintained and updated
 Heterogeneity
 Systems are distributed and include a mix of hardware and
software
 Delivery
 There is increasing pressure for faster delivery of software
Software Applications
 system software
 application software
 engineering/scientific
software
 embedded software
 product-line software
 WebApps (Web applications)
 AI software
System Software
 Service other programs
 Usually:
 heavy interaction with computer hardware,
 heavy usage by multiple users,
 concurrent operation
 scheduling, resource sharing, process management,

 complex data structures,


 multiple external interfaces
Application Software
 Standalone programs that solve a specific business need.
 Conventional data processing
 Control business functions in real-time
Engineering/Scientific software
 Numerical algorithms
 Newly: real-time and system software characteristics

Including:
 Astronomy
 Volcano logy
 Automotive stress analysis
 Space shuttle orbital dynamics
 Molecular biology
Embedded Software
 Resides within a product or system
Product-line software
 Provide a specific capability for use by many different
customers

 Inventory control, word processing, spreadsheets, computer


graphics, …
WebApps (Web applications)
 E- commerce and B2B applications
AI Software
Robotics, expert systems,
pattern recognition (image and
voice), artificial neural
networks, theorem proving, and
game playing
Software – New Categories
 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


Legacy Software
Why must it change?

 It must be fixed to eliminate errors.


 It must be enhanced to implement new functional and non-
functional requirements
 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.
Software Evolution
 The Law of Continuing Change (1974): E-type systems must
be continually adapted else they become progressively less
satisfactory.
 The Law of Increasing Complexity (1974): As an E-type
system evolves its complexity increases unless work is done to
maintain or reduce it.
 The Law of Self Regulation (1974): The E-type system
evolution process is self-regulating with distribution of product
and process measures close to normal.
 The Law of Conservation of Organizational Stability (1980):
The average effective global activity rate in an evolving E-type
system is invariant over product lifetime.
Software Evolution
 The Law of Conservation of Familiarity (1980): As an E-type
system evolves all associated with it, developers, sales
personnel, users, for example, must maintain mastery of its
content and behavior to achieve satisfactory evolution.
 The Law of Continuing Growth (1980): The functional content
of E-type systems must be continually increased to maintain
user satisfaction over their lifetime.
 The Law of Declining Quality (1996): The quality of E-type
systems will appear to be declining unless they are rigorously
maintained and adapted to operational environment changes.
 The Feedback System Law (1996): E-type evolution processes
constitute multi-level, multi-loop, multi-agent feedback
systems and must be treated as such to achieve significant
improvement over any reasonable base.
Software Myths

 Affect managers, customers (and other non-technical


stakeholders) and practitioners
 Are believable because they often have elements of truth,
but …
 Invariably lead to bad decisions,
therefore …
 Insist on reality as you navigate your way through
software engineering
Software Myths
 If we get behind schedule, we can add more programmers and
catch up.
 A general statement about objectives is sufficient to begin
building programs.
 Change in project requirements can be easily accommodated
because software is flexible.
 Once we write a working program, we’re done.
 Until I get the program running, I have no way of assessing its
quality.
 The only deliverable work product for a successful project is
the working program.
 Software engineering will make us create too much
documentation and will slow us down.
Management Myths
 “We already have a book of standards and procedures for
building software. It does provide my people with everything
they need to know …”
 “If my project is behind the schedule, I always can add more
programmers to it and catch up …”
(a.k.a. “The Mongolian Horde concept”)
 “If I decide to outsource the software project to a third party, I
can just relax: Let them build it, and I will just pocket my
profits …”
Customer Myths
 “A general statement of objectives is sufficient to begin
writing programs - we can fill in the details later …”

 “Project requirements continually change but this change can


easily be accommodated because software is flexible …”
Practitioner’s Myths
 “Let’s start coding ASAP, because once we write the program
and get it to work, our job is done …”

 “Until I get the program running, I have no way of assessing its


quality …”

 “The only deliverable work product for a successful project is


the working program …”

 “Software engineering is baloney. It makes us create tons of


paperwork, only to slow us down …”

You might also like