SlideShare a Scribd company logo
1 of 72
SHARBANI
BHATTACHARYA
Software Engineering-
Software Development Life Cycle
Govt. Polytechnic(W)
Faridabad
26th August 2016
Software Development Life
Cycle Models
 Waterfall Model
 Prototype Model
 Iterative or Evolutionary Model
 Spiral Model
 V – Model
 Big Bang Model
Software Development Life
Cycle
Communication
Communication with customer or requirement
analysis. Communication in team and
management of Software Company.
The user contacts the service provider and tries
to negotiate the terms, submits the request to
the service providing organization in writing.
Requirement Gathering
Gathering of information and put don into papers
or system specification and requirement
specification.
 Studying the existing or obsolete system and
software
 Conducting interviews of users and developers
 Referring to the database
 Collecting answers from the questionnaires
Feasibility Study
 After requirement gathering, the team comes up
with a rough plan of software process.
 At this step the team analyzes if a software can be
designed to fulfill all requirements of the user, and
if there is any possibility of software being no
more useful.
 It is also analyzed if the project is financially,
practically, and technologically feasible for the
organization to take up.
 There are many algorithms available, which help
the developers to conclude the feasibility of a
software project.
System Analysis
Analysis of the system and its working methods.
Workflow and dataflow is conceptualized.
 At this step the developers decide a roadmap of
their plan and try to bring up the best software
model suitable for the project.
 System analysis includes understanding of
software product limitations, learning system
related problems or changes to be done in
existing systems beforehand, identifying and
addressing the impact of project on organization
and personnel etc.
 The project team analyzes the scope of the
project and plans the schedule and resources
accordingly.
Software Design
Designing of the system. Defining , selecting and
planning architectural model.
To bring down whole knowledge of requirements
and analysis on the desk and design the software
product. The inputs from users and information
gathered in requirement gathering phase are the
inputs of this step.
The output of this step comes in the form of two
designs; logical design, and physical design.
Engineers produce meta-data and data dictionaries,
logical diagrams, data-flow diagrams, and in some
cases pseudo codes.
Coding
This step is also known as programming phase.
The implementation of software design starts in
terms of writing program code in the suitable
programming language and developing error-
free executable programs efficiently.
Testing
An estimate says that 50% of whole software
development process should be tested. Errors
may ruin the software from critical level to its
own removal.
Software testing is done while coding by the
developers and thorough testing is conducted by
testing experts at various levels of code such as
module testing, program testing, product testing,
in-house testing, and testing the product at
user’s end.
Early discovery of errors and their remedy is the
key to reliable software.
Integration
Software may need to be integrated with the
libraries, databases, and other program(s). This
stage of SDLC is involved in the integration of
software with outer world entities.
Implementation
This means installing the software on user
machines. At times, software needs post-
installation configurations at user end. Software
is tested for portability and adaptability and
integration related issues are solved during
implementation.
Operation & Maintenance
This phase confirms the software operation in
terms of more efficiency and less errors.
If required, the users are trained on, or aided
with the documentation on how to operate the
software and how to keep the software
operational.
The software is maintained timely by updating
the code according to the changes taking place
in user end environment or technology.
This phase may face challenges from hidden
bugs and real-world unidentified problems.
Disposition
Softwares which cannot be used further and
cannot changed either have to be disposed off.
 Example- Foxpro systems are dispose off or
new system on ERP on Oracle is developed
in a company.
 Oracle systems are dispose off or new system
on ERP on SAP is developed in a company.
Waterfall Model
Waterfall Model
 Requirements analysis and definition
 System and software design
 Implementation and unit testing
 Integration and system testing
 Operation and maintenance
Waterfall Model
The first published model of the software
development process was derived from
more general system engineering processes
(Royce, 1970).
Waterfall Model
Because of the cascade from one phase to
another, this model is known as the ‘waterfall
model’ or software life cycle. The waterfall model
is an example of a plan-driven process—in
principle, you must plan and schedule all of the
process activities before starting work on them.
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.
Drawbacks of Waterfall Model
Its major problem is the inflexible partitioning
of the project into distinct stages. Commitments
must be made at an early stage in the process,
which makes it difficult to respond to changing
customer requirements.
Formal System Development
An important variant of the waterfall model is
formal system development, where a
mathematical model of a system specification is
created.
This model is then refined, using mathematical
transformations that preserve its consistency,
into executable code.
Based on the assumption that your
mathematical transformations are correct, you
can therefore make a strong argument that a
program generated in this way is consistent with
its specification.
Formal System Development
Formal development processes, such as that
based on the B method by Schneider,2001 and
Wordsworth, 1996.
Formal Development
Processes
It is particularly suited to the development of
systems that have stringent safety, reliability, or
security requirements.
The formal approach simplifies the production of
a safety or security case. This demonstrates to
customers or regulators that the system actually
meets its safety or security requirements.
Formal Development
Processes
Processes based on formal transformations are
generally only used in the development of
safety-critical or security-critical systems.
They require specialized expertise. For the
majority of systems this process does not offer
significant cost benefits over other approaches
to system development.
Prototype Model
A prototype is an initial version of a software
system that is used to demonstrate concepts, try
out design options, and find out more about the
problem and its possible solutions.
Rapid, iterative development of the prototype is
essential so that costs are controlled and system
stakeholders can experiment with the prototype
early in the software process.
Prototype Model
Prototype Model
A software prototype can be used in a software
development process to help anticipate changes
that
1. In the requirements engineering process, a
prototype can help with the elicitation and
validation of system requirements.
2. In the system design process, a prototype can
be used to explore particular software solutions
and to support user interface design.
Drawbacks of Prototype
Model
 A general problem with prototyping is that the prototype may
not necessarily be used in the same way as the final system.
 The tester of the prototype may not be typical of system
users.
 The training time during prototype evaluation may be
insufficient.
 If the prototype is slow, the evaluators may adjust their way of
working and avoid those system features that have slow
response times. When provided with better response in the
final system, they may use it in a different way.
 Developers are sometimes pressured by managers to deliver
throwaway prototypes, particularly when there are delays in
delivering the final version of the software.
Prototypes Benefits
 Prototypes do not have to be executable to be
useful. Paper-based mock-ups of the system user
interface (Rettig, 1994) can be effective in helping
users refine an interface design and work through
usage scenarios. These are very cheap to
develop and can be constructed in a few days.
 An extension of this technique is a Wizard of Oz
prototype where only the user interface is
developed. Users interact with this interface but
their requests are passed to a person who
interprets them and outputs the appropriate
response.
Iterative or Evolutionary Model
Incremental Development
Incremental development is based on the idea of
developing an initial implementation, exposing
this to user comment and evolving it through
several versions until an adequate system has
been developed
Iterative or Evolutionary
Model
 Incremental software development, which is a
fundamental part of agile approaches, is better
than a waterfall approach for most business, e-
commerce, and personal systems. Incremental
development reflects the way that we solve
problems.
Iterative or Evolutionary Model
Incremental & Waterfall
Incremental development has three important benefits,
compared to the waterfall model:
1.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.
2. 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. Customers find it difficult to
judge progress from software design documents.
3. More rapid delivery and deployment of useful software
to the customer is possible, even if all of the functionality
has not been included. Customers are able to use and
Incremental Delivery
Advantages: Customers can use the early increments as
prototypes and gain experience that informs their
requirements for later system increments. Unlike
prototypes, these are part of the real system so
there is no re-learning when the complete system
is available.
 Customers do not have to wait until the entire
system is delivered before they can gain value
from it. The first increment satisfies their most
critical requirements so they can use the software
immediately.
 The process maintains the benefits of incremental
development in that it should be relatively easy to
incorporate changes into the system.
 As the highest-priority services are delivered first
and increments then integrated, the most
Drawbacks of Incremental
Model
 Most systems require a set of basic facilities that are used by
different parts of the system. As requirements are not defined
in detail until an increment is to be implemented, it can be
hard to identify common facilities that are needed by all
increments.
 Iterative development can also be difficult when a replacement
system is being developed. Users want all of the functionality
of the old system and are often unwilling to experiment with
an incomplete new system. Therefore, getting useful customer
feedback is difficult.
 The essence of iterative processes is that the specification is
developed in conjunction with the software. However, this
conflicts with the procurement model of many organizations,
where the complete system specification is part of the system
development contract. In the incremental approach, there is
no complete system specification until the final increment is
specified. This requires a new form of contract, which large
customers such as government agencies may find difficult to
accommodate.
Spiral Model
Boehm’s Spiral Model
A risk-driven software process framework
(the spiral model) was proposed by
Boehm (1988).
Spiral Model
The software process is represented as a spiral,
rather than a sequence of activities with some
backtracking from one activity to another.
Each loop in the spiral represents a phase of the
software process.
Thus, the innermost loop might be concerned
with system feasibility, the next loop with
requirements definition, the next loop with
system design, and so on.
Spiral Model
Each loop in the spiral is split into four sectors:
 Objective setting
 Risk assessment and reduction
 Development and validation
 Planning
Objective Setting
Specific objectives for that phase of the project
are defined. Constraints on the process and the
product are identified and a detailed
management plan is drawn up.
Project risks are identified. Alternative strategies,
depending on these risks, may be planned.
Risk Assessment and Reduction
For each of the identified project risks, a detailed
analysis is carried out. Steps are taken to reduce
the risk.
For example, if there is a risk that the
requirements are inappropriate, a prototype
system may be developed.
Development and Validation
After risk evaluation, a development model for
the
system is chosen. For example, throwaway
prototyping may be the best development
approach if user interface risks are dominant.
If safety risks are the main consideration,
development based on formal transformations
may be the most appropriate process, and so
on. If the main identified risk is sub-system
integration, the waterfall model may be the best
development model to use.
Planning
 The project is reviewed and a decision made
whether to continue with a further loop of the
spiral. If it is decided to continue, plans are
drawn up for the next phase of the project.
V – Model
V- Model
 At every stage, test plans and test cases are
created to verify and validate the product
according to the requirement of that stage.
 For example, in requirement gathering stage
the test team prepares all the test cases in
correspondence to the requirements.
V -Model
Later, when the product is developed and is
ready for testing, test cases of this stage verify
the software against its validity towards
requirements at this stage.
This makes both verification and validation go in
parallel. This model is also known as verification
and validation model.
Big Bang Model
Big Bang Model
This model is the simplest model in its form. It
requires little planning, lots of programming and
lots of funds. This model is conceptualized
around the big bang of universe.
As scientists say that after big bang lots of
galaxies, planets, and stars evolved just as an
event. Likewise, if we put together lots of
programming and funds, you may achieve the
best software product.
Big Bang Model
For this model, very small amount of planning is
required. It does not follow any process, or at
times the customer is not sure about the
requirements and future needs. So the input
requirements are arbitrary.
This model is not suitable for large software
projects but good one for learning and
experimenting.
Reuse-Oriented Development
Model
Reuse-oriented approaches rely on a large base
of reusable software components and an
integrating framework for the composition of
these components.
Sometimes, these components are systems in
their own right (COTS or commercial off-the-
shelf systems) that may provide specific
functionality such as word processing or a
spreadsheet.
Reuse-Oriented Development
Model
Although the initial requirements specification
stage and the validation stage are comparable
with other software processes, the intermediate
stages in a reuse oriented process are different.
Reuse-Oriented Development
Model
Reuse-Oriented Development
Model
The intermediate stages apart initial
requirements specification stage and the
validation stage from are
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration
Component Analysis
 Given the requirements specification, a search
is made for components to implement that
specification.
 Usually, there is no exact match and the
components that may be used only provide
some of the functionality required.
Requirements Modification
 During this stage, the requirements are
analyzed using information about the
components that have been discovered.
 They are then modified to reflect the available
components. Where modifications are
impossible, the component analysis activity
may be re-entered to search for alternative
solutions.
System Design with Reuse
 During this phase, the framework of the
system is designed or an existing framework is
reused.
 The designers take into account the
components that are reused and organize the
framework to cater for this.
 Some new software may have to be designed
if reusable components are not available.
Development and Integration
 Software that cannot be externally procured is
developed, and the components and COTS
systems are integrated to create the new
system.
 System integration, in this model, may be part
of the development process rather than a
separate activity.
Software Reuse-Oriented
Process
There are three types of software component
that may be used in a reuse-oriented process:
1. Web services that are developed according to
service standards and which are available for
remote invocation.
2. Collections of objects that are developed as a
package to be integrated with a component
framework such as .NET or J2EE.
3. Stand-alone software systems that are
configured for use in a particular environment.
Rational Unified Process
Model
RUP is a modern generic process model that is
organized into phases
-inception, elaboration, construction, and
transition
but separates activities
-requirements, analysis, and design, etc.
from these phases.
Rational Unified Process
Model
Philippe Krutchen,2003
Rational Unified Process
Model
1.Develop software iteratively Plan increments of the system
based on customer priorities and develop the highest-priority
system features early in the development process.
2. Manage requirements Explicitly document the customer’s
requirements and keep track of changes to these requirements.
Analyze the impact of changes on the system before accepting
them.
3. Use component-based architectures Structure the system
architecture into components, as discussed earlier in this
chapter.
4. Visually model software Use graphical UML models to present
static and dynamic views of the software.
5. Verify software quality Ensure that the software meets the
organizational quality standards.
6. Control changes to software Manage changes to the software
using a change management system and configuration
management procedures and tools.
Rational Unified Process
Model
1. A dynamic perspective, which shows the
phases of the model over time.
2. A static perspective, which shows the process
activities that are enacted.
3. A practice perspective, which suggests good
practices to be used during the process.
Drawbacks of RUP Model
The RUP is not a suitable process for all types of
development, e.g., embedded software
development.
Advantages RUP Model
 The most important innovations in the RUP are
the separation of phases and workflows, and
the recognition that deploying software in a
user’s environment is part of the process.
 Phases are dynamic and have goals.
 Workflows are static and are technical
activities that are not associated with a single
phase but may be used throughout the
development to achieve the goals of each
phase.
REFERENCES
 Software Engineering by Somerville
 Software Engineering-Pressman
 Software Engineering Tutorial Point
 Software Engineering Wikipedia
THANK YOU

More Related Content

What's hot

962 sech04
962 sech04962 sech04
962 sech04
aldwal
 
Software engineering Questions and Answers
Software engineering Questions and AnswersSoftware engineering Questions and Answers
Software engineering Questions and Answers
Bala Ganesh
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
A Subbiah
 
Sdlc process document
Sdlc process documentSdlc process document
Sdlc process document
Pesara Swamy
 
Study of solution development methodology for small size projects.
Study of solution development methodology for small size projects.Study of solution development methodology for small size projects.
Study of solution development methodology for small size projects.
Joon ho Park
 

What's hot (20)

962 sech04
962 sech04962 sech04
962 sech04
 
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
Report on SOFTWARE DEVELOPMENT LIFE CYCLE SDLC
 
SDLC Model
SDLC  ModelSDLC  Model
SDLC Model
 
Software process
Software processSoftware process
Software process
 
Swe notes
Swe notesSwe notes
Swe notes
 
Ch4
Ch4Ch4
Ch4
 
Software engineering Questions and Answers
Software engineering Questions and AnswersSoftware engineering Questions and Answers
Software engineering Questions and Answers
 
Software Maintenance
Software MaintenanceSoftware Maintenance
Software Maintenance
 
Software Engineering - Lecture 01
Software Engineering - Lecture 01Software Engineering - Lecture 01
Software Engineering - Lecture 01
 
Lecture 4 software process model (2)
Lecture 4   software process model (2)Lecture 4   software process model (2)
Lecture 4 software process model (2)
 
Software development life cycle
Software development life cycleSoftware development life cycle
Software development life cycle
 
Sdlc process document
Sdlc process documentSdlc process document
Sdlc process document
 
Study of solution development methodology for small size projects.
Study of solution development methodology for small size projects.Study of solution development methodology for small size projects.
Study of solution development methodology for small size projects.
 
SDLC
SDLCSDLC
SDLC
 
Slides chapters 26-27
Slides chapters 26-27Slides chapters 26-27
Slides chapters 26-27
 
Ian Sommerville, Software Engineering, 9th EditionCh 8
Ian Sommerville,  Software Engineering, 9th EditionCh 8Ian Sommerville,  Software Engineering, 9th EditionCh 8
Ian Sommerville, Software Engineering, 9th EditionCh 8
 
Software engineering-quiz
Software engineering-quizSoftware engineering-quiz
Software engineering-quiz
 
software Processes
software Processessoftware Processes
software Processes
 
testing
testingtesting
testing
 
11 system development models
11 system development models11 system development models
11 system development models
 

Similar to Slcm sharbani bhattacharya

Mi0033 software engineering
Mi0033  software engineeringMi0033  software engineering
Mi0033 software engineering
smumbahelp
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Management
swatisinghal
 

Similar to Slcm sharbani bhattacharya (20)

SE-Lecture-2.pptx
SE-Lecture-2.pptxSE-Lecture-2.pptx
SE-Lecture-2.pptx
 
16346915.ppt
16346915.ppt16346915.ppt
16346915.ppt
 
System analsis and design
System analsis and designSystem analsis and design
System analsis and design
 
Chapter 2.pptx
Chapter 2.pptxChapter 2.pptx
Chapter 2.pptx
 
Elementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptxElementary Probability theory Chapter 2.pptx
Elementary Probability theory Chapter 2.pptx
 
Prototyping
PrototypingPrototyping
Prototyping
 
Mi0033 software engineering
Mi0033  software engineeringMi0033  software engineering
Mi0033 software engineering
 
SDLC and Software Process Models
SDLC and Software Process ModelsSDLC and Software Process Models
SDLC and Software Process Models
 
Software Engineering Overview
Software Engineering OverviewSoftware Engineering Overview
Software Engineering Overview
 
System Development
System  DevelopmentSystem  Development
System Development
 
reaserch ppt.pptx
reaserch ppt.pptxreaserch ppt.pptx
reaserch ppt.pptx
 
3. ch 2-process model
3. ch 2-process model3. ch 2-process model
3. ch 2-process model
 
Introduction,Software Process Models, Project Management
Introduction,Software Process Models, Project ManagementIntroduction,Software Process Models, Project Management
Introduction,Software Process Models, Project Management
 
SE-03.pptx
SE-03.pptxSE-03.pptx
SE-03.pptx
 
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
 
ISE_Lecture Week 2-SW Process Models.ppt
ISE_Lecture Week 2-SW Process Models.pptISE_Lecture Week 2-SW Process Models.ppt
ISE_Lecture Week 2-SW Process Models.ppt
 
Software Development Life Cycle Part II
Software Development Life Cycle Part IISoftware Development Life Cycle Part II
Software Development Life Cycle Part II
 
Software models
Software modelsSoftware models
Software models
 
Software engineering introduction
Software engineering introductionSoftware engineering introduction
Software engineering introduction
 
Planning the development process
Planning the development processPlanning the development process
Planning the development process
 

More from Sharbani Bhattacharya

More from Sharbani Bhattacharya (20)

Biometric authentication green apple computer learning
Biometric authentication green apple computer learningBiometric authentication green apple computer learning
Biometric authentication green apple computer learning
 
Javascript
JavascriptJavascript
Javascript
 
PHP programmimg
PHP programmimgPHP programmimg
PHP programmimg
 
Sharbani Bhattacharya SE design & Implementation
Sharbani Bhattacharya SE design & ImplementationSharbani Bhattacharya SE design & Implementation
Sharbani Bhattacharya SE design & Implementation
 
Visual Basic –User Interface- V
Visual Basic –User Interface- VVisual Basic –User Interface- V
Visual Basic –User Interface- V
 
Visual Basic User Interface-VI
Visual Basic User Interface-VIVisual Basic User Interface-VI
Visual Basic User Interface-VI
 
Microsoft Front Page
Microsoft Front PageMicrosoft Front Page
Microsoft Front Page
 
Visual Basic User Interface-III
Visual Basic User Interface-IIIVisual Basic User Interface-III
Visual Basic User Interface-III
 
Visual Basic User Interface -IV
Visual Basic User Interface -IVVisual Basic User Interface -IV
Visual Basic User Interface -IV
 
Requirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharyaRequirement Analysis & Specification sharbani bhattacharya
Requirement Analysis & Specification sharbani bhattacharya
 
Estimation sharbani bhattacharya
Estimation sharbani bhattacharyaEstimation sharbani bhattacharya
Estimation sharbani bhattacharya
 
Sharbani bhattacharya Visual Basic User Interface-ii
Sharbani bhattacharya  Visual Basic User Interface-iiSharbani bhattacharya  Visual Basic User Interface-ii
Sharbani bhattacharya Visual Basic User Interface-ii
 
Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1Sharbani Bhattacharya VB User Interface1
Sharbani Bhattacharya VB User Interface1
 
Sharbani bhattacharya VB Structures
Sharbani bhattacharya VB StructuresSharbani bhattacharya VB Structures
Sharbani bhattacharya VB Structures
 
Software Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani BhattacharyaSoftware Metrics & Measurement-Sharbani Bhattacharya
Software Metrics & Measurement-Sharbani Bhattacharya
 
SE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharyaSE Introduction sharbani bhattacharya
SE Introduction sharbani bhattacharya
 
Sharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flashSharbani bhattacharya Macromedia-flash
Sharbani bhattacharya Macromedia-flash
 
Sharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual BasicSharbani bhattacharya Visual Basic
Sharbani bhattacharya Visual Basic
 
Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014Sharbani bhattacharya gyanodya 2014
Sharbani bhattacharya gyanodya 2014
 
Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014Sharbani bhattacharya sacta 2014
Sharbani bhattacharya sacta 2014
 

Recently uploaded

21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx
rahulmanepalli02
 
Introduction to Robotics in Mechanical Engineering.pptx
Introduction to Robotics in Mechanical Engineering.pptxIntroduction to Robotics in Mechanical Engineering.pptx
Introduction to Robotics in Mechanical Engineering.pptx
hublikarsn
 
Standard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayStandard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power Play
Epec Engineered Technologies
 
INTERRUPT CONTROLLER 8259 MICROPROCESSOR
INTERRUPT CONTROLLER 8259 MICROPROCESSORINTERRUPT CONTROLLER 8259 MICROPROCESSOR
INTERRUPT CONTROLLER 8259 MICROPROCESSOR
TanishkaHira1
 
scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
HenryBriggs2
 

Recently uploaded (20)

Dr Mrs A A Miraje C Programming PPT.pptx
Dr Mrs A A Miraje C Programming PPT.pptxDr Mrs A A Miraje C Programming PPT.pptx
Dr Mrs A A Miraje C Programming PPT.pptx
 
Fundamentals of Internet of Things (IoT) Part-2
Fundamentals of Internet of Things (IoT) Part-2Fundamentals of Internet of Things (IoT) Part-2
Fundamentals of Internet of Things (IoT) Part-2
 
TMU_GDSC_20240509.pdfTMU_GDSC_20240509.pdf
TMU_GDSC_20240509.pdfTMU_GDSC_20240509.pdfTMU_GDSC_20240509.pdfTMU_GDSC_20240509.pdf
TMU_GDSC_20240509.pdfTMU_GDSC_20240509.pdf
 
21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx21P35A0312 Internship eccccccReport.docx
21P35A0312 Internship eccccccReport.docx
 
analog-vs-digital-communication (concept of analog and digital).pptx
analog-vs-digital-communication (concept of analog and digital).pptxanalog-vs-digital-communication (concept of analog and digital).pptx
analog-vs-digital-communication (concept of analog and digital).pptx
 
Post office management system project ..pdf
Post office management system project ..pdfPost office management system project ..pdf
Post office management system project ..pdf
 
Introduction to Robotics in Mechanical Engineering.pptx
Introduction to Robotics in Mechanical Engineering.pptxIntroduction to Robotics in Mechanical Engineering.pptx
Introduction to Robotics in Mechanical Engineering.pptx
 
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdflitvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
litvinenko_Henry_Intrusion_Hong-Kong_2024.pdf
 
Standard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power PlayStandard vs Custom Battery Packs - Decoding the Power Play
Standard vs Custom Battery Packs - Decoding the Power Play
 
Ground Improvement Technique: Earth Reinforcement
Ground Improvement Technique: Earth ReinforcementGround Improvement Technique: Earth Reinforcement
Ground Improvement Technique: Earth Reinforcement
 
Independent Solar-Powered Electric Vehicle Charging Station
Independent Solar-Powered Electric Vehicle Charging StationIndependent Solar-Powered Electric Vehicle Charging Station
Independent Solar-Powered Electric Vehicle Charging Station
 
Presentation on Slab, Beam, Column, and Foundation/Footing
Presentation on Slab,  Beam, Column, and Foundation/FootingPresentation on Slab,  Beam, Column, and Foundation/Footing
Presentation on Slab, Beam, Column, and Foundation/Footing
 
Overview of Transformation in Computer Graphics
Overview of Transformation in Computer GraphicsOverview of Transformation in Computer Graphics
Overview of Transformation in Computer Graphics
 
Dynamo Scripts for Task IDs and Space Naming.pptx
Dynamo Scripts for Task IDs and Space Naming.pptxDynamo Scripts for Task IDs and Space Naming.pptx
Dynamo Scripts for Task IDs and Space Naming.pptx
 
INTERRUPT CONTROLLER 8259 MICROPROCESSOR
INTERRUPT CONTROLLER 8259 MICROPROCESSORINTERRUPT CONTROLLER 8259 MICROPROCESSOR
INTERRUPT CONTROLLER 8259 MICROPROCESSOR
 
Databricks Generative AI Fundamentals .pdf
Databricks Generative AI Fundamentals  .pdfDatabricks Generative AI Fundamentals  .pdf
Databricks Generative AI Fundamentals .pdf
 
Fundamentals of Structure in C Programming
Fundamentals of Structure in C ProgrammingFundamentals of Structure in C Programming
Fundamentals of Structure in C Programming
 
Danikor Product Catalog- Screw Feeder.pdf
Danikor Product Catalog- Screw Feeder.pdfDanikor Product Catalog- Screw Feeder.pdf
Danikor Product Catalog- Screw Feeder.pdf
 
Introduction to Geographic Information Systems
Introduction to Geographic Information SystemsIntroduction to Geographic Information Systems
Introduction to Geographic Information Systems
 
scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
scipt v1.pptxcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
 

Slcm sharbani bhattacharya

  • 1. SHARBANI BHATTACHARYA Software Engineering- Software Development Life Cycle Govt. Polytechnic(W) Faridabad 26th August 2016
  • 2. Software Development Life Cycle Models  Waterfall Model  Prototype Model  Iterative or Evolutionary Model  Spiral Model  V – Model  Big Bang Model
  • 3.
  • 5. Communication Communication with customer or requirement analysis. Communication in team and management of Software Company. The user contacts the service provider and tries to negotiate the terms, submits the request to the service providing organization in writing.
  • 6. Requirement Gathering Gathering of information and put don into papers or system specification and requirement specification.  Studying the existing or obsolete system and software  Conducting interviews of users and developers  Referring to the database  Collecting answers from the questionnaires
  • 7. Feasibility Study  After requirement gathering, the team comes up with a rough plan of software process.  At this step the team analyzes if a software can be designed to fulfill all requirements of the user, and if there is any possibility of software being no more useful.  It is also analyzed if the project is financially, practically, and technologically feasible for the organization to take up.  There are many algorithms available, which help the developers to conclude the feasibility of a software project.
  • 8. System Analysis Analysis of the system and its working methods. Workflow and dataflow is conceptualized.  At this step the developers decide a roadmap of their plan and try to bring up the best software model suitable for the project.  System analysis includes understanding of software product limitations, learning system related problems or changes to be done in existing systems beforehand, identifying and addressing the impact of project on organization and personnel etc.  The project team analyzes the scope of the project and plans the schedule and resources accordingly.
  • 9. Software Design Designing of the system. Defining , selecting and planning architectural model. To bring down whole knowledge of requirements and analysis on the desk and design the software product. The inputs from users and information gathered in requirement gathering phase are the inputs of this step. The output of this step comes in the form of two designs; logical design, and physical design. Engineers produce meta-data and data dictionaries, logical diagrams, data-flow diagrams, and in some cases pseudo codes.
  • 10. Coding This step is also known as programming phase. The implementation of software design starts in terms of writing program code in the suitable programming language and developing error- free executable programs efficiently.
  • 11. Testing An estimate says that 50% of whole software development process should be tested. Errors may ruin the software from critical level to its own removal. Software testing is done while coding by the developers and thorough testing is conducted by testing experts at various levels of code such as module testing, program testing, product testing, in-house testing, and testing the product at user’s end. Early discovery of errors and their remedy is the key to reliable software.
  • 12. Integration Software may need to be integrated with the libraries, databases, and other program(s). This stage of SDLC is involved in the integration of software with outer world entities.
  • 13. Implementation This means installing the software on user machines. At times, software needs post- installation configurations at user end. Software is tested for portability and adaptability and integration related issues are solved during implementation.
  • 14. Operation & Maintenance This phase confirms the software operation in terms of more efficiency and less errors. If required, the users are trained on, or aided with the documentation on how to operate the software and how to keep the software operational. The software is maintained timely by updating the code according to the changes taking place in user end environment or technology. This phase may face challenges from hidden bugs and real-world unidentified problems.
  • 15. Disposition Softwares which cannot be used further and cannot changed either have to be disposed off.  Example- Foxpro systems are dispose off or new system on ERP on Oracle is developed in a company.  Oracle systems are dispose off or new system on ERP on SAP is developed in a company.
  • 17. Waterfall Model  Requirements analysis and definition  System and software design  Implementation and unit testing  Integration and system testing  Operation and maintenance
  • 18. Waterfall Model The first published model of the software development process was derived from more general system engineering processes (Royce, 1970).
  • 19. Waterfall Model Because of the cascade from one phase to another, this model is known as the ‘waterfall model’ or software life cycle. The waterfall model is an example of a plan-driven process—in principle, you must plan and schedule all of the process activities before starting work on them.
  • 20. 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.
  • 21. 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.
  • 22. 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.
  • 23. 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.
  • 24. 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.
  • 25. Drawbacks of Waterfall Model Its major problem is the inflexible partitioning of the project into distinct stages. Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements.
  • 26. Formal System Development An important variant of the waterfall model is formal system development, where a mathematical model of a system specification is created. This model is then refined, using mathematical transformations that preserve its consistency, into executable code. Based on the assumption that your mathematical transformations are correct, you can therefore make a strong argument that a program generated in this way is consistent with its specification.
  • 27. Formal System Development Formal development processes, such as that based on the B method by Schneider,2001 and Wordsworth, 1996.
  • 28. Formal Development Processes It is particularly suited to the development of systems that have stringent safety, reliability, or security requirements. The formal approach simplifies the production of a safety or security case. This demonstrates to customers or regulators that the system actually meets its safety or security requirements.
  • 29. Formal Development Processes Processes based on formal transformations are generally only used in the development of safety-critical or security-critical systems. They require specialized expertise. For the majority of systems this process does not offer significant cost benefits over other approaches to system development.
  • 30. Prototype Model A prototype is an initial version of a software system that is used to demonstrate concepts, try out design options, and find out more about the problem and its possible solutions. Rapid, iterative development of the prototype is essential so that costs are controlled and system stakeholders can experiment with the prototype early in the software process.
  • 32. Prototype Model A software prototype can be used in a software development process to help anticipate changes that 1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements. 2. In the system design process, a prototype can be used to explore particular software solutions and to support user interface design.
  • 33. Drawbacks of Prototype Model  A general problem with prototyping is that the prototype may not necessarily be used in the same way as the final system.  The tester of the prototype may not be typical of system users.  The training time during prototype evaluation may be insufficient.  If the prototype is slow, the evaluators may adjust their way of working and avoid those system features that have slow response times. When provided with better response in the final system, they may use it in a different way.  Developers are sometimes pressured by managers to deliver throwaway prototypes, particularly when there are delays in delivering the final version of the software.
  • 34. Prototypes Benefits  Prototypes do not have to be executable to be useful. Paper-based mock-ups of the system user interface (Rettig, 1994) can be effective in helping users refine an interface design and work through usage scenarios. These are very cheap to develop and can be constructed in a few days.  An extension of this technique is a Wizard of Oz prototype where only the user interface is developed. Users interact with this interface but their requests are passed to a person who interprets them and outputs the appropriate response.
  • 36. Incremental Development Incremental development is based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed
  • 37. Iterative or Evolutionary Model  Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, e- commerce, and personal systems. Incremental development reflects the way that we solve problems.
  • 39. Incremental & Waterfall Incremental development has three important benefits, compared to the waterfall model: 1.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. 2. 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. Customers find it difficult to judge progress from software design documents. 3. More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and
  • 40. Incremental Delivery Advantages: Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments. Unlike prototypes, these are part of the real system so there is no re-learning when the complete system is available.  Customers do not have to wait until the entire system is delivered before they can gain value from it. The first increment satisfies their most critical requirements so they can use the software immediately.  The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system.  As the highest-priority services are delivered first and increments then integrated, the most
  • 41. Drawbacks of Incremental Model  Most systems require a set of basic facilities that are used by different parts of the system. As requirements are not defined in detail until an increment is to be implemented, it can be hard to identify common facilities that are needed by all increments.  Iterative development can also be difficult when a replacement system is being developed. Users want all of the functionality of the old system and are often unwilling to experiment with an incomplete new system. Therefore, getting useful customer feedback is difficult.  The essence of iterative processes is that the specification is developed in conjunction with the software. However, this conflicts with the procurement model of many organizations, where the complete system specification is part of the system development contract. In the incremental approach, there is no complete system specification until the final increment is specified. This requires a new form of contract, which large customers such as government agencies may find difficult to accommodate.
  • 43. Boehm’s Spiral Model A risk-driven software process framework (the spiral model) was proposed by Boehm (1988).
  • 44. Spiral Model The software process is represented as a spiral, rather than a sequence of activities with some backtracking from one activity to another. Each loop in the spiral represents a phase of the software process. Thus, the innermost loop might be concerned with system feasibility, the next loop with requirements definition, the next loop with system design, and so on.
  • 45. Spiral Model Each loop in the spiral is split into four sectors:  Objective setting  Risk assessment and reduction  Development and validation  Planning
  • 46. Objective Setting Specific objectives for that phase of the project are defined. Constraints on the process and the product are identified and a detailed management plan is drawn up. Project risks are identified. Alternative strategies, depending on these risks, may be planned.
  • 47. Risk Assessment and Reduction For each of the identified project risks, a detailed analysis is carried out. Steps are taken to reduce the risk. For example, if there is a risk that the requirements are inappropriate, a prototype system may be developed.
  • 48. Development and Validation After risk evaluation, a development model for the system is chosen. For example, throwaway prototyping may be the best development approach if user interface risks are dominant. If safety risks are the main consideration, development based on formal transformations may be the most appropriate process, and so on. If the main identified risk is sub-system integration, the waterfall model may be the best development model to use.
  • 49. Planning  The project is reviewed and a decision made whether to continue with a further loop of the spiral. If it is decided to continue, plans are drawn up for the next phase of the project.
  • 51. V- Model  At every stage, test plans and test cases are created to verify and validate the product according to the requirement of that stage.  For example, in requirement gathering stage the test team prepares all the test cases in correspondence to the requirements.
  • 52. V -Model Later, when the product is developed and is ready for testing, test cases of this stage verify the software against its validity towards requirements at this stage. This makes both verification and validation go in parallel. This model is also known as verification and validation model.
  • 54. Big Bang Model This model is the simplest model in its form. It requires little planning, lots of programming and lots of funds. This model is conceptualized around the big bang of universe. As scientists say that after big bang lots of galaxies, planets, and stars evolved just as an event. Likewise, if we put together lots of programming and funds, you may achieve the best software product.
  • 55. Big Bang Model For this model, very small amount of planning is required. It does not follow any process, or at times the customer is not sure about the requirements and future needs. So the input requirements are arbitrary. This model is not suitable for large software projects but good one for learning and experimenting.
  • 56. Reuse-Oriented Development Model Reuse-oriented approaches rely on a large base of reusable software components and an integrating framework for the composition of these components. Sometimes, these components are systems in their own right (COTS or commercial off-the- shelf systems) that may provide specific functionality such as word processing or a spreadsheet.
  • 57. Reuse-Oriented Development Model Although the initial requirements specification stage and the validation stage are comparable with other software processes, the intermediate stages in a reuse oriented process are different.
  • 59. Reuse-Oriented Development Model The intermediate stages apart initial requirements specification stage and the validation stage from are  Component analysis  Requirements modification  System design with reuse  Development and integration
  • 60. Component Analysis  Given the requirements specification, a search is made for components to implement that specification.  Usually, there is no exact match and the components that may be used only provide some of the functionality required.
  • 61. Requirements Modification  During this stage, the requirements are analyzed using information about the components that have been discovered.  They are then modified to reflect the available components. Where modifications are impossible, the component analysis activity may be re-entered to search for alternative solutions.
  • 62. System Design with Reuse  During this phase, the framework of the system is designed or an existing framework is reused.  The designers take into account the components that are reused and organize the framework to cater for this.  Some new software may have to be designed if reusable components are not available.
  • 63. Development and Integration  Software that cannot be externally procured is developed, and the components and COTS systems are integrated to create the new system.  System integration, in this model, may be part of the development process rather than a separate activity.
  • 64. Software Reuse-Oriented Process There are three types of software component that may be used in a reuse-oriented process: 1. Web services that are developed according to service standards and which are available for remote invocation. 2. Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. 3. Stand-alone software systems that are configured for use in a particular environment.
  • 65. Rational Unified Process Model RUP is a modern generic process model that is organized into phases -inception, elaboration, construction, and transition but separates activities -requirements, analysis, and design, etc. from these phases.
  • 67. Rational Unified Process Model 1.Develop software iteratively Plan increments of the system based on customer priorities and develop the highest-priority system features early in the development process. 2. Manage requirements Explicitly document the customer’s requirements and keep track of changes to these requirements. Analyze the impact of changes on the system before accepting them. 3. Use component-based architectures Structure the system architecture into components, as discussed earlier in this chapter. 4. Visually model software Use graphical UML models to present static and dynamic views of the software. 5. Verify software quality Ensure that the software meets the organizational quality standards. 6. Control changes to software Manage changes to the software using a change management system and configuration management procedures and tools.
  • 68. Rational Unified Process Model 1. A dynamic perspective, which shows the phases of the model over time. 2. A static perspective, which shows the process activities that are enacted. 3. A practice perspective, which suggests good practices to be used during the process.
  • 69. Drawbacks of RUP Model The RUP is not a suitable process for all types of development, e.g., embedded software development.
  • 70. Advantages RUP Model  The most important innovations in the RUP are the separation of phases and workflows, and the recognition that deploying software in a user’s environment is part of the process.  Phases are dynamic and have goals.  Workflows are static and are technical activities that are not associated with a single phase but may be used throughout the development to achieve the goals of each phase.
  • 71. REFERENCES  Software Engineering by Somerville  Software Engineering-Pressman  Software Engineering Tutorial Point  Software Engineering Wikipedia