Here are some key points from Unit 1: - Software is computer programs, data structures, and documentation. Software engineering is the systematic development and maintenance of software. - A software process provides a framework for development activities like communication, planning, modeling, construction and deployment. It establishes quality practices. - Legacy software supports core functions but is outdated, poorly designed and documented. It is costly to replace but also to maintain. - Common software myths include thinking requirements can change freely, documentation is unnecessary, or that quality is only important after coding. These undermine good practices. - A process framework provides structure while methods and tools support specific technical tasks. Processes must balance control and flexibility for different projects.

1. 1
Introduction to Software Engineering
Preeti Mishra
Course Instructor

2. Basics:
Software & Software Engineering

3. What is
Software?
The product that software professionals build and then support
over the long term.
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.

4. Software products
• Generic products
– Stand-alone systems that are
marketed and sold to any customer
who wishes to buy them.
– Examples – PC software such as
editing, graphics programs, project
management tools
• Customized products
– Software that is commissioned by a
specific customer to meet their own
needs.
– Examples – embedded control
systems, air traffic control software,
traffic monitoring systems.

5. Software Categories
• 1. System software: such as compilers, editors, file management utilities
• 2. Application software: stand-alone programs for specific needs.
• 3. Engineering/scientific software: Characterized by “number
crunching”algorithms. such as automotive stress analysis, molecular biology,
orbital dynamics etc
• 4. Embedded software resides within a product or system. (key pad control of a
microwave oven, digital function of dashboard display in a car)
• 5. Product-line software focus on a limited marketplace to address mass
consumer market. (word processing, graphics, database management)
• 6. WebApps (Web applications) network centric software. As web 2.0 emerges,
more sophisticated computing environments is supported integrated with remote
database and business applications.
• 7. AI software uses non-numerical algorithm to solve complex problem.
Robotics, expert system, pattern recognition game playing

6. Software—New Categories
• Open world computing—pervasive, ubiquitous, distributed computing
due to wireless networking. How to allow mobile devices, personal
computer, enterprise system to communicate across vast network.
• Netsourcing—the Web as a computing engine. How to architect simple
and sophisticated applications to target end-users worldwide.
• 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

7. Why Software is Important?
• The economies of ALL developed nations
are dependent on software.
• More and more systems are software
controlled ( transportation, medical,
telecommunications, military, industrial,
entertainment,)
• Software engineering is concerned with
theories, methods and tools for
professional software development.
• Expenditure on software represents a
significant fraction of GNP in all developed
countries.

8. Software costs
• Software costs often dominate computer 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.

9. Features of Software?
• Its characteristics that make it different
from other things human being build.
Features of such logical system:
• Software is developed or engineered, it is
not manufactured in the classical sense
which has quality problem.
• Software doesn't "wear out.” but it
deteriorates (due to change). Hardware has
bathtub curve of failure rate ( high failure rate
in the beginning, then drop to steady state, then
cumulative effects of dust, vibration, abuse occurs).
• Although the industry is moving toward
component-based construction, most
software continues to be custom-built.
• Modern reusable components
encapsulate data and processing into
software parts to be reused by different
programs. E.g. graphical user interface,
window, pull-down menus in library etc.

10. Wear vs. Deterioration
10
idealizedcurve
change
actualcurve
Failure
rate
Time
increasedfailure
rate due toside effects

11. 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).
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.
Software Engineering Definition

12. Importance of Software Engineering
• More and more, individuals and society rely on advanced software
systems. We need to be able to produce reliable and trustworthy
systems economically and quickly.
• It is usually cheaper, in the long run, to use software engineering
methods and techniques for software systems rather than just write
the programs as if it was a personal programming project. For most
types of system, the majority of costs are the costs of changing the
software after it has gone into use.

13. FAQ about software engineering
Question Answer
What is software? Computer programs, data structures and associated
documentation. Software products may be developed for
a particular customer or may be developed for a general
market.
What are the attributes of good software? Good software should deliver the required functionality
and performance to the user and should be
maintainable, dependable and usable.
What is software engineering? Software engineering is an engineering discipline that is
concerned with all aspects of software production.
What is the difference between software
engineering and computer science?
Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities
of developing and delivering useful software.
What is the difference between software
engineering and 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 more general process.

14. Essential attributes of good
software
Product characteristic Description
Maintainability • Software should be written in such a way so that it can evolve to meet the
changing needs of customers.
• This is a critical attribute because software change is an inevitable
requirement of a changing business environment.
Dependability and security • Software dependability includes a range of characteristics including
• reliability,
• security and
• safety.
• Dependable software should not cause physical or economic damage in the
event of system failure.
• Malicious users should not be able to access or damage the system.
Efficiency • Software should not make wasteful use of system resources such as memory
and processor cycles.
• Efficiency therefore includes responsiveness, processing time, memory
utilisation, etc.
Acceptability • Software must be acceptable to the type of users for which it is designed.
• This means that it must be understandable, usable and compatible with other
systems that they use.

16. Questions!!

17. Software Process

18. A Layered Technology
aa “quality” focus“quality” focus
process modelprocess model
methodsmethods
toolstools
 Any engineering approach must rest on organizational commitment to quality which fosters a
continuous process improvement culture.
 Process
 Method
 Tools

19. Process, Methods, and Tools
• Process
– Provides the glue that holds the layers together; enables rational and
timely development; provides a framework for effective delivery of
technology; forms the basis for management; provides the context
for technical methods, work products, milestones, quality measures,
and change management
• Methods
– Provide the technical "how to" for building software; rely on a set of
basic principles; encompass a broad array of tasks; include modeling
activities
• Tools
– Provide automated or semi-automated support for the process and
methods (i.e., CASE tools)

20. Process??
• (Webster) A system of operations in producing
something; a series of actions, changes, or functions
that achieve an end or a result
• (IEEE) A sequence of steps performed for a given
purpose

21. What is a Software Process?
• (SEI) A set of activities, methods, practices, and
transformations that people use to develop and maintain
software and the associated products (e.g., project plans,
design documents, code, test cases, and user manuals)
• As an organization matures, the software process becomes
better defined and more consistently implemented throughout
the organization
• Software process maturity is the extent to which a specific
process is explicitly defined, managed, measured, controlled,
and effective

22. Five Activities of a Generic Process
framework
• Communication: communicate with customer to understand objectives
and gather requirements
• Planning: creates a “map” defines the work by describing the tasks, risks
and resources, work products and work schedule.
• Modeling: Create a “sketch”, what it looks like architecturally, how the
constituent parts fit together and other characteristics.
• Construction: code generation and the testing.
• Deployment: Delivered to the customer who evaluates the products and
provides feedback based on the evaluation.
• These five framework activities can be used to all software development
regardless of the application domain, size of the project, complexity of
the efforts etc, though the details will be different in each case.
• For many software projects, these framework activities are applied
iteratively as a project progresses. Each iteration produces a software
increment that provides a subset of overall software features and
functionality.

23. Umbrella Activities
Complement the five process framework activities and help team manage and
control progress, quality, change, and risk.
1. Software project tracking and control: assess progress against the plan and
take actions to maintain the schedule.
2. Risk management: assesses risks that may affect the outcome and quality.
3. Software quality assurance: defines and conduct activities to ensure quality.
4. Technical reviews: assesses work products to uncover and remove errors
before going to the next activity.
5. Measurement: define and collects process, project, and product measures
to ensure stakeholder’s needs are met.
6. Software configuration management: manage the effects of change
throughout the software process.
7. Reusability management: defines criteria for work product reuse and
establishes mechanism to achieve reusable components.
8. Work product preparation and production: create work products such as
models, documents, logs, forms and lists.

24. The Essence of Practice
• How does the practice of software engineering fit in the process activities
mentioned above? Namely, communication, planning, modeling,
construction and deployment.
• George Polya outlines the essence of problem solving, 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).

25. 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?

26. Plan the 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?

27. Carry Out the Plan
• Does the solutions 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?

28. Examine the Result
• 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?

29. Software Myths

30. Software Myths
Erroneous beliefs about software and the process that is used
to build it.
•Affect managers, customers (and other non-technical
stakeholders) and practitioners
•Many people recognize the fallacy of the myths. Regrettably,
habitual attitudes and methods
•Poor management and technical practices, even when reality
dictates a better approach.

31. Management Myths
• We already have standards and procedures for building software;
isn’t that enough?
– How widely used is it?
– How relevant to the team?
– How useful to the project?
• If we’re behind schedule, we’ll just add more programmers to
catch up
– “Adding people to a late project makes it later” [Brooks]
– Ramp-up time
– Interference
• If I outsource a project, I can just relax
– Management issues are much more difficult, and if not
understood, will sink the project

32. Customer Myths
• A general statement of work is sufficient to kick off the
project, and we can fill in the details later
• Requirements can change, and that’s OK because software is so
flexible
-Most software project failures can be traced to inadequacy of
requirement specifications

33. Software Engineers’ Myths
• Once the program is written, I’m done
– Between 60-80% of effort expended after
delivery
• Until the program is written, quality is
uncertain
– Formal design reviews
– Formal code reviews
– Test-first approaches
– Prototyping to verify design and structure
– Prototyping to validate requirements
• The only deliverable is the program itself
– Lots of documentation: installation guides,
usage guides, maintenance guides, API
defintions and examples

34. Software Engineers’ Myths
• Documentation is Software-Engineering busy work
– Focus is on quality, not quantity
– Documentation can be hard for engineers to write, just as
C++ may be difficult for poets.

35. Legacy Software

36. What is Legacy System
• In computing, a legacy system is an old method, technology,
computer system, or application program, "of, relating to, or
being a previous or outdated computer system.“
• Often a pejorative term, referencing a system as "legacy" often
implies that the system is out of date or in need of replacement.

37. Legacy Software -
Characteristics
• Support core business functions
• Have longevity and business criticality
• Exhibit poor quality
– Convoluted code, poor documentation, poor testing, poor change
management

38. Why Organizations can have compelling reasons for keeping a legacy
S/W
• The system works satisfactorily, and the owner sees no reason to change it.
• The costs of redesigning or replacing the system are prohibitive because it
is large, monolithic, and/or complex.
• Retraining on a new system would be costly in lost time and money,
compared to the anticipated appreciable benefits of replacing it
• The system requires near-constant availability, so it cannot be taken out of
service, and the cost of designing a new system
• The user expects that the system can easily be replaced when this becomes
necessary.
• Newer systems perform undesirable (especially for individual or non-
institutional users)

39. Problems posed by legacy Software
• If legacy software runs on only antiquated hardware, the cost of maintaining
the system may eventually outweigh the cost of replacing both the software
and hardware unless
• These systems can be hard to maintain, improve, and expand because
there is a general lack of understanding of the system; the staff who were
experts on it have retired or forgotten what they knew about it, and staff who
entered the field after it became "legacy" never learned about it in the first
place. This can be worsened by lack or loss of documentation.
• Legacy systems may have vulnerabilities in older operating systems or
applications due to lack of security patches being available or applied.
• Integration with newer systems may also be difficult because new software
may use completely different technologies.

40. Reasons for Evolving the Legacy
Software
• (Adaptive) Must be adapted to meet the needs of new
computing environments or more modern systems, databases,
or networks
• (Perfective) Must be enhanced to implement new business
requirements
• (Corrective) Must be changed because of errors found in the
specification, design, or implementation
(Note: These are also the three
major reasons for any software
maintenance)

41. End of Unit 1:
Importance of Software Engineering

42. FAQ on Unit 1
Type Examples
What/Define Software, Software Engineering, legacy Software,
software process…..
list Software Myths, legacy s/w characteristics, generic
process framework activities, umbrella activities…
Reason/ Why Use Software Engg, use process framework, use of
legacy s/w, each s/w myth…
And in the similar way you can think of differences, advantages, limitations,
examples ….. On these topics