SlideShare a Scribd company logo
Course : Software Engineering
Course Code: 21CS47
Course : Software Engineering
Course Code: 21CS47
Choice Based Credit System (CBCS)
Course Code: 21CS47
CIE Marks: 50
Teaching Hours/Week: 3:0:0
SEE Marks: 50
Total Number of Contact Hours: 40
Exam Hours: 3
Objectives
• Understand what software engineering is
and why it is important;
• Understand that the development of
different types of software system may
require different software engineering
techniques;
• Understand ethical and professional issues
that are important for software engineers;
Module -1
Professional software
development
Professional software development, SE diversity, Internet
SE
Software engineering
ethics Software engineering ethics and Professional Practice
Case studies
An insulin pump control system, A patient information
system for mental health care, A wilderness weather
station, A digital Learning Environment for schools
Software processes Software processes: Software Process Models.
Software Process
Models The waterfall model, Incremental model
Process activities
Software specification, Software design and
implementation, Software Validation, Software evolution
Coping with change Prototyping, Incremental Delivery
Process
improvement Software Process Improvement
Module -2
Requirements
Engineering Introduction to RE
Functional
requirement Functional requirement, Domain Requirement
Non Functional
requirement Product, Organization, External Requirement
Requirements
Engineering
Processes
Requirements elicitation, Requirement elicitation
techniques Stories and Scenarios
Requirements
specification Natural Language Specification, Structured Specifications,
Requirements
Validation Requirements reviews
Requirement Change
Requirements management planning, requirements change
management
Usecases Developing usecase requirements
Module -3
System models Context models
Behavioural Models
Interaction models, Usecase Modelling, Sequence
Diagram
Structural Models Class diagram
Architectural design Architectural design decisions
Architectural views
and patterns
Architectural views, Layered Architecture, Architectural
Patterns
Design and
Implementation Object-oriented design using UML
Design Patterns Patterns and Patterns Language
Module -4
Agile Software
Development Agile methods, Agile development techniques
Agile project
management Scrum Sprint Lifecycle
Software Testing
strategies A strategic approach to software testing, strategic issues
Software Testing
strategies Software test strategies for conventional software
Software Validation validation testing, system testing
Software Evolution Evolution Process
Legacy systems Legacy system management, Software maintenance.
Module -5
Project Management
Concepts
The management spectrum, People, The product, The
process, The project
W5HH Principle Basic concepts, Project scheduling
Project Scheduling
Basic principles, The relationship between people and
effort
Defining a task
network A task set example, Refinement of major tasks
Scheduling
Time line charts, tracking the schedule, Tracking
progress for an OO object
Risk Management Reactive versus proactive strategies
Software Risks Software Risks, Risk Identification
Risks in software
development
Risk Mitigation, Monitoring and Management, The
RMMM plan
Course Outcomes
CO1
Apply the principles, concepts, methods, and techniques
of the Software Engineering.
CO2
Use the techniques, skills and modern engineering tools
necessary for engineering practice.
CO3
Analyze the components and process of a given scenario
pertaining to it’s realistic constraints.
Question Paper Pattern
SEE will be conducted for 100 marks.
Part A: First question with 20 MCQs carrying 1 mark each.
Part B: Each full question is for 16 marks. (Answer five full questions out of
10 questions with intra modular choice).
In every question, there will be a maximum of three sub-questions.
CIE will be announced prior to the commencement of the course.
25 marks for test. Average of three test will be taken.
25 marks for Alternate Assessment Method.
Text books
Text books:
1. Ian Sommerville, Software Engineering, Person Education Ltd 10th
Edition, 2019.
2. Roger. S. Pressman, Software Engineering-A Practitioners Approach,
McGraw-Hill, 8th Edition, 2019.
References:
1. Pankaj Jalote, An Integrated Approach to Software Engineering, 3rd
Edition, Narosa Publications, 2005.
2. Stephen R. Schacht, Object Oriented & Classical Software Engineering,
Tata McGraw-Hill, 6th Edition, 2005
Software Engineering
Software engineering is the process of developing,
testing and deploying computer applications to solve
real-world problems by adhering to a set of
engineering principles and best practices.
Chapter 1- Introduction to Software Engineering
15
Professional software
development
• software development is a professional activity in
which software is developed for business purposes,
for inclusion in other devices, or as software
products such as information systems and
computer-aided design systems.
• The key distinctions are that professional software
is intended for use by someone apart from its
developer and that teams rather than individuals
usually develop the software. It is maintained and
changed throughout its life
Chapter 1 Introduction
Frequently Asked Questions about Software
Engineering
2
Question Answer
What is software? Computer programs 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 are the fundamental software
engineering activities?
Software specification, software development, software
validation and software evolution.
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. 17
Chapter 1 Introduction
Frequently Asked Questions about Software
Engineering
Question Answer
What are the key challenges facing
software engineering?
Coping with increasing diversity, demands for reduced
delivery times and developing trustworthy software.
What are the costs of software
engineering?
Roughly 60% of software costs are development costs,
40% are testing costs. For custom software, evolution
costs often exceed development costs.
What are the best software engineering
techniques and methods?
While all software projects have to be professionally
managed and developed, different techniques are
appropriate for different types of system. For example,
games should always be developed using a series of
prototypes whereas safety critical control systems require
a complete and analyzable specification to be developed.
You can’t, therefore, say that one method is better than
another.
What differences has the web made to
software engineering?
The web has led to the availability of software services and
the possibility of developing highly distributed service-
based systems. Web-based systems development has led
to important advances in programming languages and
software reuse.
3
Chapter 1 Introduction
Essential Attributes of Good Software
Often referred to as "Quality Metrics"
Sometimes called "Non-Functional Requirements"
4
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.
Essential Attributes of Good Software
Often referred to as "Quality Metrics"
Sometimes called "Non-Functional Requirements"
➢ Reliability
➢ Scalability
➢ Portability
➢ Reusability
➢ Useability
➢ Reliability:Software reliability is the probability of failure-free
operation of a computer program for a specified period in a specified
environment.
➢ Scalability: is an attribute of a system to increase its capacity and
functionalities based on its users' demand.
➢ Portability: the possibility to use the same software in different
environments
➢ Reusability :the ease with which the product or portions of the
product can be reused in the development of other systems. For
example, a programmer may copy a small portion of source code to a
new software system under construction, versus copying the entire
source code
➢ Useability: the quality of a user's experience when interacting with
products or systems, including websites, software, devices, or
applications. Usability is about effectiveness, efficiency and the overall
satisfaction of the user.
Software Engineering
➢ Software engineering is an engineering discipline that is
concerned with all aspects of software production from the
early stages of system specification through to maintaining
the system after it has gone into use.
➢ Engineering discipline
➢ Using appropriate theories and methods to solve problems
bearing in mind organizational and financial constraints.
➢ All aspects of software production
➢ Not just technical process of development. Also project
management and the development of tools, methods etc. to
support software production.
Software Process Activities
(High level view)
 Software specifications: where customers and
engineers define the software that is to be produced and
the constraints on its operation.
 Software development, where the software is
designed and programmed.
 Software validation, where the software is checked to
ensure that it is what the customer requires.
 Software evolution, where the software is modified to
reflect changing customer and market requirements.
Software Engineering Diversity
➢ There are many different types of software system and
there is no universal set of software techniques that is
applicable to all of these.
➢ The software engineering methods and tools used depend
on the type of application being developed, the
requirements of the customer and the background of the
development team.
➢ Many companies do not subscribe exactly to any specific
process. Rather, they use a hybrid of activities that ‘fits’
their organization, tools, experience, and frankly what
‘works for them.’
Key examples of diverse systems
➢ Stand alone apps
➢ Interactive transaction-based apps
➢ Embedded real time systems
➢ Process control systems
➢ Batch systems
➢ Data collection systems. And more...
25
Software Engineering Fundamentals
Some fundamental principles apply to all types of
software system.
➢ Systems should be developed using a managed and
understood development process.
➢ Dependability and performance are important for all
systems. But there are many other quality metrics needed!!
➢ Understanding and managing the software specification
and requirements (what the software should do) are vitally
important.
➢ Where appropriate, you should reuse software that has
already been developed rather than write new software.
Software Engineering and the Web
➢ The Web is now a platform for running application and
organizations are increasingly developing web-based
systems rather than local systems.
➢ Web services allow application functionality to be accessed
globally
➢ We must consider our developments global by default.
➢ Cloud computing is an approach to the provision of
computer services where applications run remotely on the
‘cloud’.
➢ Users do not buy software
pay according to use.
9
27
Web Software Engineering
➢ Software reuse is the dominant approach for constructing
web-based systems.
➢ When building these systems, you think about how you can
assemble them from pre-existing software components and
systems.
➢ Web-based systems should be developed and delivered
iteratively and incrementally.
➢ It is now generally recognized that it is impractical to specify
all the requirements for such systems in advance.
➢ User interfaces are constrained by the capabilities of web
browsers.
➢ Technologies such as AJAX allow rich interfaces to be created
within a web browser but are still difficult to use.
➢ Web forms with local scripting are more commonly used.
Software Engineering Ethics
➢ Software engineering involves wider responsibilities than
simply the application of technical skills.
➢ This is dramatically different than software development.
years ago.
➢ Software engineers must behave in an honest and ethically
responsible way if they are to be respected as
professionals.
➢ Ethical behavior is more than simply upholding the law but
involves following a set of principles that are morally
correct.
Issues of Professional Responsibility
Confidentiality
➢ Engineers should normally respect the confidentiality of
their employers or clients irrespective of whether or not a
formal confidentiality agreement has been signed.
➢ When being fired, often employee is not allowed to return
to his/her desk!
Competence
➢ Engineers should not misrepresent their level of
competence. They should not knowingly accept work which
is out with their competence.
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).
Ethical Principles
15
1. PUBLIC - Software engineers shall act consistently with the public interest.
2. 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.
3. PRODUCT - Software engineers shall ensure that their products and related modifications
meet the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and
promote an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the
profession consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. 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.
34
Case studies
1. A personal insulin pump
➢ An embedded system in an insulin pump used by diabetics to
➢ maintain blood glucose control.
2. A mental health case patient management system
➢ A system used to maintain records of people receiving care
for
➢ mental health problems.
3. A wilderness weather station
➢ A data collection system that collects data about
weather conditions in remote areas.
Case study 1– An Insulin Pump Control
System
A personal insulin pump
An embedded system in an insulin pump used by diabetics to maintain
blood glucose control.
Insulin pump control system
Collects data from a blood sugar sensor and calculates the amount of
insulin required to be injected.
Calculation based on the rate of change of blood sugar levels.
Sends signals to a micro-pump to deliver the correct dose of insulin.
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.
17
39
Insulin pump hardware architecture
22
40
Activity model of the insulin pump
19
41
Essential high-level requirements
(sometimes called User Stories or
Features)
• 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. A patient information system
for mental health care
➢ A patient information system to support mental health care
is a medical information system that maintains information
about patients suffering from mental health problems and
the treatments that they have received.
➢ Most mental health patients do not require dedicated
hospital treatment but need to attend specialist clinics
regularly where they can meet a doctor who has detailed
knowledge of their problems.
➢ To make it easier for patients to attend, these clinics are
not just run in hospitals. They may also be held in local
medical practices or community centers.
MHC-PMS
➢ The MHC-PMS (Mental Health Care-Patient Management
System) is an information system that is intended for use in
clinics.
➢ It makes use of a centralized database of patient information
but has also been designed to run on a PC, so that it may be
accessed and used from sites that do not have secure network
connectivity.
➢ When the local systems have secure network access, they use
patient information in the database but they can download and
use local copies of patient records when they are
disconnected.
MHC-PMS goals
➢ To generate management information that allows health
service managers to assess performance against local
and government targets.
➢ To provide medical staff with timely information to
support the treatment of patients.
The organization of the MHC-PMS
MHC-PMS key features
 Individual care management
▪ Clinicians can create records for patients, edit the information in
the system, view patient history, etc. The system supports data
summaries so that doctors can quickly learn about the key
problems and treatments that have been prescribed.
 Patient monitoring
▪ The system monitors the records of patients that are involved in
treatment and issues warnings if possible problems are detected.
 Administrative reporting
▪ The system generates monthly management reports showing the
number of patients treated at each clinic, the number of patients
who have entered and left the care system, number of patients
sectioned, the drugs prescribed and their costs, etc.
MHC-PMS concerns
➢ Privacy
➢ It is essential that patient information is confidential and is never
disclosed to anyone apart from authorised medical staff and the
patient themselves.
➢ Safety
➢ Some mental illnesses cause patients to become suicidal or a
danger to other people. Wherever possible, the system should
warn medical staff about potentially suicidal or dangerous
patients.
➢ The system must be available when needed otherwise safety
may be compromised and it may be impossible to prescribe the
correct medication to patients.
Case study 3: A wilderness weather
station
➢ To help monitor climate change and to improve the accuracy
of weather forecasts in remote areas.
➢ These weather stations collect data from a set of instruments
that measure temperature and pressure, sunshine, rainfall,
wind speed and wind direction.
➢ Wilderness weather stations are part of a larger system, which
is a weather information system that collects data from
weather stations and makes it available to other systems for
processing.
Figure : The weather station’s environment
used the UML package symbol to indicate that each
system is a collection of components and the separate
systems are identified using the UML stereotype
«system»
1. The weather station system This system is responsible for
collecting weather data, carrying out some initial data processing,
and transmitting it to the data management system.
2. The data management and archiving system This system collects
the data from all of the wilderness weather stations, carries out
data processing and analysis, and archives the data in a form that
can be retrieved by other systems, such as weather forecasting
systems.
3. The station maintenance system This system can communicate by
satellite with all wilderness weather stations to monitor the health
of these systems and provide reports of problems. It can update
the embedded software in these systems. In the event of system
problems, this system can also be used to remotely control the
weather station.
The station software is therefore not just concerned with data
collection. It must also:
1. Monitor the instruments, power. and communication hardware and
report faults to the management system.
2. Manage the system power, ensuring that batteries are charged
whenever the environmental conditions permit but also that
generators are shut down in potentially damaging weather
conditions, such as high wind.
3. Allow for dynamic reconfiguration where parts of the software are
replaced with new versions and where backup instruments are
switched into the system in the event of system failure
Case study 4: A digital learning
environment for schools
Chapter 2 – Software Processes
1
Topics Covered
➢ Software Process
➢ Software Process Models
➢ Process Activities - Traditional
2
The Software Process
A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective.
A software process is a structured set of activities required
to develop a software system.
Many different software processes but all involve:
1. Specification – defining what the system should do;
2. Design and implementation – defining the organization of the system
and implementing the system;
3. Validation – checking that it does what the customer wants;
4. Evolution – changing the system in response to changing customer
needs.
3
Software Process Descriptions
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.
4
Three Different Models
1. Water Fall Model
2. Incremental Model
3. Boehm’s Spiral Model
Model1: The Waterfall Model
8
Waterfall Model Phases
➢ There are separate identified phases in the waterfall
model:
Requirements analysis and definition: The system's services, constraints, and goals are
established by consultation with system users. They are then defined in detail and serve as a system
specification.
System and software design: The systems design process allocates the requirements to either
hardware or software systems by establishing an overall system architecture. Software design involves
identifying and describing the fundamental software system abstractions and their relationships.
Implementation and unit testing: During this stage, the software design is realized as a set of
programs or program units. Unit testing involves verifying that each unit meets its specification.
Integration and system testing: The individual program units or programs are integrated and
tested as a complete system to ensure that the software requirements have been met. After testing, the
software system is delivered to the customer.
Operation and maintenance: Normally (although not necessarily), this is the longest life cycle
phase. The system is installed and put into practical use. Maintenance involves correcting errors which
were not discovered in earlier stages of the life cycle, improving the implementation of system units and
enhancing the system's services as new requirements are discovered.
9
Waterfall Model Problems
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.
10
Advantages and Disadvantages in
Water Fall model
Advantages
Model 2: Incremental development
model
Specification, development and validation are interleaved. The system is
developed as a series of versions (increments), with each version adding
functionality to the previous version until the required system has been
developed. May be plan-driven or agile.
Advantages and Disadvantages in Incremental
development model
Benefits of incremental development(Advantages):
▪ Lower cost of changes: 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.
▪ Frequent feedback: 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.
▪ Faster delivery: 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.
Problems with incremental development (from the management
perspective)(Disadvantages)
▪ 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.
Integration and configuration
Figure shows a general process model for reuse-based development,
based on integration and configuration.
The stages in this process are:
1.Requirements specification: The initial requirements for the system are proposed.
Includes brief descriptions of essential requirements and desirable system features.
2. Software discovery and evaluation: Given an outline of the software requirements, a
search is made for components and systems that provide the functionality required.
Candidate components and systems are evaluated to see if they meet the essential
requirements and if they are generally suitable for use in the system.
3. Requirements refinement: During this stage, the requirements are refined using
information about the reusable components and applications that have been
discovered. The requirements are modified to reflect the available components, and
the system specification is re-defined. Where modifications are impossible, the
component analysis activity may be reentered to search for alternative solutions.
4. Application system configuration: If an off-the-shelf application system that meets
the requirements is available, it may then be configured for use to create the new
system.
5. Component adaptation and integration: If there is no off-the-shelf system,
individual reusable components may be modified and new components developed.
These are then integrated to create the system.
Types of software components are
frequently reused:
• Web services that are developed according to service
standards and which are available for remote invocation.
• Collections of objects that are developed as a package to
be integrated with a component framework such as .NET
or J2EE.
• Stand-alone commercial-off-the-shelf systems (COTS) that
are configured for use in a particular environment.
Process activities
➢ The four basic process activities of specification,
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 interleaved.
➢ How these activities are carried out depends on
the type of software being developed, the
experience and competence of the developers, and
the type of organization developing the software.
1. Software specification
There are three main activities in the
requirements engineering process:
1. Requirements elicitation and analysis: This is the process of deriving the
system requirements through observation of existing systems, discussions
with potential users and procurers, task analysis, and so on. This may involve
the development of one or more system models and prototypes. These help
you understand the system to be specified.
2. Requirements specification: It is the activity of translating the
information gathered during requirements analysis into a document that
defines a set of requirements. Two types of requirements may be included
in this document. User requirements are abstract statements of the system
requirements for the customer and end-user of the system; system
requirements are a more detailed description of the functionality to be
provided.
3. Requirements validation: This activity checks the requirements for
realism, consistency, and completeness. During this process, errors in the
requirements document are inevitably discovered. It must then be modified
to correct these problems.
2. Software design and implementation
➢ Software design is a description of the structure
of the software to be implemented, the data
models and structures used by the system, the
interfaces between system components and,
sometimes, the algorithms used.
➢ Designers add detail as they develop their design,
with constant backtracking to modify earlier
designs.
➢ The design process activities are both interleaved
and interdependent.
Figure shows four activities that may be part of
the design process for information systems:
➢ ‘software platform’- the environment in which the software will execute.
➢ Most software interfaces with other software systems like operating system,
database, middleware, and other application systems.
➢ If the system is to process existing data, then the description of that data may
be included in the platform specification. Otherwise, the data description
must be an input to the design process so that the system data organization
can be defined.
➢ The activities in the design process vary, depending on the type of system
being developed.
Four activities that may be part of the design process for information
systems:
1. Architectural design, where you identify the overall structure of the system,
the principal components (sometimes called subsystems or modules), their
relationships, and how they are distributed.
2. Database design, where you design the system data structures and how these
are to be represented in a database. Again, the work here depends on whether an
existing database is to be reused or a new database is to be created.
3.Interface design, where you define the interfaces between system
components. With a precise interface, a component may be used by other
components without them having to know how it is implemented.
4.Component selection and design, where you search for reusable components
and, if no suitable components are available, design new software components.
Alternatively, it may be a list of changes to be made to a reusable component or a
detailed design model expressed in the UML.
The design model may then be used to automatically generate an
implementation.
3. Software validation
verification and validation (V & V) is intended to show that a system
both conforms to its specification and meets the expectations of the
system customer.
➢Figure 2.6 shows a three-stage testing process in which system
components are individually tested, then the integrated system is tested.
➢For custom software, customer testing involves testing the system
with real customer data.
➢For products that are sold as applications, customer testing is
sometimes called beta testing where selected users try out and comment
on the software.
The stages in the testing process are:
➢ Component testing The components making up the system are
tested by the people developing the system. Each component is tested
independently, without other system components. Test automation
tools, such as JUnit for Java, that can rerun tests when new versions of
the component are created, are commonly used.
➢ System testing System components are integrated to create a
complete system. This process is concerned with finding errors that
result from unanticipated interactions between components and
component interface problems.It is also concerned with showing that
the system meets its functional and non-functional requirements, and
testing the emergent system properties.
➢ Customer testing This is the final stage in the testing process before
the system is accepted for operational use. The system is tested by the
system customer rather than with simulated test data. For custom-
built software, customer testing may reveal errors and omissions in
the system requirements definition.
➢ When a system is to be marketed as a software product, a testing
process called beta testing is often used. Beta testing involves
delivering a system to a number of potential customers who agree to
use that system. They report problems to the system developers. This
exposes the product to real use and detects errors that may not have
been anticipated by the product developers. After this feedback, the
software product may be modified and released for further beta
testing or general sale.
➢ test-driven development, which is a normal part of agile processes,
tests are developed along with the requirements before
development starts. This helps the testers and developers to
understand the requirements and ensures that there are no delays as
test cases are created.
➢ When a plan-driven software process is used (e.g., for critical
systems development), testing is driven by a set of test plans. An
independent team of testers works from these test plans, which have
been developed from the system specification and design.
➢ Figure 2.7 illustrates how test plans are the link between testing and
development activities. This is sometimes called the V-model of
development (turn it on its side to see the V).
The V-model shows the software validation
activities that correspond to each stage of the
waterfall process model.
4. Software evolution
The flexibility of software is one of the main reasons why more and more
software is being incorporated into large, complex systems. Once a
decision has been made to manufacture hardware, it is very expensive to
make changes to the hardware design.
Coping with change
The flexibility of software is one of the main reasons why more and more
software is being incorporated into large, complex systems. Once a
decision has been made to manufacture hardware, it is very expensive to
make changes to the hardware design.
The spiral model
• The spiral model is an SDLC model that combines
elements of an iterative(prototype) software
development model with a waterfall model. It is
advisable to use this model for expensive, large
and complex projects.
Spiral Model Phases
1.Determine objectives and find alternate solutions – This phase includes requirement
gathering and analysis. Based on the requirements, objectives are defined and different
alternate solutions are proposed.
2.Risk Analysis and resolving – In this quadrant, all the proposed solutions are analyzed
and any potential risk is identified, analyzed, and resolved.
3.Develop and test: This phase includes the actual implementation of the different features.
All the implemented features are then verified with thorough testing.
4.Review and planning of the next phase – In this phase, the software is evaluated by the
customer. It also includes risk identification and monitoring like cost overrun or schedule
slippage and after that planning of the next phase is started.
Spiral Model Advantages
and Disadvantages
Advantages
1. The spiral model is perfect for projects that are large and complex in nature as
continuous prototyping and evaluation help in mitigating any risk.
2. Because of its risk handling ability, the model is best suited for projects which are
very critical like software related to the health domain, space exploration, etc.
3. This model supports the client feedback and implementation of change
requests (CRs) which is not possible in conventional models like a waterfall.
4. Since customer gets to see a prototype in each phase, so there are higher chances of
customer satisfaction.
Disadvantages
1. Because of the prototype development and risk analysis in each phase, it is
very expensive and time taking.
2. It is not suitable for a simpler and smaller project because of multiple phases.
3. It requires more documentation as compared to other models.
4. Project deadlines can be missed since the number of phases is unknown in the
beginning and frequent prototyping and risk analysis can make things worse.
Requirements engineering
understand the concepts of user and system requirements
and why these requirements should be written in different
ways;
■ understand the differences between functional and non-
functional software requirements;
■ understand the main requirements engineering activities
of elicitation, analysis, and validation, and the relationships
between these activities;
■ understand why requirements management is necessary
A FEASIBILITY study is a short, focused study that
should take place early in the RE process. It should
answer three key questions:
(1) Does the system contribute to the overall
objectives of the organization?
(2) Can the system be implemented within schedule
and budget using current technology? and
(3) Can the system be integrated with other systems
that are used?
Functional and non-functional
requirements
1.Functional requirements: These are statements of services
the system should provide, how the system should react to
particular inputs, and how the system should behave in
particular situations. In some cases, the functional
requirements may also explicitly state what the system
should not do.
2. Non-functional requirements: These are constraints on
the services or functions offered by the system. They include
timing constraints, constraints on the development
process, and constraints imposed by standards. Non-
functional requirements often apply to the system as a
whole rather than individual system features or services.
Functional requirements
Examples of functional requirements for the Mentcare
system, used to maintain information about patients
receiving treatment for mental health problems:
1. A user shall be able to search the appointments lists
for all clinics.
2. The system shall generate each day, for each clinic, a
list of patients who are expected to attend appointments
that day.
3. Each staff member using the system shall be uniquely
identified by his or her eight-digit employee number.
➢ System developers may interpret the
requirement so that it is easier to
implement
For Example: A medical staff member
specifying a search requirement may expect
“search” to mean that, given a patient name,
the system looks for that name in all
appointments at all clinics. However, this is
not explicit in the requirement.
Non-functional requirements
They are divided into two main categories:
Execution qualities like security and usability, which are observable at run
time.
Evolution qualities like testability, extensibility, and scalability that
embodied in the static structure of the software system.
Non-functional requirements specify the software's quality attribute. These
requirements define the general characteristics, behavior of the system, and
features that affect the experience of the user. They ensure a better user
experience, minimizes the cost factor. Non-functional requirements ensure
that the software system must follow the legal and adherence rules. The
impact of the non-functional requirements is not on the functionality of the
system, but they impact how it will perform.
CLASSIFICATION OF NON-FUNCTIONAL
REQUIREMENTS.
We can see from this diagram that the non-
functional requirements may come from
➢ Required Characteristics Of The Software (Product
Requirements),
➢ The Organization Developing The Software
(Organizational Requirements),
➢ Or External Sources
1. Product requirements These requirements specify or constrain the
runtime behavior of the software. Examples include performance
requirements for how fast the system must execute and how much memory it
requires; reliability requirements that set out the acceptable failure rate;
security requirements; and usability requirements.
2. Organizational requirements These requirements are broad system
requirements derived from policies and procedures in the customer’s and
developer’s organizations. Examples include operational process
requirements that define how the system will be used; development process
requirements that specify the programming language; the development
environment or process standards to be used; and environmental
requirements that specify the operating environment of the system.
3. External requirements This broad heading covers all requirements that
are derived from factors external to the system and its development process.
These may include regulatory requirements that set out what must be done
for the system to be approved for use by a regulator, such as a nuclear safety
authority; legislative requirements that must be followed to ensure that the
system operates within the law; and ethical requirements that ensure that the
system will be acceptable to its users and the general public
Example
Metrics For Specifying
Nonfunctional Requirements
4.3 Requirements elicitation
• The requirements elicitation and analysis
process
1. Requirements discovery and understanding This is the process of interacting with
stakeholders of the system to discover their requirements. Domain requirements
from stakeholders and documentation are also discovered during this activity.
2. Requirements classification and organization This activity takes the unstructured
collection of requirements, groups related requirements and organizes them into
coherent clusters.
3. Requirements prioritization and negotiation Inevitably, when multiple
stakeholders are involved, requirements will conflict. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts through
negotiation. Usually, stakeholders have to meet to resolve differences and agree on
compromise requirements.
4. Requirements documentation The requirements are documented and input into
the next round of the spiral. An early draft of the software requirements documents
may be produced at this stage, or the requirements may simply be maintained
informally on whiteboards, wikis, or other shared spaces.
• Domain requirements are expectations related to a particular type
of software, purpose or industry vertical. Domain requirements can
be functional or nonfunctional. The common factor for domain
requirements is that they meet established standards or widely
accepted feature sets for that category of software project.
• Example: medical equipment or educational software. In medical
equipment, software must be developed per IEC 60601 regarding
medical electrical equipment's basic safety and performance.
Software Engineering and Introduction, Activities and ProcessModels

More Related Content

What's hot

Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
Mohammed Romi
 
Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
farazimlak
 
User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15
koolkampus
 
Introduction to software engineering
Introduction to software engineeringIntroduction to software engineering
Introduction to software engineering
Hitesh Mohapatra
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
Saqib Raza
 
Need for Software Engineering
Need for Software EngineeringNeed for Software Engineering
Need for Software Engineering
Upekha Vandebona
 
Introduction to Software Development
Introduction to Software DevelopmentIntroduction to Software Development
Introduction to Software Development
Zeeshan MIrza
 
Requirement Engineering
Requirement EngineeringRequirement Engineering
Requirement Engineering
University of Haripur
 
Software design
Software designSoftware design
Software design
Benazir Fathima
 
Software development slides
Software development slidesSoftware development slides
Software development slides
iarthur
 
Software Engineering Practice
Software Engineering PracticeSoftware Engineering Practice
Software Engineering Practice
Research & Development LAB QUEST Nawabshah
 
Software development process models
Software development process modelsSoftware development process models
Software development process models
Muhammed Afsal Villan
 
Software Engineering - Ch1
Software Engineering - Ch1Software Engineering - Ch1
Software Engineering - Ch1
Siddharth Ayer
 
software architecture
software architecturesoftware architecture
software architecture
Manidheer Babu
 
UI/UX Design
UI/UX DesignUI/UX Design
UI/UX Design
sumit singh
 
Requirement Elicitation
Requirement ElicitationRequirement Elicitation
Requirement Elicitation
Ravikanth-BA
 
Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7
mohammad hossein Jalili
 
Introduction to User Experience Design
Introduction to User Experience DesignIntroduction to User Experience Design
Introduction to User Experience Design
Ravi Bhadauria
 
What is software engineering
What is software engineeringWhat is software engineering
What is software engineering
Jennifer Polack
 
Chapter 01
Chapter 01Chapter 01
Chapter 01
ans ali raza
 

What's hot (20)

Ian Sommerville, Software Engineering, 9th Edition Ch1
Ian Sommerville,  Software Engineering, 9th Edition Ch1Ian Sommerville,  Software Engineering, 9th Edition Ch1
Ian Sommerville, Software Engineering, 9th Edition Ch1
 
Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
 
User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15User Interface Design in Software Engineering SE15
User Interface Design in Software Engineering SE15
 
Introduction to software engineering
Introduction to software engineeringIntroduction to software engineering
Introduction to software engineering
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
Need for Software Engineering
Need for Software EngineeringNeed for Software Engineering
Need for Software Engineering
 
Introduction to Software Development
Introduction to Software DevelopmentIntroduction to Software Development
Introduction to Software Development
 
Requirement Engineering
Requirement EngineeringRequirement Engineering
Requirement Engineering
 
Software design
Software designSoftware design
Software design
 
Software development slides
Software development slidesSoftware development slides
Software development slides
 
Software Engineering Practice
Software Engineering PracticeSoftware Engineering Practice
Software Engineering Practice
 
Software development process models
Software development process modelsSoftware development process models
Software development process models
 
Software Engineering - Ch1
Software Engineering - Ch1Software Engineering - Ch1
Software Engineering - Ch1
 
software architecture
software architecturesoftware architecture
software architecture
 
UI/UX Design
UI/UX DesignUI/UX Design
UI/UX Design
 
Requirement Elicitation
Requirement ElicitationRequirement Elicitation
Requirement Elicitation
 
Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7Software engineering rogers pressman chapter 7
Software engineering rogers pressman chapter 7
 
Introduction to User Experience Design
Introduction to User Experience DesignIntroduction to User Experience Design
Introduction to User Experience Design
 
What is software engineering
What is software engineeringWhat is software engineering
What is software engineering
 
Chapter 01
Chapter 01Chapter 01
Chapter 01
 

Similar to Software Engineering and Introduction, Activities and ProcessModels

SE-Lecture1.ppt
SE-Lecture1.pptSE-Lecture1.ppt
SE-Lecture1.ppt
vishal choudhary
 
SE chp1 update and learning management .pptx
SE chp1 update and learning management .pptxSE chp1 update and learning management .pptx
SE chp1 update and learning management .pptx
ssuserdee5bb1
 
Software Engineering1-1.pptx
Software Engineering1-1.pptxSoftware Engineering1-1.pptx
Software Engineering1-1.pptx
naqibullah2022faryab
 
ch1_introduction (1).ppt
ch1_introduction (1).pptch1_introduction (1).ppt
ch1_introduction (1).ppt
AleksandraArsic6
 
ch1_introduction (2).ppt
ch1_introduction (2).pptch1_introduction (2).ppt
ch1_introduction (2).ppt
AleksandraArsic6
 
ch1_introduction.ppt
ch1_introduction.pptch1_introduction.ppt
ch1_introduction.ppt
BhargaviChaitanya2
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
MrsRBoomadeviIT
 
SE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SE
SE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SESE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SE
SE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SE
AbhishekTripathi709328
 
Lecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptxLecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptx
YaseenNazir3
 
Lecture1 (SE Introduction)
Lecture1 (SE Introduction)Lecture1 (SE Introduction)
Lecture1 (SE Introduction)
Education Front
 
Intro
IntroIntro
Intro
hinaaaa123
 
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG  22CSE141.pdfMODULE 1 Software Product and Process_ SW ENGG  22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
Jayanthi Kannan MK
 
lecture 1.pdf
lecture 1.pdflecture 1.pdf
lecture 1.pdf
ssuser2d043c
 
Software Engineering PPT Unit I.pptx
Software Engineering PPT Unit I.pptxSoftware Engineering PPT Unit I.pptx
Software Engineering PPT Unit I.pptx
omgadekar25
 
Week1.pptx
Week1.pptxWeek1.pptx
Week1.pptx
MarriamNawaz
 
se01.ppt
se01.pptse01.ppt
se01.ppt
xiso
 
SE 18CS35 Module 1.pdf
SE 18CS35 Module 1.pdfSE 18CS35 Module 1.pdf
SE 18CS35 Module 1.pdf
balaji984829
 
Soft.Engg. UNIT 1.pptx
Soft.Engg. UNIT 1.pptxSoft.Engg. UNIT 1.pptx
Soft.Engg. UNIT 1.pptx
Kalpna Saharan
 
Unit 1 importance ofsoftengg_b.tech iii year
Unit 1  importance ofsoftengg_b.tech iii yearUnit 1  importance ofsoftengg_b.tech iii year
Unit 1 importance ofsoftengg_b.tech iii year
Preeti Mishra
 
Unit 1 introduction tosoftengg_mba tech ii year
Unit 1  introduction tosoftengg_mba tech ii yearUnit 1  introduction tosoftengg_mba tech ii year
Unit 1 introduction tosoftengg_mba tech ii year
Preeti Mishra
 

Similar to Software Engineering and Introduction, Activities and ProcessModels (20)

SE-Lecture1.ppt
SE-Lecture1.pptSE-Lecture1.ppt
SE-Lecture1.ppt
 
SE chp1 update and learning management .pptx
SE chp1 update and learning management .pptxSE chp1 update and learning management .pptx
SE chp1 update and learning management .pptx
 
Software Engineering1-1.pptx
Software Engineering1-1.pptxSoftware Engineering1-1.pptx
Software Engineering1-1.pptx
 
ch1_introduction (1).ppt
ch1_introduction (1).pptch1_introduction (1).ppt
ch1_introduction (1).ppt
 
ch1_introduction (2).ppt
ch1_introduction (2).pptch1_introduction (2).ppt
ch1_introduction (2).ppt
 
ch1_introduction.ppt
ch1_introduction.pptch1_introduction.ppt
ch1_introduction.ppt
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
SE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SE
SE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SESE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SE
SE UNIT 1 NOTES OF SE SOFTWARE ENGG AND SE
 
Lecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptxLecture-1,2-Introduction to SE.pptx
Lecture-1,2-Introduction to SE.pptx
 
Lecture1 (SE Introduction)
Lecture1 (SE Introduction)Lecture1 (SE Introduction)
Lecture1 (SE Introduction)
 
Intro
IntroIntro
Intro
 
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG  22CSE141.pdfMODULE 1 Software Product and Process_ SW ENGG  22CSE141.pdf
MODULE 1 Software Product and Process_ SW ENGG 22CSE141.pdf
 
lecture 1.pdf
lecture 1.pdflecture 1.pdf
lecture 1.pdf
 
Software Engineering PPT Unit I.pptx
Software Engineering PPT Unit I.pptxSoftware Engineering PPT Unit I.pptx
Software Engineering PPT Unit I.pptx
 
Week1.pptx
Week1.pptxWeek1.pptx
Week1.pptx
 
se01.ppt
se01.pptse01.ppt
se01.ppt
 
SE 18CS35 Module 1.pdf
SE 18CS35 Module 1.pdfSE 18CS35 Module 1.pdf
SE 18CS35 Module 1.pdf
 
Soft.Engg. UNIT 1.pptx
Soft.Engg. UNIT 1.pptxSoft.Engg. UNIT 1.pptx
Soft.Engg. UNIT 1.pptx
 
Unit 1 importance ofsoftengg_b.tech iii year
Unit 1  importance ofsoftengg_b.tech iii yearUnit 1  importance ofsoftengg_b.tech iii year
Unit 1 importance ofsoftengg_b.tech iii year
 
Unit 1 introduction tosoftengg_mba tech ii year
Unit 1  introduction tosoftengg_mba tech ii yearUnit 1  introduction tosoftengg_mba tech ii year
Unit 1 introduction tosoftengg_mba tech ii year
 

More from BMS Institute of Technology and Management

Python Regular Expressions
Python Regular ExpressionsPython Regular Expressions
Python Regular Expressions
BMS Institute of Technology and Management
 
Pytho_tuples
Pytho_tuplesPytho_tuples
Pytho dictionaries
Pytho dictionaries Pytho dictionaries
Pytho lists
Pytho listsPytho lists
File handling in Python
File handling in PythonFile handling in Python
Introduction to the Python
Introduction to the PythonIntroduction to the Python
Introduction to the Python
BMS Institute of Technology and Management
 
15CS562 AI VTU Question paper
15CS562 AI VTU Question paper15CS562 AI VTU Question paper
15CS562 AI VTU Question paper
BMS Institute of Technology and Management
 
weak slot and filler
weak slot and fillerweak slot and filler
strong slot and filler
strong slot and fillerstrong slot and filler
Problems, Problem spaces and Search
Problems, Problem spaces and SearchProblems, Problem spaces and Search
Problems, Problem spaces and Search
BMS Institute of Technology and Management
 
Introduction to Artificial Intelligence and few examples
Introduction to Artificial Intelligence and few examplesIntroduction to Artificial Intelligence and few examples
Introduction to Artificial Intelligence and few examples
BMS Institute of Technology and Management
 

More from BMS Institute of Technology and Management (11)

Python Regular Expressions
Python Regular ExpressionsPython Regular Expressions
Python Regular Expressions
 
Pytho_tuples
Pytho_tuplesPytho_tuples
Pytho_tuples
 
Pytho dictionaries
Pytho dictionaries Pytho dictionaries
Pytho dictionaries
 
Pytho lists
Pytho listsPytho lists
Pytho lists
 
File handling in Python
File handling in PythonFile handling in Python
File handling in Python
 
Introduction to the Python
Introduction to the PythonIntroduction to the Python
Introduction to the Python
 
15CS562 AI VTU Question paper
15CS562 AI VTU Question paper15CS562 AI VTU Question paper
15CS562 AI VTU Question paper
 
weak slot and filler
weak slot and fillerweak slot and filler
weak slot and filler
 
strong slot and filler
strong slot and fillerstrong slot and filler
strong slot and filler
 
Problems, Problem spaces and Search
Problems, Problem spaces and SearchProblems, Problem spaces and Search
Problems, Problem spaces and Search
 
Introduction to Artificial Intelligence and few examples
Introduction to Artificial Intelligence and few examplesIntroduction to Artificial Intelligence and few examples
Introduction to Artificial Intelligence and few examples
 

Recently uploaded

Properties Railway Sleepers and Test.pptx
Properties Railway Sleepers and Test.pptxProperties Railway Sleepers and Test.pptx
Properties Railway Sleepers and Test.pptx
MDSABBIROJJAMANPAYEL
 
Curve Fitting in Numerical Methods Regression
Curve Fitting in Numerical Methods RegressionCurve Fitting in Numerical Methods Regression
Curve Fitting in Numerical Methods Regression
Nada Hikmah
 
22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt
KrishnaveniKrishnara1
 
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by AnantLLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
Anant Corporation
 
学校原版美国波士顿大学毕业证学历学位证书原版一模一样
学校原版美国波士顿大学毕业证学历学位证书原版一模一样学校原版美国波士顿大学毕业证学历学位证书原版一模一样
学校原版美国波士顿大学毕业证学历学位证书原版一模一样
171ticu
 
Generative AI leverages algorithms to create various forms of content
Generative AI leverages algorithms to create various forms of contentGenerative AI leverages algorithms to create various forms of content
Generative AI leverages algorithms to create various forms of content
Hitesh Mohapatra
 
Welding Metallurgy Ferrous Materials.pdf
Welding Metallurgy Ferrous Materials.pdfWelding Metallurgy Ferrous Materials.pdf
Welding Metallurgy Ferrous Materials.pdf
AjmalKhan50578
 
Data Driven Maintenance | UReason Webinar
Data Driven Maintenance | UReason WebinarData Driven Maintenance | UReason Webinar
Data Driven Maintenance | UReason Webinar
UReason
 
spirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptxspirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptx
Madan Karki
 
132/33KV substation case study Presentation
132/33KV substation case study Presentation132/33KV substation case study Presentation
132/33KV substation case study Presentation
kandramariana6
 
官方认证美国密歇根州立大学毕业证学位证书原版一模一样
官方认证美国密歇根州立大学毕业证学位证书原版一模一样官方认证美国密歇根州立大学毕业证学位证书原版一模一样
官方认证美国密歇根州立大学毕业证学位证书原版一模一样
171ticu
 
Material for memory and display system h
Material for memory and display system hMaterial for memory and display system h
Material for memory and display system h
gowrishankartb2005
 
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURSCompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
RamonNovais6
 
Unit-III-ELECTROCHEMICAL STORAGE DEVICES.ppt
Unit-III-ELECTROCHEMICAL STORAGE DEVICES.pptUnit-III-ELECTROCHEMICAL STORAGE DEVICES.ppt
Unit-III-ELECTROCHEMICAL STORAGE DEVICES.ppt
KrishnaveniKrishnara1
 
The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.
sachin chaurasia
 
Certificates - Mahmoud Mohamed Moursi Ahmed
Certificates - Mahmoud Mohamed Moursi AhmedCertificates - Mahmoud Mohamed Moursi Ahmed
Certificates - Mahmoud Mohamed Moursi Ahmed
Mahmoud Morsy
 
Engineering Drawings Lecture Detail Drawings 2014.pdf
Engineering Drawings Lecture Detail Drawings 2014.pdfEngineering Drawings Lecture Detail Drawings 2014.pdf
Engineering Drawings Lecture Detail Drawings 2014.pdf
abbyasa1014
 
4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf
4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf
4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf
Gino153088
 
Introduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptxIntroduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptx
MiscAnnoy1
 
artificial intelligence and data science contents.pptx
artificial intelligence and data science contents.pptxartificial intelligence and data science contents.pptx
artificial intelligence and data science contents.pptx
GauravCar
 

Recently uploaded (20)

Properties Railway Sleepers and Test.pptx
Properties Railway Sleepers and Test.pptxProperties Railway Sleepers and Test.pptx
Properties Railway Sleepers and Test.pptx
 
Curve Fitting in Numerical Methods Regression
Curve Fitting in Numerical Methods RegressionCurve Fitting in Numerical Methods Regression
Curve Fitting in Numerical Methods Regression
 
22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt22CYT12-Unit-V-E Waste and its Management.ppt
22CYT12-Unit-V-E Waste and its Management.ppt
 
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by AnantLLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
LLM Fine Tuning with QLoRA Cassandra Lunch 4, presented by Anant
 
学校原版美国波士顿大学毕业证学历学位证书原版一模一样
学校原版美国波士顿大学毕业证学历学位证书原版一模一样学校原版美国波士顿大学毕业证学历学位证书原版一模一样
学校原版美国波士顿大学毕业证学历学位证书原版一模一样
 
Generative AI leverages algorithms to create various forms of content
Generative AI leverages algorithms to create various forms of contentGenerative AI leverages algorithms to create various forms of content
Generative AI leverages algorithms to create various forms of content
 
Welding Metallurgy Ferrous Materials.pdf
Welding Metallurgy Ferrous Materials.pdfWelding Metallurgy Ferrous Materials.pdf
Welding Metallurgy Ferrous Materials.pdf
 
Data Driven Maintenance | UReason Webinar
Data Driven Maintenance | UReason WebinarData Driven Maintenance | UReason Webinar
Data Driven Maintenance | UReason Webinar
 
spirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptxspirit beverages ppt without graphics.pptx
spirit beverages ppt without graphics.pptx
 
132/33KV substation case study Presentation
132/33KV substation case study Presentation132/33KV substation case study Presentation
132/33KV substation case study Presentation
 
官方认证美国密歇根州立大学毕业证学位证书原版一模一样
官方认证美国密歇根州立大学毕业证学位证书原版一模一样官方认证美国密歇根州立大学毕业证学位证书原版一模一样
官方认证美国密歇根州立大学毕业证学位证书原版一模一样
 
Material for memory and display system h
Material for memory and display system hMaterial for memory and display system h
Material for memory and display system h
 
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURSCompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
CompEx~Manual~1210 (2).pdf COMPEX GAS AND VAPOURS
 
Unit-III-ELECTROCHEMICAL STORAGE DEVICES.ppt
Unit-III-ELECTROCHEMICAL STORAGE DEVICES.pptUnit-III-ELECTROCHEMICAL STORAGE DEVICES.ppt
Unit-III-ELECTROCHEMICAL STORAGE DEVICES.ppt
 
The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.The Python for beginners. This is an advance computer language.
The Python for beginners. This is an advance computer language.
 
Certificates - Mahmoud Mohamed Moursi Ahmed
Certificates - Mahmoud Mohamed Moursi AhmedCertificates - Mahmoud Mohamed Moursi Ahmed
Certificates - Mahmoud Mohamed Moursi Ahmed
 
Engineering Drawings Lecture Detail Drawings 2014.pdf
Engineering Drawings Lecture Detail Drawings 2014.pdfEngineering Drawings Lecture Detail Drawings 2014.pdf
Engineering Drawings Lecture Detail Drawings 2014.pdf
 
4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf
4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf
4. Mosca vol I -Fisica-Tipler-5ta-Edicion-Vol-1.pdf
 
Introduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptxIntroduction to AI Safety (public presentation).pptx
Introduction to AI Safety (public presentation).pptx
 
artificial intelligence and data science contents.pptx
artificial intelligence and data science contents.pptxartificial intelligence and data science contents.pptx
artificial intelligence and data science contents.pptx
 

Software Engineering and Introduction, Activities and ProcessModels

  • 1. Course : Software Engineering Course Code: 21CS47
  • 2. Course : Software Engineering Course Code: 21CS47
  • 3. Choice Based Credit System (CBCS) Course Code: 21CS47 CIE Marks: 50 Teaching Hours/Week: 3:0:0 SEE Marks: 50 Total Number of Contact Hours: 40 Exam Hours: 3
  • 4. Objectives • Understand what software engineering is and why it is important; • Understand that the development of different types of software system may require different software engineering techniques; • Understand ethical and professional issues that are important for software engineers;
  • 5. Module -1 Professional software development Professional software development, SE diversity, Internet SE Software engineering ethics Software engineering ethics and Professional Practice Case studies An insulin pump control system, A patient information system for mental health care, A wilderness weather station, A digital Learning Environment for schools Software processes Software processes: Software Process Models. Software Process Models The waterfall model, Incremental model Process activities Software specification, Software design and implementation, Software Validation, Software evolution Coping with change Prototyping, Incremental Delivery Process improvement Software Process Improvement
  • 6. Module -2 Requirements Engineering Introduction to RE Functional requirement Functional requirement, Domain Requirement Non Functional requirement Product, Organization, External Requirement Requirements Engineering Processes Requirements elicitation, Requirement elicitation techniques Stories and Scenarios Requirements specification Natural Language Specification, Structured Specifications, Requirements Validation Requirements reviews Requirement Change Requirements management planning, requirements change management Usecases Developing usecase requirements
  • 7. Module -3 System models Context models Behavioural Models Interaction models, Usecase Modelling, Sequence Diagram Structural Models Class diagram Architectural design Architectural design decisions Architectural views and patterns Architectural views, Layered Architecture, Architectural Patterns Design and Implementation Object-oriented design using UML Design Patterns Patterns and Patterns Language
  • 8. Module -4 Agile Software Development Agile methods, Agile development techniques Agile project management Scrum Sprint Lifecycle Software Testing strategies A strategic approach to software testing, strategic issues Software Testing strategies Software test strategies for conventional software Software Validation validation testing, system testing Software Evolution Evolution Process Legacy systems Legacy system management, Software maintenance.
  • 9. Module -5 Project Management Concepts The management spectrum, People, The product, The process, The project W5HH Principle Basic concepts, Project scheduling Project Scheduling Basic principles, The relationship between people and effort Defining a task network A task set example, Refinement of major tasks Scheduling Time line charts, tracking the schedule, Tracking progress for an OO object Risk Management Reactive versus proactive strategies Software Risks Software Risks, Risk Identification Risks in software development Risk Mitigation, Monitoring and Management, The RMMM plan
  • 10. Course Outcomes CO1 Apply the principles, concepts, methods, and techniques of the Software Engineering. CO2 Use the techniques, skills and modern engineering tools necessary for engineering practice. CO3 Analyze the components and process of a given scenario pertaining to it’s realistic constraints.
  • 11. Question Paper Pattern SEE will be conducted for 100 marks. Part A: First question with 20 MCQs carrying 1 mark each. Part B: Each full question is for 16 marks. (Answer five full questions out of 10 questions with intra modular choice). In every question, there will be a maximum of three sub-questions. CIE will be announced prior to the commencement of the course. 25 marks for test. Average of three test will be taken. 25 marks for Alternate Assessment Method.
  • 12. Text books Text books: 1. Ian Sommerville, Software Engineering, Person Education Ltd 10th Edition, 2019. 2. Roger. S. Pressman, Software Engineering-A Practitioners Approach, McGraw-Hill, 8th Edition, 2019. References: 1. Pankaj Jalote, An Integrated Approach to Software Engineering, 3rd Edition, Narosa Publications, 2005. 2. Stephen R. Schacht, Object Oriented & Classical Software Engineering, Tata McGraw-Hill, 6th Edition, 2005
  • 13. Software Engineering Software engineering is the process of developing, testing and deploying computer applications to solve real-world problems by adhering to a set of engineering principles and best practices.
  • 14. Chapter 1- Introduction to Software Engineering 15
  • 15. Professional software development • software development is a professional activity in which software is developed for business purposes, for inclusion in other devices, or as software products such as information systems and computer-aided design systems. • The key distinctions are that professional software is intended for use by someone apart from its developer and that teams rather than individuals usually develop the software. It is maintained and changed throughout its life
  • 16. Chapter 1 Introduction Frequently Asked Questions about Software Engineering 2 Question Answer What is software? Computer programs 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 are the fundamental software engineering activities? Software specification, software development, software validation and software evolution. 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. 17
  • 17. Chapter 1 Introduction Frequently Asked Questions about Software Engineering Question Answer What are the key challenges facing software engineering? Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software. What are the costs of software engineering? Roughly 60% of software costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs. What are the best software engineering techniques and methods? While all software projects have to be professionally managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. What differences has the web made to software engineering? The web has led to the availability of software services and the possibility of developing highly distributed service- based systems. Web-based systems development has led to important advances in programming languages and software reuse. 3
  • 18. Chapter 1 Introduction Essential Attributes of Good Software Often referred to as "Quality Metrics" Sometimes called "Non-Functional Requirements" 4 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.
  • 19. Essential Attributes of Good Software Often referred to as "Quality Metrics" Sometimes called "Non-Functional Requirements" ➢ Reliability ➢ Scalability ➢ Portability ➢ Reusability ➢ Useability
  • 20. ➢ Reliability:Software reliability is the probability of failure-free operation of a computer program for a specified period in a specified environment. ➢ Scalability: is an attribute of a system to increase its capacity and functionalities based on its users' demand. ➢ Portability: the possibility to use the same software in different environments ➢ Reusability :the ease with which the product or portions of the product can be reused in the development of other systems. For example, a programmer may copy a small portion of source code to a new software system under construction, versus copying the entire source code ➢ Useability: the quality of a user's experience when interacting with products or systems, including websites, software, devices, or applications. Usability is about effectiveness, efficiency and the overall satisfaction of the user.
  • 21. Software Engineering ➢ Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. ➢ Engineering discipline ➢ Using appropriate theories and methods to solve problems bearing in mind organizational and financial constraints. ➢ All aspects of software production ➢ Not just technical process of development. Also project management and the development of tools, methods etc. to support software production.
  • 22. Software Process Activities (High level view)  Software specifications: where customers and engineers define the software that is to be produced and the constraints on its operation.  Software development, where the software is designed and programmed.  Software validation, where the software is checked to ensure that it is what the customer requires.  Software evolution, where the software is modified to reflect changing customer and market requirements.
  • 23. Software Engineering Diversity ➢ There are many different types of software system and there is no universal set of software techniques that is applicable to all of these. ➢ The software engineering methods and tools used depend on the type of application being developed, the requirements of the customer and the background of the development team. ➢ Many companies do not subscribe exactly to any specific process. Rather, they use a hybrid of activities that ‘fits’ their organization, tools, experience, and frankly what ‘works for them.’
  • 24. Key examples of diverse systems ➢ Stand alone apps ➢ Interactive transaction-based apps ➢ Embedded real time systems ➢ Process control systems ➢ Batch systems ➢ Data collection systems. And more... 25
  • 25. Software Engineering Fundamentals Some fundamental principles apply to all types of software system. ➢ Systems should be developed using a managed and understood development process. ➢ Dependability and performance are important for all systems. But there are many other quality metrics needed!! ➢ Understanding and managing the software specification and requirements (what the software should do) are vitally important. ➢ Where appropriate, you should reuse software that has already been developed rather than write new software.
  • 26. Software Engineering and the Web ➢ The Web is now a platform for running application and organizations are increasingly developing web-based systems rather than local systems. ➢ Web services allow application functionality to be accessed globally ➢ We must consider our developments global by default. ➢ Cloud computing is an approach to the provision of computer services where applications run remotely on the ‘cloud’. ➢ Users do not buy software pay according to use. 9 27
  • 27. Web Software Engineering ➢ Software reuse is the dominant approach for constructing web-based systems. ➢ When building these systems, you think about how you can assemble them from pre-existing software components and systems. ➢ Web-based systems should be developed and delivered iteratively and incrementally. ➢ It is now generally recognized that it is impractical to specify all the requirements for such systems in advance. ➢ User interfaces are constrained by the capabilities of web browsers. ➢ Technologies such as AJAX allow rich interfaces to be created within a web browser but are still difficult to use. ➢ Web forms with local scripting are more commonly used.
  • 28. Software Engineering Ethics ➢ Software engineering involves wider responsibilities than simply the application of technical skills. ➢ This is dramatically different than software development. years ago. ➢ Software engineers must behave in an honest and ethically responsible way if they are to be respected as professionals. ➢ Ethical behavior is more than simply upholding the law but involves following a set of principles that are morally correct.
  • 29. Issues of Professional Responsibility Confidentiality ➢ Engineers should normally respect the confidentiality of their employers or clients irrespective of whether or not a formal confidentiality agreement has been signed. ➢ When being fired, often employee is not allowed to return to his/her desk! Competence ➢ Engineers should not misrepresent their level of competence. They should not knowingly accept work which is out with their competence. 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.
  • 30. 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).
  • 31. Ethical Principles 15 1. PUBLIC - Software engineers shall act consistently with the public interest. 2. 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. 3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues. 8. 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. 34
  • 32.
  • 33. Case studies 1. A personal insulin pump ➢ An embedded system in an insulin pump used by diabetics to ➢ maintain blood glucose control. 2. A mental health case patient management system ➢ A system used to maintain records of people receiving care for ➢ mental health problems. 3. A wilderness weather station ➢ A data collection system that collects data about weather conditions in remote areas.
  • 34. Case study 1– An Insulin Pump Control System A personal insulin pump An embedded system in an insulin pump used by diabetics to maintain blood glucose control. Insulin pump control system Collects data from a blood sugar sensor and calculates the amount of insulin required to be injected. Calculation based on the rate of change of blood sugar levels. Sends signals to a micro-pump to deliver the correct dose of insulin. 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. 17 39
  • 35. Insulin pump hardware architecture 22 40
  • 36. Activity model of the insulin pump 19 41
  • 37. Essential high-level requirements (sometimes called User Stories or Features) • 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.
  • 38. Case study 2. A patient information system for mental health care ➢ A patient information system to support mental health care is a medical information system that maintains information about patients suffering from mental health problems and the treatments that they have received. ➢ Most mental health patients do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems. ➢ To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centers.
  • 39. MHC-PMS ➢ The MHC-PMS (Mental Health Care-Patient Management System) is an information system that is intended for use in clinics. ➢ It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity. ➢ When the local systems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected.
  • 40. MHC-PMS goals ➢ To generate management information that allows health service managers to assess performance against local and government targets. ➢ To provide medical staff with timely information to support the treatment of patients.
  • 41. The organization of the MHC-PMS
  • 42. MHC-PMS key features  Individual care management ▪ Clinicians can create records for patients, edit the information in the system, view patient history, etc. The system supports data summaries so that doctors can quickly learn about the key problems and treatments that have been prescribed.  Patient monitoring ▪ The system monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected.  Administrative reporting ▪ The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, number of patients sectioned, the drugs prescribed and their costs, etc.
  • 43. MHC-PMS concerns ➢ Privacy ➢ It is essential that patient information is confidential and is never disclosed to anyone apart from authorised medical staff and the patient themselves. ➢ Safety ➢ Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially suicidal or dangerous patients. ➢ The system must be available when needed otherwise safety may be compromised and it may be impossible to prescribe the correct medication to patients.
  • 44. Case study 3: A wilderness weather station ➢ To help monitor climate change and to improve the accuracy of weather forecasts in remote areas. ➢ These weather stations collect data from a set of instruments that measure temperature and pressure, sunshine, rainfall, wind speed and wind direction. ➢ Wilderness weather stations are part of a larger system, which is a weather information system that collects data from weather stations and makes it available to other systems for processing.
  • 45. Figure : The weather station’s environment used the UML package symbol to indicate that each system is a collection of components and the separate systems are identified using the UML stereotype «system»
  • 46. 1. The weather station system This system is responsible for collecting weather data, carrying out some initial data processing, and transmitting it to the data management system. 2. The data management and archiving system This system collects the data from all of the wilderness weather stations, carries out data processing and analysis, and archives the data in a form that can be retrieved by other systems, such as weather forecasting systems. 3. The station maintenance system This system can communicate by satellite with all wilderness weather stations to monitor the health of these systems and provide reports of problems. It can update the embedded software in these systems. In the event of system problems, this system can also be used to remotely control the weather station.
  • 47. The station software is therefore not just concerned with data collection. It must also: 1. Monitor the instruments, power. and communication hardware and report faults to the management system. 2. Manage the system power, ensuring that batteries are charged whenever the environmental conditions permit but also that generators are shut down in potentially damaging weather conditions, such as high wind. 3. Allow for dynamic reconfiguration where parts of the software are replaced with new versions and where backup instruments are switched into the system in the event of system failure
  • 48. Case study 4: A digital learning environment for schools
  • 49. Chapter 2 – Software Processes 1
  • 50. Topics Covered ➢ Software Process ➢ Software Process Models ➢ Process Activities - Traditional 2
  • 51. The Software Process A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. A software process is a structured set of activities required to develop a software system. Many different software processes but all involve: 1. Specification – defining what the system should do; 2. Design and implementation – defining the organization of the system and implementing the system; 3. Validation – checking that it does what the customer wants; 4. Evolution – changing the system in response to changing customer needs. 3
  • 52. Software Process Descriptions 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. 4
  • 53. Three Different Models 1. Water Fall Model 2. Incremental Model 3. Boehm’s Spiral Model
  • 55.
  • 56. Waterfall Model Phases ➢ There are separate identified phases in the waterfall model: Requirements analysis and definition: The system's services, constraints, and goals are established by consultation with system users. They are then defined in detail and serve as a system specification. System and software design: The systems design process allocates the requirements to either hardware or software systems by establishing an overall system architecture. Software design involves identifying and describing the fundamental software system abstractions and their relationships. Implementation and unit testing: During this stage, the software design is realized as a set of programs or program units. Unit testing involves verifying that each unit meets its specification. Integration and system testing: The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met. After testing, the software system is delivered to the customer. Operation and maintenance: Normally (although not necessarily), this is the longest life cycle phase. The system is installed and put into practical use. Maintenance involves correcting errors which were not discovered in earlier stages of the life cycle, improving the implementation of system units and enhancing the system's services as new requirements are discovered. 9
  • 57. Waterfall Model Problems 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. 10
  • 58. Advantages and Disadvantages in Water Fall model Advantages
  • 59. Model 2: Incremental development model Specification, development and validation are interleaved. The system is developed as a series of versions (increments), with each version adding functionality to the previous version until the required system has been developed. May be plan-driven or agile.
  • 60. Advantages and Disadvantages in Incremental development model Benefits of incremental development(Advantages): ▪ Lower cost of changes: 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. ▪ Frequent feedback: 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. ▪ Faster delivery: 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. Problems with incremental development (from the management perspective)(Disadvantages) ▪ 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.
  • 62. Figure shows a general process model for reuse-based development, based on integration and configuration. The stages in this process are: 1.Requirements specification: The initial requirements for the system are proposed. Includes brief descriptions of essential requirements and desirable system features. 2. Software discovery and evaluation: Given an outline of the software requirements, a search is made for components and systems that provide the functionality required. Candidate components and systems are evaluated to see if they meet the essential requirements and if they are generally suitable for use in the system. 3. Requirements refinement: During this stage, the requirements are refined using information about the reusable components and applications that have been discovered. The requirements are modified to reflect the available components, and the system specification is re-defined. Where modifications are impossible, the component analysis activity may be reentered to search for alternative solutions. 4. Application system configuration: If an off-the-shelf application system that meets the requirements is available, it may then be configured for use to create the new system. 5. Component adaptation and integration: If there is no off-the-shelf system, individual reusable components may be modified and new components developed. These are then integrated to create the system.
  • 63. Types of software components are frequently reused: • Web services that are developed according to service standards and which are available for remote invocation. • Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. • Stand-alone commercial-off-the-shelf systems (COTS) that are configured for use in a particular environment.
  • 64. Process activities ➢ The four basic process activities of specification, 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 interleaved. ➢ How these activities are carried out depends on the type of software being developed, the experience and competence of the developers, and the type of organization developing the software.
  • 66. There are three main activities in the requirements engineering process: 1. Requirements elicitation and analysis: This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on. This may involve the development of one or more system models and prototypes. These help you understand the system to be specified. 2. Requirements specification: It is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; system requirements are a more detailed description of the functionality to be provided. 3. Requirements validation: This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.
  • 67. 2. Software design and implementation ➢ Software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used. ➢ Designers add detail as they develop their design, with constant backtracking to modify earlier designs. ➢ The design process activities are both interleaved and interdependent.
  • 68.
  • 69. Figure shows four activities that may be part of the design process for information systems: ➢ ‘software platform’- the environment in which the software will execute. ➢ Most software interfaces with other software systems like operating system, database, middleware, and other application systems. ➢ If the system is to process existing data, then the description of that data may be included in the platform specification. Otherwise, the data description must be an input to the design process so that the system data organization can be defined. ➢ The activities in the design process vary, depending on the type of system being developed. Four activities that may be part of the design process for information systems: 1. Architectural design, where you identify the overall structure of the system, the principal components (sometimes called subsystems or modules), their relationships, and how they are distributed. 2. Database design, where you design the system data structures and how these are to be represented in a database. Again, the work here depends on whether an existing database is to be reused or a new database is to be created.
  • 70. 3.Interface design, where you define the interfaces between system components. With a precise interface, a component may be used by other components without them having to know how it is implemented. 4.Component selection and design, where you search for reusable components and, if no suitable components are available, design new software components. Alternatively, it may be a list of changes to be made to a reusable component or a detailed design model expressed in the UML. The design model may then be used to automatically generate an implementation.
  • 71. 3. Software validation verification and validation (V & V) is intended to show that a system both conforms to its specification and meets the expectations of the system customer. ➢Figure 2.6 shows a three-stage testing process in which system components are individually tested, then the integrated system is tested. ➢For custom software, customer testing involves testing the system with real customer data. ➢For products that are sold as applications, customer testing is sometimes called beta testing where selected users try out and comment on the software.
  • 72. The stages in the testing process are: ➢ Component testing The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components. Test automation tools, such as JUnit for Java, that can rerun tests when new versions of the component are created, are commonly used. ➢ System testing System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems.It is also concerned with showing that the system meets its functional and non-functional requirements, and testing the emergent system properties. ➢ Customer testing This is the final stage in the testing process before the system is accepted for operational use. The system is tested by the system customer rather than with simulated test data. For custom- built software, customer testing may reveal errors and omissions in the system requirements definition.
  • 73. ➢ When a system is to be marketed as a software product, a testing process called beta testing is often used. Beta testing involves delivering a system to a number of potential customers who agree to use that system. They report problems to the system developers. This exposes the product to real use and detects errors that may not have been anticipated by the product developers. After this feedback, the software product may be modified and released for further beta testing or general sale. ➢ test-driven development, which is a normal part of agile processes, tests are developed along with the requirements before development starts. This helps the testers and developers to understand the requirements and ensures that there are no delays as test cases are created. ➢ When a plan-driven software process is used (e.g., for critical systems development), testing is driven by a set of test plans. An independent team of testers works from these test plans, which have been developed from the system specification and design. ➢ Figure 2.7 illustrates how test plans are the link between testing and development activities. This is sometimes called the V-model of development (turn it on its side to see the V).
  • 74. The V-model shows the software validation activities that correspond to each stage of the waterfall process model.
  • 75. 4. Software evolution The flexibility of software is one of the main reasons why more and more software is being incorporated into large, complex systems. Once a decision has been made to manufacture hardware, it is very expensive to make changes to the hardware design.
  • 76. Coping with change The flexibility of software is one of the main reasons why more and more software is being incorporated into large, complex systems. Once a decision has been made to manufacture hardware, it is very expensive to make changes to the hardware design.
  • 77. The spiral model • The spiral model is an SDLC model that combines elements of an iterative(prototype) software development model with a waterfall model. It is advisable to use this model for expensive, large and complex projects.
  • 78.
  • 79. Spiral Model Phases 1.Determine objectives and find alternate solutions – This phase includes requirement gathering and analysis. Based on the requirements, objectives are defined and different alternate solutions are proposed. 2.Risk Analysis and resolving – In this quadrant, all the proposed solutions are analyzed and any potential risk is identified, analyzed, and resolved. 3.Develop and test: This phase includes the actual implementation of the different features. All the implemented features are then verified with thorough testing. 4.Review and planning of the next phase – In this phase, the software is evaluated by the customer. It also includes risk identification and monitoring like cost overrun or schedule slippage and after that planning of the next phase is started.
  • 80. Spiral Model Advantages and Disadvantages Advantages 1. The spiral model is perfect for projects that are large and complex in nature as continuous prototyping and evaluation help in mitigating any risk. 2. Because of its risk handling ability, the model is best suited for projects which are very critical like software related to the health domain, space exploration, etc. 3. This model supports the client feedback and implementation of change requests (CRs) which is not possible in conventional models like a waterfall. 4. Since customer gets to see a prototype in each phase, so there are higher chances of customer satisfaction. Disadvantages 1. Because of the prototype development and risk analysis in each phase, it is very expensive and time taking. 2. It is not suitable for a simpler and smaller project because of multiple phases. 3. It requires more documentation as compared to other models. 4. Project deadlines can be missed since the number of phases is unknown in the beginning and frequent prototyping and risk analysis can make things worse.
  • 81. Requirements engineering understand the concepts of user and system requirements and why these requirements should be written in different ways; ■ understand the differences between functional and non- functional software requirements; ■ understand the main requirements engineering activities of elicitation, analysis, and validation, and the relationships between these activities; ■ understand why requirements management is necessary
  • 82. A FEASIBILITY study is a short, focused study that should take place early in the RE process. It should answer three key questions: (1) Does the system contribute to the overall objectives of the organization? (2) Can the system be implemented within schedule and budget using current technology? and (3) Can the system be integrated with other systems that are used?
  • 83. Functional and non-functional requirements 1.Functional requirements: These are statements of services the system should provide, how the system should react to particular inputs, and how the system should behave in particular situations. In some cases, the functional requirements may also explicitly state what the system should not do. 2. Non-functional requirements: These are constraints on the services or functions offered by the system. They include timing constraints, constraints on the development process, and constraints imposed by standards. Non- functional requirements often apply to the system as a whole rather than individual system features or services.
  • 84. Functional requirements Examples of functional requirements for the Mentcare system, used to maintain information about patients receiving treatment for mental health problems: 1. A user shall be able to search the appointments lists for all clinics. 2. The system shall generate each day, for each clinic, a list of patients who are expected to attend appointments that day. 3. Each staff member using the system shall be uniquely identified by his or her eight-digit employee number.
  • 85. ➢ System developers may interpret the requirement so that it is easier to implement For Example: A medical staff member specifying a search requirement may expect “search” to mean that, given a patient name, the system looks for that name in all appointments at all clinics. However, this is not explicit in the requirement.
  • 86. Non-functional requirements They are divided into two main categories: Execution qualities like security and usability, which are observable at run time. Evolution qualities like testability, extensibility, and scalability that embodied in the static structure of the software system. Non-functional requirements specify the software's quality attribute. These requirements define the general characteristics, behavior of the system, and features that affect the experience of the user. They ensure a better user experience, minimizes the cost factor. Non-functional requirements ensure that the software system must follow the legal and adherence rules. The impact of the non-functional requirements is not on the functionality of the system, but they impact how it will perform.
  • 87.
  • 88. CLASSIFICATION OF NON-FUNCTIONAL REQUIREMENTS. We can see from this diagram that the non- functional requirements may come from ➢ Required Characteristics Of The Software (Product Requirements), ➢ The Organization Developing The Software (Organizational Requirements), ➢ Or External Sources
  • 89.
  • 90. 1. Product requirements These requirements specify or constrain the runtime behavior of the software. Examples include performance requirements for how fast the system must execute and how much memory it requires; reliability requirements that set out the acceptable failure rate; security requirements; and usability requirements. 2. Organizational requirements These requirements are broad system requirements derived from policies and procedures in the customer’s and developer’s organizations. Examples include operational process requirements that define how the system will be used; development process requirements that specify the programming language; the development environment or process standards to be used; and environmental requirements that specify the operating environment of the system. 3. External requirements This broad heading covers all requirements that are derived from factors external to the system and its development process. These may include regulatory requirements that set out what must be done for the system to be approved for use by a regulator, such as a nuclear safety authority; legislative requirements that must be followed to ensure that the system operates within the law; and ethical requirements that ensure that the system will be acceptable to its users and the general public
  • 93. 4.3 Requirements elicitation • The requirements elicitation and analysis process
  • 94. 1. Requirements discovery and understanding This is the process of interacting with stakeholders of the system to discover their requirements. Domain requirements from stakeholders and documentation are also discovered during this activity. 2. Requirements classification and organization This activity takes the unstructured collection of requirements, groups related requirements and organizes them into coherent clusters. 3. Requirements prioritization and negotiation Inevitably, when multiple stakeholders are involved, requirements will conflict. This activity is concerned with prioritizing requirements and finding and resolving requirements conflicts through negotiation. Usually, stakeholders have to meet to resolve differences and agree on compromise requirements. 4. Requirements documentation The requirements are documented and input into the next round of the spiral. An early draft of the software requirements documents may be produced at this stage, or the requirements may simply be maintained informally on whiteboards, wikis, or other shared spaces.
  • 95. • Domain requirements are expectations related to a particular type of software, purpose or industry vertical. Domain requirements can be functional or nonfunctional. The common factor for domain requirements is that they meet established standards or widely accepted feature sets for that category of software project. • Example: medical equipment or educational software. In medical equipment, software must be developed per IEC 60601 regarding medical electrical equipment's basic safety and performance.