DEPARTMENT OF CSE, CSIT & AI&DS
COURSE NAME – ADAPTIVE SOFTWARE
ENGINEERING
COURSE CODE – 22CI2001
TOPIC:
SOFTWARE IEEE DEFINITION
AIM OF THE SESSION
To familiarize students with the basic concept of Software and Software Engineering
INSTRUCTIONAL OBJECTIVES LEARNING OUTCOMES
This Session is designed to: At the end of this session, you should be able to:
1. Demonstrate Software Engineering Definition - 1. Define Software Engineering Definition - IEEE
IEEE 2. Describe the Software Process and process
2. Describe A Layered Technology framework activity
3. List out the Software Process and process 3. Summarize Umbrella Activities, Software
framework activity Engineering Practice, and Software Myths
4. Describe the Umbrella Activities , Software
Engineering Practice, Software Myths
2
AGENDA
Software Engineering Definition - IEEE
A Layered Technology
Software Process
Process framework Activities
Umbrella Activities
Software Engineering Practice
Software Myths
3
Software Engineering
• 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
Definition:
• Software engineering is a detailed study of engineering to the design, development and maintenance of
software.
• Software engineering was introduced to address the issues of low-quality software projects.
• Problems arise when a software generally exceeds timelines, budgets, and reduced levels of quality
4
THE IEEE DEFINITION:
• Software Engineering:
The application of a
Systematic,
Disciplined,
Quantifiable approach
to the development, operation, and maintenance of
software;
that is, the application of engineering to software.
5
A Layered Technology
tools
methods
process model
a “quality” focus
Software Engineering
Software engineering is fully a layered technology, to develop software we need to
go from one layer to another. All the layers are connected and each layer demands
the fulfillment of the previous layer. Fig: The diagram shows the layers of software
development
6
A Layered Technology
Quality: The organization is commitment to quality
Process: Manages the control of software projects Ensures quality, establishes milestones,
manages changes
Methods: Provide technical ways for building software i.e. Communication, requirement analysis,
design modelling, program construction, testing, and support
Tools: Provide automated or semi-automated support for the Process & Methods
7
The Software Process
A Process is collection of activities, actions, and tasks that are
performed when some work product is to be created
• Activity-Strives to achieve a broad objective
(eg: communication with stakeholders)
• Actions- encompasses a set of tasks that produce a major work
product (eg: architectural design)
• Task- focusses on small, but well-defined objective that
produces a tangible outcome (eg: conduct a unit test)
8
PROCESS FRAMEWORK ACTIVITIES
■ Communication
■ Planning
■ Modeling
■ Analysis of requirements
■ Design
■ Construction
■ Code generation
■ Testing
■ Deployment
9
PROCESS FRAMEWORK ACTIVITIES(CONT.)
Communication: communicate with customer to understand objectives and gather requirements
Planning: creates a “map” that defines the work by describing tasks, risks and resources, work
products and work schedule.
Modeling: Create a “sketch”, what it looks like architecturally, how the essential parts fit together
and other characteristics.
Construction: code generation and the testing.
Deployment: Delivered to the customer who evaluates the products & provides feedback based
on the evaluation.
10
Process framework Activities(cont.)
• 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.
11
UMBRELLA ACTIVITIES
What are umbrella activities in software engineering?
• Software engineering is a collection of interconnected phases. These steps are expressed or
available in different ways in different software process models. Umbrella activities are a
series of steps or procedures followed by a software development team to maintain the
progress, quality, changes, and risks of complete development task
Need for umbrella activities
• In general, umbrella activities are applied throughout a software project and help a software
team manage and control progress, quality, change, and risk. Since the software
engineering process is not a rigid regimen that must be followed precisely by a software team,
the process has a lot of room for adaptation.
12
UMBRELLA ACTIVITIES
• Complete the five process framework activities and help team manage and control progress, quality, change, and risk.
• Software project tracking & control: assess progress against the plan and take actions to maintain the schedule.
• Risk management: assesses risks that may affect the outcome and quality.
• Software quality assurance: defines and conduct activities to ensure quality.
• Technical reviews: assesses work products to uncover and remove errors before going to the next activity.
• Measurement: define and collects process, project, and product measures to ensure stakeholder’s needs are met.
• Software configuration management: manage the effects of change throughout the software process.
• Reusability management: defines criteria for work product reuse and establishes mechanism to achieve reusable components.
• Work product preparation and production: create work products such as models, documents, logs, forms and lists.
13
Software Engineering Practice
• How does the practice of software engineering fit in the process activities mentioned above? Namely,
• Communication,
• Planning,
• Modeling,
• Construction
• Deployment.
The essence of problem-solving is outlined in 4 points:
Understand the problem (communication and analysis).
Plan a solution (modeling and software design).
Carry out the plan (code generation).
Examine the result for accuracy (testing and quality assurance).
14
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?
15
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?
16
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 an algorithm?
17
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?
18
SOFTWARE MYTHS
■ Myth means, a false belief or idea
■ 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
19
[Link] MYTHS
Myth1:
• “We already have a book of standards and procedures for building software. It does
provide my people with everything they need to know …”
Fact:
• Software experts do not know all the requirements for the software development.
• And all existing processes are incomplete as new software development is based on
new and different problem.
20
MANAGEMENT MYTHS CONT..
Myth2:
• The addition of the latest hardware programs will improve the software development.
Fact:
• The role of the latest hardware is not very high on standard software development; instead (CASE:
Computer Aided Software Engineering) Engineering tools help the computer, they are more
important than hardware to produce quality and productivity.
• Hence, the hardware resources are misused.
21
Management Myths cont..
Case tools can be broadly classed into these broader areas:
• Requirement Analysis Tool.
• Structure Analysis Tool.
• Software Design Tool.
• Code Generation Tool.
• Test Case Generation Tool.
• Document Production Tool.
• Reverse Engineering Tool.
22
Myth 3:
• With the addition of more people and program planners to Software development can help meet
project deadlines (If lagging behind).
Fact:
• If software is late, adding more people will merely make the problem worse. This is because the
people already working on the project now need to spend time educating the new comers, and are
thus taken away from their work.
• The newcomers are also far less productive than the existing software engineers, and so the work
put into training them to work on the software does not immediately meet with an appropriate
reduction in work.
23
2. CUSTOMER MYTHS
• The customer can be the direct users of the software, the technical team, marketing / sales
department, or other company.
Myth1:
• “A general statement of objectives is sufficient to begin writing programs - we can fill in the
details later …”
Fact:
• Official and detailed description of the database function, ethical performance,
communication, structural issues and the verification process are important.
• Unambiguous requirements (usually derived iteratively) are developed only through effective
and continuous communication between customer and developer.
24
CUSTOMER MYTHS CONT…
Myth 2:
• Software requirements continually change, but change can be easily accommodated because
software is flexible
Fact:
• It is true that software requirements change, but the impact of change varies with the time at which
it is introduced.
• When requirements changes are requested early (before design or code has been started), the cost
impact is relatively small. However, as time passes, the cost impact grows rapidly—resources have
been committed, a design framework has been established, and change can cause that require
additional resources and major design modification.
25
CUSTOMER MYTHS CONT…
26
3. PRACTITIONER’S MYTHS
Myth1:
• “Let’s start coding ASAP, because once we write the program and get it to
work, our job is done …”
Fact:
• It is true that every 60-80% effort goes into the maintenance phase (as of the
latter software release).
• Efforts are required, where the product is available first delivered to
customers.
27
PRACTITIONER’S MYTHS CONT..
Myth 2:
• There is no other way to achieve system quality, until it is “running”.
Fact:
• Systematic review of project technology is the quality of effective software verification method. These
updates are quality filters and more accessible than test.
Myth 3:
• An operating system is the only product that can be successfully exported project.
Fact:
• A working system is not enough, the right document brochures and booklets are also required to provide
guidance & software support.
28
PRACTITIONER’S MYTHS CONT..
Myth 4:
• Engineering software will enable us to build powerful and unnecessary document &
always delay us.
Fact:
• Software engineering is not about creating documents. It is about creating a quality
product. Better quality leads to reduced rework. And reduced rework results in faster
delivery times
29
SELF-ASSESSMENT QUESTIONS
1. Define Software Engineering.
2. What is the need of Umbrella Activities.
3. What are different Layers of Software Engineering.
4. What are Process framework Activities.
5. What are different activities comes under Modeling face.
6. Need of Technical reviews in software development.
7. Need of Reusability management in software development process.
8. Need of Software quality assurance in software development process.
9. Define Myth ?
10. How many types of Myths available.
11. What are myths comes under Management Myths.
12. What are myths comes under Customer Myths.
13. What are myths comes under Practitioner’s Myths.
30
REFERENCES FOR FURTHER LEARNING OF THE
SESSION
TEXTBOOKS:
1. Roger [Link], “Software Engineering – A Practitioner’s Approach” 7th Edition, Mc Graw Hill,(2014).
2. Ian Sommerville, “Software Engineering”, Tenth Edition, Pearson Education, (2015).
3. Agile Software Development Ecosystems, Jim Highsmith, Addison Wesley; ISBN: 0201760436; 1 st edition
Reference Book
Agile Modelling: Effective Practices for Extreme Programming and the Unified Process Scott Amber John Wiley &
Sons; ISBN: 0471202827; 1st edition.
WEB REFERNCES/MOOCS:
[Link]
[Link]
[Link]
[Link]
31
THANK YOU
Team – ADAPTIVE SOFTWARE ENGINEERING
32
