Software Engeneering

1
20MCA24—Software Engineering
2021-2022 Batch
Expectation Setting Session

Department of Computer Applications
Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Software Engineering 2
PCC- Professional Core Course
SEMESTER – 2
[Under Outcome Based Education (OBE) and Choice Based Credit System (CBCS) Scheme]
Subject Code: 20MCA24

CIE Marks: 40 SEE Marks: 60 SEE Hours: 03
Number of Lecture Hours/Week: 03 Hours Theory and
Skill development activities (SDA)/Tutorial:02 Hours
Total Number of Lecture Hours: 50 minimum
Total Number of Teaching Hours/Module: 10 Hrs minimum
CREDITS: 04
“Teaching is more than imparting knowledge, it is inspiring change.”
Department of Computer Application 20MCA24-Software Engineering

William Arthur Ward 25 July 2022
Course Outcome (CO) 3
Course Outcomes: Students will be able to
CO1: Identify and define different requirements for the given problem and present in the IEEE format.
CO2: Use modern tool to create dynamic diagrams to represent the design for the given problem.
CO3: Draw class diagram , analyze the different types of association that exists as per the given problem
and represent them using UML notations.
CO4: Analyze the given system to identify actors, use cases to design use case diagrams for the given
problem using Rational Software Architect (RSA)/open source tool.
CO5: Design the static/dynamic models to meet application requirements of the given system and
generate code (skeleton) using the modern tool.

Module Descriptions 4
Module -1:
•Overview
•Software Process & Agile Software Development
Module -2:
•Requirements Engineering Process
•Requirements Elicitation
Module -3:
•Object Modelling Design
•Architectural Design
Module -4:
•Architectural Design and State Modelling
•Use cases
Module -5
•Planning a software Project
•Software Testing

Textbooks and Reference Books 5
Text Books:
1. Ian Sommerville: Software Engineering, 9th Edition, Pearson Education Ltd, 2011
2. Pankaj Jalote, Software Engineering, Wiley India Pvt Ltd (2010) Paul C Jorgensen Software
Testing A Craft Man’s Approach, 2nd edition, CRC Press.
3. Michel Blaha, James Rumbaugh: Object-Oriented Modelling and Design with UML, 2nd
edition, Pearson, 2007.
Reference Books:
1. Stephan R. Schach, “Object oriented software engineering”, Tata McGrawHill,2008
2. Craig Larman, Applying UML and Patterns, 3rd ed, Pearson Education,2005.
3. Roger S Pressman: Software Engineering-A Practitioners approach, 6th Edition, McGraw-Hill,
2010.

Additional Resources 6
▪ 11th International Conference on Software Engineering and Applications (SEA 2022)

▪ ACM International Conference on Software Engineering
▪ ACM Special Interest Group on Software Engineering
▪ IEEE International Conference on Software Engineering (ICSE)

Module-1 15
Overview
Introduction: Professional Software Development Attributes of good software, software engineering
diversity, IEEE/ACM code of software engineering ethics, case studies.
Software Process & Agile Software Development

Software Process models: waterfall, incremental development, reuses oriented, Process activities;
coping with change, The Rational Unified Process. Agile Methods, Plan-Driven and Agile
Development, Extreme Programming, Agile Project Management, scaling agile methods.

What is software? 16
Software is a set of instructions made in the form of written programs, procedures

or rules and associated documentation pertaining to the operation of a computer
system and that are stored in read/ write memory.
Instructions
Alphabets A,B,C,D………………………………Z
a,b,c,d……………………………….z
Digits 0,1,2,3,4,5,6,7,8,9
Special symbol

What is Software Engineering? 17
The IEEE Computer Society defines software engineering as
The application of a systematic, disciplined, quantifiable approach to the

development, operation, and maintenance of software; that is, the
application of engineering to software.

Difference of Software Engineering and Computer Science 18
• 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. ( Practicalities)
• Computer science
is concerned with theory and fundamentals

Software Categories 19
Software is often divided into Three Categories
System Software Programming Software Application Software
serves as a base for application Is a set of tools to aid is intended to perform certain tasks.
software. System software includes developers in writing Examples of application
device drivers, operating systems programs. The various software include office suites,
(OSs), compilers, disk formatters, tools available are gaming applications, database
text editors and utilities helping the compilers, linkers, systems and educational
computer to operate more debuggers, interpreters software. Application software can
efficiently. It is also responsible for and text editors. be a single program or a
managing hardware components collection of small programs. This
and providing basic non-task- type of software is what consumers
specific functions. most typically think of as
"software."

What is a System? 20
• A purposeful collection of inter-related components working together to achieve
some common objective.
• A system may include software, mechanical component, electrical and
electronic hardware and be operated by people.

Components of Software Engineering/ICT 21
Computer based System Engineering Architecture/Components of Information System
Components of ICT-Information Communication Technology

Information system 22
An information system is software that helps you organize and analyze data.
This makes it possible to answer questions and solve problems relevant to the
mission of an organization.

Types of Information System/
23
Computer Based Information System
Office Automation System

(OAS) Office Automation System(OAS) refers to the
varied computer machinery and software used to digitally
create, collect, store, manipulate, and relay office
information needed for accomplishing basic tasks

What are the attributes of Good Software? 24
Maintainability:
– Software must evolve to meet changing needs;
Dependability:
– Software must be trustworthy;
Efficiency:
– Software should not make wasteful use of system resources;
Acceptability:
– Software must accepted by the users for which it was designed. This means it must be understandable, usable
and compatible with other systems.
Useability:
Usability is the measure of a product's potential to accomplish the goals of the user. Some factors used in
determining product usability are ease-of-use, visual consistency, and a clear, defined process for evolution.

What are the attributes of Good Software? 25
Reliability:
Software Reliability is the probability of failure-free software operation for a specified period of time in a specified
environment. Software Reliability is also an important factor affecting system reliability.
Scalability:
Scalability is an attribute that describes the ability of a process, network, software or organization to grow and manage
increased demand. A system, business or software that is described as scalable has an advantage because it is more
adaptable to the changing needs or demands of its users or clients.
Portability:
Portability in high-level computer programming is the usability of the same software in different environments. The
prerequirement for portability is the generalized abstraction between the application logic and system interfaces.
Reusability:
Software reuse is the process of implementing or updating software systems using existing software components. A
good software reuse process facilitates the increase of productivity, quality, and reliability, and the decrease of costs
and implementation time.

What are the Key Challenges Facing Software Engineering? 26
Heterogeneity, delivery and trust.
• Heterogeneity
– Developing techniques for building software that can cope with heterogeneous platforms
and execution environments;
• Delivery
– Developing techniques that lead to faster delivery of software;
• Trust
– Developing techniques that demonstrate that software can be trusted by its users.

27
Professional
and
Ethical Responsibility

Professional and ethical responsibility 28
• 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.

Issues of Professional Responsibility 29
• 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 out with their competence.

Issues of Professional Responsibility 30
• 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).

ACM/IEEE Code of Ethics 31
• The professional societies in the US have cooperated to produce a code of ethical practice.
• The Code contains Eight Principles related to the behaviour of and decisions made by
professional software engineers, including practitioners, educators, managers, supervisors and
policy makers, as well as trainees and students of the profession.

Code of Ethics - Principles 32
Software engineers shall adhere to the following Eight Principles:
• Public
– Software engineers shall act consistently with the public interest.
• Client And Employer
– Software engineers shall act in a manner that is in the best interests of their client and
employer consistent with the public interest.
• Product
– Software engineers shall ensure that their products and related modifications meet the
highest professional standards possible.

• Judgment
– Software engineers shall maintain integrity and independence in their professional judgment.
• Management
– Software engineering managers and leaders shall subscribe to and promote an ethical
approach to the management of software development and maintenance.
• Profession
– Software engineers shall advance the integrity and reputation of the profession consistent with
the public interest.

• Colleagues
– Software engineers shall be fair to and supportive of their colleagues.
• Self
– Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.

Case Study-1 35
A personal insulin pump
An embedded system in an insulin pump used by diabetics to maintain

blood glucose control.

A personal insulin pump control system 36
People who suffer from diabetes use the system.

❖ Cause: The human pancreas is unable to produce sufficient quantities
Continuous Glucose Monitoring (CGM)
of a hormone called insulin. Insulin metabolizes glucose in the blood.
❖ Treatment: Regular injections of genetically engineered insulin.
❖ System: Collects data from a blood sugar sensor and calculates the
amount of insulin required to be injected.

A personal insulin control system 37
CBIS

Insulin Pump Organization
38
(Block Diagram)
Calculation based on the rate of change of blood sugar levels.
Sends signals to a micro-pump to deliver the correct dose of insulin.

A Personal Insulin Pump Activity Model 39

Insulin Pump data-flow 40

A Personal Insulin Pump Safety-Critical System 41
Safety-critical system as low blood sugars can lead to brain malfunctioning, coma and death;
high blood sugar levels Have long-term consequences such as eye and kidney damage.
The system shall be available to deliver insulin when required.

The system shall perform reliably and deliver the correct amount of insulin to counteract
the current level of blood sugar.
The system must therefore be designed and implemented to ensure that the system always
meets these requirements.

Case Study-2-Amazon vs Flipkart -Supply Chain Mechanism 42
Students
Learning
Activity
SDA-1
▪ Identify Supply Chain Model of Amazon and Flip Cart

Problem Statements: ▪ Describe How Amazon became Global Online Retail Portal
▪ Justify How Flipkart can become a Global Online Retail Portal
▪ As a Software Engineer what would you suggestion
Submission Date 19-7-2022 by 8am

Skill Development Activity(SDA)-2 43
Activity On Software Engineering Diversity

Explore Research Articles on the topics Software Engineering Diversity
Collect article from

▪ https://ieeexplore.ieee.org/Xplore/home.jsp
▪ https://www.springer.com/in
▪ https://dl.acm.org/
▪ https://www.google.com/
▪ https://scholar.google.com/
Creative Work
A. Analyse different categories of software engineering diversity
B. Justify inclusion of diversity
Submission:
1. Submission Date on 21-7-2022 by 8pm.
2. Submission to be done as Hand written and PDF copy in the google class room
3. Write your USN , Name in Capital Letter Top Right Corner in your paper
Module-1 – Part-1 Important Questions 44
1. Describe important attribute which all software product should have.

2. Discuss the various issues in software engineering professional ethics/
responsibility.
3. Explain ACM/IEEE code of ethics and suggest an appropriate example that
illustrates that clause.
4. Demonstrate how software is supportive for life critical system with real time
example. (Insulin pump embedded system)
5. Explain Software Engineering Diversity.

Module-1 – Part-2 45
Software Process
and
Agile Software Development

Module-1 – Part-2 46
Topics covered
❑ Software Process models:
❑ Waterfall,
❑ incremental development,
❑ reuses oriented,
❑ Process activities; Coping with change,
❑ The rational Unified process.
❑ Agile methods, Plan-driven and agile Development,
❑ Extreme Programming, Agile project management,
❑ Scaling agile methods.

Software Process Models/Life Cycle Model 47
• A software life cycle model (also process model or SDLC):

–A descriptive and diagrammatic model of software life cycle:
–Identifies all the activities undertaken during product development,
–Establishes a precedence ordering among the different activities,
–Divides life cycle into phases.

Why Model Software Process/ Life Cycle Model ? 48
• A graphical and written description:
–Helps common understanding of activities among the software developers.
–Helps to identify inconsistencies, redundancies, and omissions in the development

process.
–Helps in tailoring a process model for specific projects.

Why Model Software Process / Life Cycle Model ? 49
• The development team must identify a suitable life cycle model:

–and then adhere to it.
–Primary advantage of adhering to a life cycle model:
• Helps development of software in a systematic and disciplined manner.

The Software Process 50
• A software process model is an abstract representation of a process. It presents a

description of a process from some particular perspective.
• A structured set of activities required to develop a software system.

Software Process Descriptions 51
• When we describe and discuss processes, we usually talk about the activities in these processes
such as specifying a data model, designing a user interface, etc. and the ordering of these
activities.
• Process descriptions may also include:
– Products, which are the outcomes of a process activity;
– Roles, which reflect the responsibilities of the people involved in the process;
– Pre- and post-conditions, which are statements that are true before and after a process
activity has been enacted or a product produced.

Plan-driven and Agile processes 52
• Plan-driven processes are processes where all of the process activities are
planned in advance and progress is measured against this plan.
• In Agile processes, planning is incremental and it is easier to change the process

to reflect changing customer requirements.
• In practice, most practical processes include elements of both plan-driven and

agile approaches.

Software Process Models 53
• Many Software Process Models have been proposed.

• We confine our attention to only a few commonly used models as per syllabus
Software Process Models
Traditional / Planned Driven Models Agile Models

– Waterfall • XP
– V model • Scrum
– Evolutionary • Rational Unified Process-RUP
– Incremental • Crystal
• DSDM ( Dynamic systems
– Prototyping
development method)
– Spiral model • Lean
– RAD (Rapid Application Development)
The Waterfall Model 54
▪ The Waterfall Model was first Process Model to be introduced.

▪ It is very simple to understand and use.
▪ In a Waterfall model, each phase must be completed before the next phase can begin and
there is no overlapping in the phases.
▪ Waterfall model is the earliest SDLC approach that was used for software development.
▪ It is step by step software development process model

Waterfall Model Phases 55
• There are separate identified phases in the

waterfall model:
– Requirements analysis and definition
– System and software design
– Implementation and unit testing
– Integration and system testing
– Operation and maintenance
• The main drawback of the waterfall model
is the difficulty of accommodating change
after the process is underway. In principle, a
phase has to be complete before moving
onto the next phase.

Waterfall Model Problems 56
• Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing
customer requirements.
– Therefore, this model is only appropriate when the requirements are well-understood and
changes will be fairly limited during the design process.
– Few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites.
– In those circumstances, the plan-driven nature of the waterfall model helps coordinate the
work.

The Waterfall Model 57
Sno Model Definition Features When to use the Model Advantages Disadvantages
1 Waterfall The Waterfall There are Requirements are well Easy to All requirements must
Model was first separate understand, easy be known upfront – in
known and stable
Process Model to be identified
to use, especially most projects
introduced. It is very phases in the
simple to understand waterfall Technology is by inexperienced requirement change
and use. In model: understood staff occurs after project
a Waterfall model, •Requirements start
each phase must be analysis and Milestones are
Development team
completed before definition well understood Can give a false
the next phase can •System and have experience with
by the team impression of progress
begin and there is software design similar projects
no overlapping in •Implementatio Provides Integration is one big
the n and unit bang at the end
requirements
phases. Waterfall testing
model is the earliest •Integration stability during
Little opportunity for
SDLC approach that and system development
customer to pre-view
was used for testing
software •Operation and Facilitates strong the system.
development. maintenance management
control (plan,
staff, track)
Incremental Development Model 58
▪ Incremental Model is a process of software development where requirements are broken

down into multiple standalone modules of software development cycle.
▪ Incremental development is done in steps from analysis design, implementation,
testing/verification, maintenance.
▪ This model combines the elements of the waterfall model with the iterative philosophy of
prototyping.

Incremental development Model 59

Incremental Model 60
A A A
B B
Incremental Model is a process of software development where requirements are

broken down into multiple standalone modules of software development cycle.

Incremental delivery 61
increment design build Customer

install
1 Feedback
design build Customer

increment install
Feedback
2
increment design build Customer

install
3 Feedback

Incremental development benefits 62
• The cost of accommodating changing customer requirements is reduced.

– The amount of analysis and documentation that has to be redone is much less than is
required with the waterfall model.
• It is easier to get customer feedback on the development work that has been done.
– Customers can comment on demonstrations of the software and see how much has been
implemented.
• More rapid delivery and deployment of useful software to the customer is possible.
– Customers are able to use and gain value from the software earlier than is possible with a
waterfall process.

Incremental development problems 63
• The process is not visible.
– Managers need regular deliverables to measure progress. If systems are developed

quickly, it is not cost-effective to produce documents that reflect every version of the
system.
• System structure tends to degrade as new increments are added.
– Unless time and money is spent on refactoring to improve the software, regular change
tends to corrupt its structure. Incorporating further software changes becomes increasingly
difficult and costly.

Incremental Development Model 64
Sno Model Definition Features When to use the Model Advantages Disadvantages
1 Incremental Incremental System development is Such models are used Generates working Each phase of an
Development Model is a broken down into many where requirements are software quickly iteration is rigid
Model process of mini development clear and can and early during and do not
software projects implement by phase the software life overlap each
development Partial systems are wise. From the figure it’s cycle. other.
where successively built to clear that the More flexible – Problems may
requirements are produce a final total requirements is divided less costly to arise pertaining
broken down into system into R1, R2……….Rn change scope and to system
multiple Highest priority and delivered requirements. architecture
standalone requirement is tackled accordingly. Easier to test and because not all
modules of first Mostly such model is debug during a requirements are
software Once the incremented used in web applications smaller iteration. gathered up front
development portion id developed, and product based Easier to manage for the entire
cycle. Incremental requirements for that companies. risk because risky software life
development is increment are frozen pieces are cycle.
done in steps from identified and
analysis design, handled during its
implementation, iteration.
testing/verificatio Each iteration is an
n, maintenance. easily managed
milestone.

Reuse-Oriented Model 65
Reuse Oriented Model (ROM), also known as reuse-oriented development

(ROD), it can be steps of the software development for specific duration in which
software is redesigned through creating a sequence of prototypes known
as models, every system is derived from the previous one with constant series of
defined rules

▪ Reuse is one of the most important concepts of today's software engineering since it can not only
save a given amount of work when existing components providing a given functionality are
reused but existing components might have lots of testing received so far so we can possibly build
more reliable systems based on them.
▪ Reuse often happens in an informal way when people working on the project know of designs or
code that are similar to what is required.
▪ They look for these, modify them as needed, and incorporate them into their system. This is
basically the application of patterns in the development process.

• Based on systematic reuse where systems are integrated from existing

components or COTS (Commercial-off-the-shelf) systems.
• Process stages
– Component analysis;
– Requirements modification;
– System design with reuse;
– Development and integration.
• Reuse is now the standard approach for building many types of business
system

Reuse-oriented Model 68

Process activities 69
• Real software processes are inter-leaved sequences of technical, collaborative and managerial
activities with the overall goal of specifying, designing, implementing and testing a software
system.
• The four basic process activities of specification(SRS), development, validation and evolution are
organized differently in different development processes. In the waterfall model, they are
organized in sequence, whereas in incremental development they are inter-leaved.

Software Requirement specification 70
The process of establishing what services are required and the constraints on the system’s
operation and development.
• Requirements engineering process
– Feasibility study
• Is it technically and financially feasible to build the system?
– Requirements elicitation and analysis
• What do the system stakeholders require or expect from the system?
– Requirements specification
• Defining the requirements in detail
– Requirements validation
• Checking the validity of the requirements

Software design and implementation 71
The process of converting the system specification into an executable system.

• Software design
– Design a software structure that realises the specification;
• Implementation
– Translate this structure into an executable program;
The activities of design and implementation are closely related and may be inter-
leaved.

Design Activities 72
• Architectural design, where you identify the overall structure of the system, the
principal components (sometimes called sub-systems or modules), their relationships
and how they are distributed.
• Interface design, where you define the interfaces between system components.
• Component design, where you take each system component and design how it will
operate.
• Database design, where you design the system data structures and how these are to
be represented in a database.

A general model of the design process 73

74
Software Processes
Coping with Change

Coping with change 75
• Change is inevitable in all large software projects.

– Business changes lead to new and changed system requirements
– New technologies open up new possibilities for improving implementations
– Changing platforms require application changes
• Change leads to rework so the costs of change include both rework (e.g. re-analysing
requirements) as well as the costs of implementing new functionality

Reducing the costs of rework 76
• Change avoidance, where the software process includes activities that can anticipate possible
changes before significant rework is required.
– For example, a prototype system may be developed to show some key features of the
system to customers.
• Change tolerance, where the process is designed so that changes can be accommodated at
relatively low cost.
– This normally involves some form of incremental development. Proposed changes may be
implemented in increments that have not yet been developed. If this is impossible, then only
a single increment (a small part of the system) may have be altered to incorporate the
change.

Coping with Change and changing system requirements 77
1.System prototyping,
where a version of the system or part of the system is developed quickly to check the
customer’s requirements and the feasibility of design decisions. This is a method of change
anticipation as it allows users to experiment with the system before delivery and so refine their
requirements. The number of requirements change proposals made after delivery is therefore
likely to be reduced.
2.Incremental delivery,
where system increments are delivered to the customer for comment and
experimentation. This supports both change avoidance and change tolerance. It avoids the
premature commitment to requirements for the whole system and allows changes to be
incorporated into later increments at relatively low cost.
3. Spiral Model

Software Prototyping 78
• A prototype is an initial version of a system used to demonstrate concepts

and try out design options.
• A prototype can be used in:
– The requirements engineering process to help with requirements elicitation
and validation;
– In design processes to explore options and develop a UI design;
– In the testing process to run back-to-back tests.

Benefits of Prototyping 79
• Improved system usability.
• A closer match to users’ real needs.
• Improved design quality.
• Improved maintainability.
• Reduced development effort.

80

81

Prototype development 82
• May be based on rapid prototyping languages or tools
• May involve leaving out functionality
– Prototype should focus on areas of the product that are not well-understood;
– Error checking and recovery may not be included in the prototype;
– Focus on functional rather than non-functional requirements such as reliability

and security

Throw-away prototypes 83
• Prototypes should be discarded after development as they are not a good

basis for a production system:
– It may be impossible to tune the system to meet non-functional requirements;
– Prototypes are normally undocumented;
– The prototype structure is usually degraded through rapid change;
– The prototype probably will not meet normal organizational quality
standards.

• Rather than deliver the system as a single delivery, the development and
delivery is broken down into increments with each increment delivering part of
the required functionality.
• User requirements are prioritised and the highest priority requirements are
included in early increments.
• Once the development of an increment is started, the requirements are frozen

though requirements for later increments can continue to evolve.

Incremental development and delivery 85
• Incremental development
– Develop the system in increments and evaluate each increment before proceeding to the
development of the next increment;
– Normal approach used in agile methods;
– Evaluation done by user/customer proxy.
• Incremental delivery
– Deploy an increment for use by end-users;
– More realistic evaluation about practical use of software;
– Difficult to implement for replacement systems as increments have less functionality than the
system being replaced.


Boehm’s Spiral Model 87
The spiral model is a systems development lifecycle (SDLC)

method used for risk management that combines the iterative
development process model with elements of the Waterfall
model. The spiral model is used by software engineers and is
favored for large, expensive and complicated projects.

Boehm’s Spiral Model 88
Objectives determination and identify alternative solutions: Requirements are gathered from the customers and the
objectives are identified, elaborated, and analyzed at the start of every phase. Then alternative solutions possible for
the phase are proposed in this quadrant.
Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to select the best
possible solution. Then the risks associated with that solution are identified and the risks are resolved using the best
possible strategy. At the end of this quadrant, the Prototype is built for the best possible solution.
Develop next version of the Product: During the third quadrant, the identified features are developed and verified
through testing. At the end of the third quadrant, the next version of the software is available.
Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far developed version of
the software. In the end, planning for the next phase is started.

Advantages & Disadvantages of Spiral Model 89
Advantages of Spiral Model: Disadvantages of Spiral Model:

Below are some advantages of the Spiral Model. Below are some main disadvantages of the spiral model.
Risk Handling: The projects with many unknown risks that Complex: The Spiral Model is much more complex than
occur as the development proceeds, in that case, Spiral other SDLC models.
Model is the best development model to follow due to the Expensive: Spiral Model is not suitable for small projects
risk analysis and risk handling at every phase. as it is expensive.
Good for large projects: It is recommended to use the Too much dependability on Risk Analysis: The
Spiral Model in large and complex projects. successful completion of the project is very much
Flexibility in Requirements: Change requests in the dependent on Risk Analysis. Without very highly
Requirements at later phase can be incorporated experienced experts, it is going to be a failure to
accurately by using this model. develop a project using this model.
Customer Satisfaction: Customer can see the Difficulty in time management: As the number of phases
development of the product at the early phase of the is unknown at the start of the project, so time estimation is
software development and thus, they habituated with the very difficult.
system by using it before completion of the total product.

Important Questions 163
• Describe the main activities in the software design process and the outputs of these activities. Using a diagram, show
possible relationships between the outputs of these activities
• Explain why change is inevitable in complex systems and give examples (apart from prototyping and incremental
delivery) of software process activities that help predict changes and make the software being developed more
resilient to change.
• What is software process model? Explain the essential attributes of good software
• Discuss the various issues in software engineering professional responsibility and code of ethics
• Discuss the key challenges facing software engineering professionals that are common to all software processes
• Discuss the process involved in waterfall and incremental development model with advantages and disadvantages.
• Describe the difference between software engineering and system engineering product
• What differences has the Web made to software engineering? and explain Software engineering diversity
• Explain in detail about Reuse Oriented software engineering.
• Justify which process model will be suitable to design insulin pump system
• Explain Spiral model of Software Process with neat diagram.
• Explain Prototyping of software process with example
• Explain why incremental development is the most effective approach for developing business software systems. Why
is this model less appropriate for real-time systems engineering?
• Suggest why it is important to make a distinction between developing the user requirements and developing system
requirements in the requirements engineering process.

Software Engeneering

Uploaded by

Copyright:

Available Formats

You might also like

Software Engeneering

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engeneering

Uploaded by

Copyright:

Available Formats

1

Expectation Setting Session

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Subject Code: 20MCA24

Department of Computer Application 20MCA24-Software Engineering

Course Outcomes: Students will be able to

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

▪ 11th International Conference on Software Engineering and Applications (SEA 2022)

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Software Process & Agile Software Development

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Software is a set of instructions made in the form of written programs, procedures

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

The IEEE Computer Society defines software engineering as

The application of a systematic, disciplined, quantifiable approach to the

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

The application of a systematic, disciplined, quantifiable approach to the

is concerned with theory and fundamentals

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Software is often divided into Three Categories

System Software Programming Software Application Software

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

• A purposeful collection of inter-related components working together to achieve

some common objective.

• A system may include software, mechanical component, electrical and

electronic hardware and be operated by people.

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Computer based System Engineering Architecture/Components of Information System

Components of ICT-Information Communication Technology

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Office Automation System

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Heterogeneity, delivery and trust.

– Developing techniques that lead to faster delivery of software;

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

• Ethical behaviour is more than simply upholding the law.

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

• Intellectual property rights

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

professional software engineers, including practitioners, educators, managers, supervisors and

policy makers, as well as trainees and students of the profession.

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Software engineers shall adhere to the following Eight Principles:

– Software engineers shall act consistently with the public interest.

• Client And Employer

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

– Software engineers shall be fair to and supportive of their colleagues.

Department of Computer Application 20MCA24-Software Engineering 25 July 2022

A personal insulin pump

An embedded system in an insulin pump used by diabetics to maintain