SlideShare une entreprise Scribd logo
1  sur  58
Télécharger pour lire hors ligne
UNIT I
Introduction to Software Engineering
Presented By

Prof.Hitesh Mohapatra
Dept. of Computer Engg.
Software’s Dual Role


Software is a product





Delivers computing potential
Produces, manages, acquires, modifies, displays, or transmits
information

Software is a vehicle for delivering a product





Supports or directly provides system functionality
Controls other programs (e.g., an operating system)
Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)
What is Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
What is Software?





software is engineered
software doesn’t wear out
software is complex
Wear vs. Deterioration
in re s d fa re
c ae
ilu
ra d e to s e e c
te u
id ffe ts

F ilue
a r
rt
ae

cag
hne
a t ac r e
cu l uv

id a e c r e
e liz d uv
T e
im
Software Applications








system software
application software
engineering/scientific software
embedded software
product-line software
Web Apps (Web applications)
AI software
Software—New Categories






Ubiquitous computing—wireless networks
Net sourcing—the Web as a computing engine
Open source—”free” source code open to the computing
community (a blessing, but also a potential curse!)
Also … (see Chapter 32)





Data mining
Grid computing
Cognitive machines
Software for nanotechnologies
Legacy Software
Why must it change?








software must be adapted to meet the needs of new
computing environments or technology.
software must be enhanced to implement new
business requirements.
software must be extended to make it interoperable
with other more modern systems or databases.
software must be re-architected to make it viable
within a network environment.
Software Myths


Management Myths








Customer myths






We have books of standards, my staff will have sufficient info.
I work very hard to put the latest, greatest, fastest, state-of-the-art
hardware in front of all my programmers.
We have the greatest CASE tools around.
If we get behind, we can just add more programmers.
A general statement of objectives is sufficient to start coding, fill in the
details later.
Project requirements change constantly, but change is easy because
software is flexible.

Programmer myths




Once the program is written and working, our job is done.
Until the program is running, there is no way to assess quality.
The only deliverable for a successful project is the working program.
Software Engineering
Practice
Software engineering practice
- Communication practices
- Planning practices
- Analysis modeling practices
- Design modeling practices
- Construction practices
- Deployment practices
-
Software Engineering Practice








Consists of a collection of concepts, principles, methods, and tools
that a software engineer calls upon on a daily basis
Equips managers to manage software projects and software
engineers to build computer programs
Provides necessary technical and management how to’s in getting
the job done
Transforms a haphazard unfocused approach into something that is
more organized, more effective, and more likely to achieve success
The Essence of Problem Solving
Understand the problem (communication and analysis)

1)
•
•
•
•

Who has a stake in the solution to the problem?
What are the unknowns (data, function, behavior)?
Can the problem be compartmentalized?
Can the problem be represented graphically?

Plan a solution (planning, modeling and software design)

1)
•
•
•

Have you seen similar problems like this before?
Has a similar problem been solved and is the solution reusable?
Can sub problems be defined and are solutions available for the
sub problems?
The Essence of Problem Solving
(continued)
Carry out the plan (construction; code generation)

3)
•

•

Does the solution conform to the plan? Is the source code
traceable back to the design?
Is each component of the solution correct? Has the design and
code been reviewed?

Examine the results for accuracy (testing and quality
assurance)

3)
•
•

Is it possible to test each component of the solution?
Does the solution produce results that conform to the data,
function, and behavior that are required?
Seven Core Principles for Software Engineering
1)

Remember the reason that the software exists
•

1)

Keep it simple, stupid (KISS)
•

1)

Never design yourself into a corner; build software that can be easily
changed and adapted

Plan ahead for software reuse
•

1)

Always specify, design, and implement knowing that someone else will
later have to understand and modify what you did

Be open to the future
•

1)

A clear vision is essential to the project’s success

Others will consume what you produce
•

1)

All design and implementation should be as simple as possible

Maintain the vision of the project
•

1)

The software should provide value to its users and satisfy the
requirements

Reuse of software reduces the long-term cost and increases the value of
the program and the reusable components

Think, then act
•

Placing clear, complete thought before action will almost always
produce better results
Communication Practices
(Requirements Elicitation)

Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling Modelling
Analysis
Tracking
Design
Construction
Code Test

Deployment
Delivery
Support
Feedback
15
Communication Principles
1)
2)
3)
4)
5)
6)
7)
8)
9)

10)

Listen to the speaker and concentrate on what is being said
Prepare before you meet by researching and understanding the
problem
Someone should facility the meeting and have an agenda
Face-to-face communication is best, but also have a document or
presentation to focus the discussion
Take notes and document decisions
Strive for collaboration and consensus
Stay focused on a topic; modularize your discussion
If something is unclear, draw a picture
Move on to the next topic a) after you agree to something, b) if you
cannot agree to something, or c) if a feature or function is unclear
and cannot be clarified at the moment
Negotiation is not a contest or a game; it works best when both
parties win
Planning Practices

(Defining a Road Map)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Modelling
Tracking
Analysis
Design

Construction
Code
Test

Deployment
Delivery
Support
Feedback
17
Planning Principles
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)

Understand the scope of the project
Involve the customer in the planning activity
Recognize that planning is iterative; things will change
Estimate based only on what you know
Consider risk as you define the plan
Be realistic on how much can be done each day by each person
and how well
Adjust granularity as you define the plan
Define how you intend to ensure quality
Describe how you intend to accommodate change
Track the plan frequently and make adjustments as required
Barry Boehm’s W5HH Principle








Why is the system being developed?
What will be done?
When will it be accomplished?
Who is responsible for each function?
Where are they organizationally located?
How will the job be done technically and managerially?
How much of each resource is needed?

The answers to these questions lead to a definition of key
project characteristics and the resultant project plan.
Modeling Practices
(Analysis and Design)
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking

Modelling
Analysis
Design

Construction
Code
Test
Deployment
Delivery
Support
Feedback
Analysis Modeling Principles
1)
2)
3)
4)

5)

The information domain of a problem (the data that flows in and
out of a system) must be represented and understood
The functions that the software performs must be defined
The behavior of the software (as a consequence of external events)
must be represented
The models that depict information, function, and behavior must
be partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion
The analysis task should move from essential information toward
implementation detail
Design Modeling Principles
1)
2)
3)
4)
5)
6)
7)
8)
9)

The design should be traceable to the analysis model
Always consider the software architecture of the system to be built
Design of data is as important as design of processing functions
Interfaces (both internal and external) must be designed with care
User interface design should be tuned to the needs of the end-user
and should stress ease of use
Component-level design should be functionally independent (high
cohesion)
Components should be loosely coupled to one another and to the
external environment
Design representations (models) should be easily understandable
The design should be developed iteratively; with each iteration, the
designer should strive for greater simplicity

External quality factors: those properties that can be readily
observed
Internal quality factors: those properties that lead to a high-quality
design from a technical perspective
Construction Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking

Modelling
Analysis
Constructio
Design
n
Code
Test Deployment
Delivery
Support
Feedback
Coding Principles

(Preparation before coding)
1)
2)
3)
4)
5)

Understand the problem you are trying to solve
Understand basic design principles and concepts
Pick a programming language that meets the needs of the
software to be built and the environment in which it will operate
Select a programming environment that provides tools that will
make your work easier
Create a set of unit tests that will be applied once the component
you code is completed
Coding Principles
(As you begin coding)

1)
2)
3)
4)
5)
6)
7)
8)

Constrain your algorithms by following structured programming
practices
Select data structures that will meet the needs of the design
Understand the software architecture and create interfaces that are
consistent with it
Keep conditional logic as simple as possible
Create nested loops in a way that makes them easily testable
Select meaningful variable names and follow other local coding
standards
Write code that is self-documenting
Create a visual layout (e.g., indentation and blank lines) that aids
code understanding
Coding Principles

1)
2)
3)

(After completing the first round of
code)
Conduct a code walkthrough
Perform unit tests (black-box and white-box) and correct errors
you have uncovered
Refactor the code
Testing Principles
1)
2)
3)

All tests should be traceable to the software requirements
Tests should be planned long before testing begins
The Pareto principle applies to software testing
•

1)

Testing should begin “in the small” and progress toward testing
“in the large”
•

1)

80% of the uncovered errors are in 20% of the code

Unit testing --> integration testing --> validation testing --> system
testing

Exhaustive testing is not possible .
Test Objectives
1)
2)
3)

Testing is a process of executing a program with the intent of
finding an error
A good test case is one that has a high probability of finding an asyet undiscovered error
A successful test is one that uncovers an as-yet undiscovered error
Deployment Practices
Communication
Project initiation
Requirements
gathering
Planning
Estimating
Scheduling
Tracking Modelling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
Deployment Principles
1)

Customer expectations for the software must be managed
•

1)
2)
3)
4)

Be careful not to promise too much or to mislead the user

A complete delivery package should be assembled and tested
A support regime must be established before the software is
delivered
Appropriate instructional materials must be provided to end
users
Buggy software should be fixed first, delivered later
Software Process
Process Models



Waterfall model
Incremental Process Models





Evolutionary Process Models





Prototyping model
Spiral model

Specialized Process Models





Rapid application development model
Incremental model

Component-Based Development
Formal Method model

Comparison of life-cycle models
Waterfall model




Requirements are reasonably understood.
When work flow is linear in fashion
Systematic sequential approach
r)
r)
(o e (o el
l
de y cl M od
o c
l M ife ti a l
l
rfa a l L ue n
a te sic e q
W as
S
C l ne a r
Li
Software engineering
Incremental model




Evolution of waterfall model
New features added to 1st Increment(core product)
Incremental software development model may be
applicable to projects where:



Software Requirements are well defined, but realization may be
delayed.
The basic software functionality are required early
SW Functionality and features
Time

Inc 1

Inc 2

Inc 3
RAD Model









Rapid Application Development
Short development cycle
Faster development (60-90) days
High quality results
Use of (CASE) Tools
Component based construction
System delivered in short time (2 to 3 months)
Useful where requirements are well understood and
scope is limited
The RAD Model
Team # n
M o d e lin g
bus ines s m odeling
dat a m odeling
proc es s m odeling

C o n s t r u c t io n
c om ponent reus e
aut om at ic c ode
generat ion
t es t ing

Team # 2

Com m unicat ion

Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g

Planning
Co nst r uct io n

Team # 1

co m p o n e n t re u se
a u t o m a t i c co d e
g e n e ra t i o n
t e st i n g

Mode ling

De ploym e nt
int egrat ion
deliv ery
feedback

business modeling
dat a modeling
process modeling

Const r uct ion

component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days

40
Process Models



Waterfall model
Incremental Process Models





Evolutionary Process Models









Prototyping model
Spiral model

Specialized Process Models




Rapid application development model
Incremental model

Component-Based Development
Formal Method model

Unified Process
Comparison of life-cycle models
Prototyping






Early approximation of a final system
Linear and iterative
Customer is unable to define the system
Requirements are not freezed
a prototype is built to understand the requirements
Evolutionary Models: Prototyping
Qu ick p lan
Quick

Com m unicat ion

plan

communication
Mo d e lin g
Modeling
Qu ick d e sig n

Quick design

Deployment
Deployment
De live r y
delivery &
& Fe e dback

feedback

Const r uct ion

Construction
of
of prototype
pr ot ot ype

43
Spiral Model


Simplified form




Precede each phase by





Waterfall model plus risk analysis
Alternatives
Risk analysis

Follow each phase by



Evaluation
Planning of next phase
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication
modeling
analysis
design
start

deployment
delivery
feedback

construction
code
test

45
Specialized Process Models
1)Component Based Development


COTS




Commercial off-the-shelf software components developed by
vendors who offer them as products.

Decomposition of the engineered systems into functional
or logical components with well-defined interfaces used
for communication across the components.
Co
De m
M s ig p on
C o odu n e n
m le a r c t i n
pr I n h te
e h te ite g
e n ge ct u r a t
s i ra r e ion
ve tio
te n.
st
in
g.
2) Formal Methods Model



Mathematically based techniques for representing and
analysis of software.
Formal methods include





Formal specification
Specification analysis and proof
Transformational development
Program verification
Formal Methods Model








Reduces requirements errors as it forces a detailed
analysis of the requirements
Incompleteness and inconsistencies can be
discovered and resolved
Currently very time consuming and expensive
Extensive training required
Difficult to use this model to communicate with the
customer.
Unified Process



Contains features of OOA and OOD.
UML- Unified Modeling Language




It was created to support the OO design and modeling.

iterative and incremental process
Phases of Unified process
All the phases are concurrent in nature
 Inception
 Elaboration
 Construction
 Transition
 Production
The Unified Process (UP)
Elab o r at io n
elaboration
Incep t
inceptionio n

inception

co nst r uct io n
Release
soft ware increment

t r ansit io n

p r o d uct io n
52
UP (contd)


Inception



Customer communication
Planning




Business requirements are identified




Identify resources, assess risks, defines schedule
In the form of use cases.

Rough architecture


A tentative outline of major sub-systems, functions and features
that populate them.
UP (contd)


Elaboration





Customer communication
Modeling activity
Expands the use cases.
Expands the architecture to:




Use case model, analysis model, design model, implementation
model and deployment model.

Review plan and make modifications


Evaluate scope, risks, project delivery dates
UP (contd)


Construction







Develop software components (that make the use cases
operational).
Complete the analysis and design models.
Implement all functions and features for that increment.
Conduct unit testing for the components
Integrate components.
UP (contd)


Transition





Create user manuals, guidelines, installation procedures.
Software is given to users for beta testing.
Get user feedback
The increment is now a useable software release.
Incept ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I nc e pt i o
n

UP Work Products
Elaborat ion phase
Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual

Const ruct ion phase
Design model
Sof t ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment

Transit ion phase
Deliv ered soft ware increment
Bet a t est report s
General user feedback

57
Agile Software Development






Is a group of software development methodologies
based on iterative and incremental development, where
requirements and solutions evolve through
collaboration between self-organizing, cross-functional
teams.
Self Organization: is the process where a structure or
pattern appears in a system without central authority.
Cross-Functional team : is a group of people with
different functional expertise working toward a common
goal.
Extreme Programming









Is a software development methodology which is
intended to improve software quality and
responsiveness to changing customer requirements.
It releases product in short development cycles (time
boxing)
Pair Programming: Driver and Observer
Time Boxing
Code Review
Unit Testing

Contenu connexe

Tendances

Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9koolkampus
 
4 p’s of management spectrum and the w5hh principle
4 p’s of management spectrum and the w5hh principle4 p’s of management spectrum and the w5hh principle
4 p’s of management spectrum and the w5hh principleMohammad Hafiz-Al-Masud
 
Software myths | Software Engineering Notes
Software myths | Software Engineering NotesSoftware myths | Software Engineering Notes
Software myths | Software Engineering NotesNavjyotsinh Jadeja
 
Selection of an appropriate project approach
Selection of an appropriate project approachSelection of an appropriate project approach
Selection of an appropriate project approachtumetr1
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9Ian Sommerville
 
1.1 The nature of software.ppt
1.1 The nature of software.ppt1.1 The nature of software.ppt
1.1 The nature of software.pptJAYAPRIYAR7
 
Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design pptfarazimlak
 
Software Engineering - Ch1
Software Engineering - Ch1Software Engineering - Ch1
Software Engineering - Ch1Siddharth Ayer
 
Software project management- Software Engineering
Software project management- Software EngineeringSoftware project management- Software Engineering
Software project management- Software EngineeringMuhammad Yousuf Abdul Qadir
 
Software Engineering Fundamentals
Software Engineering FundamentalsSoftware Engineering Fundamentals
Software Engineering FundamentalsRahul Sudame
 
Unit 1 - Introduction to Software Engineering.ppt
Unit 1 - Introduction to Software Engineering.pptUnit 1 - Introduction to Software Engineering.ppt
Unit 1 - Introduction to Software Engineering.pptDrTThendralCompSci
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGSaqib Raza
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software EngineeringMajane Padua
 

Tendances (20)

Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9Formal Specification in Software Engineering SE9
Formal Specification in Software Engineering SE9
 
4 p’s of management spectrum and the w5hh principle
4 p’s of management spectrum and the w5hh principle4 p’s of management spectrum and the w5hh principle
4 p’s of management spectrum and the w5hh principle
 
Unit1
Unit1Unit1
Unit1
 
Software myths | Software Engineering Notes
Software myths | Software Engineering NotesSoftware myths | Software Engineering Notes
Software myths | Software Engineering Notes
 
Selection of an appropriate project approach
Selection of an appropriate project approachSelection of an appropriate project approach
Selection of an appropriate project approach
 
Ch2-Software Engineering 9
Ch2-Software Engineering 9Ch2-Software Engineering 9
Ch2-Software Engineering 9
 
Software design
Software designSoftware design
Software design
 
Software Metrics
Software MetricsSoftware Metrics
Software Metrics
 
1.1 The nature of software.ppt
1.1 The nature of software.ppt1.1 The nature of software.ppt
1.1 The nature of software.ppt
 
Software architecture design ppt
Software architecture design pptSoftware architecture design ppt
Software architecture design ppt
 
Software quality
Software qualitySoftware quality
Software quality
 
Software Engineering - Ch1
Software Engineering - Ch1Software Engineering - Ch1
Software Engineering - Ch1
 
Software project management- Software Engineering
Software project management- Software EngineeringSoftware project management- Software Engineering
Software project management- Software Engineering
 
Software Engineering Fundamentals
Software Engineering FundamentalsSoftware Engineering Fundamentals
Software Engineering Fundamentals
 
Software Engineering
Software EngineeringSoftware Engineering
Software Engineering
 
Unit 1 - Introduction to Software Engineering.ppt
Unit 1 - Introduction to Software Engineering.pptUnit 1 - Introduction to Software Engineering.ppt
Unit 1 - Introduction to Software Engineering.ppt
 
REQUIREMENT ENGINEERING
REQUIREMENT ENGINEERINGREQUIREMENT ENGINEERING
REQUIREMENT ENGINEERING
 
Ch1 introduction
Ch1 introductionCh1 introduction
Ch1 introduction
 
Introduction to Software Engineering
Introduction to Software EngineeringIntroduction to Software Engineering
Introduction to Software Engineering
 
System engineering
System engineeringSystem engineering
System engineering
 

En vedette

Sequence Diagram of Hotel Management System
Sequence Diagram of Hotel Management SystemSequence Diagram of Hotel Management System
Sequence Diagram of Hotel Management SystemSushil Mishra
 
Hotel management or reservation system document
Hotel management or reservation system document Hotel management or reservation system document
Hotel management or reservation system document prabhat kumar
 
Hotel Management System SRS
Hotel Management System SRS Hotel Management System SRS
Hotel Management System SRS Paras
 
SRS document for Hotel Management System
SRS document for Hotel Management SystemSRS document for Hotel Management System
SRS document for Hotel Management SystemCharitha Gamage
 
Documentation Hotel Management System
Documentation Hotel Management SystemDocumentation Hotel Management System
Documentation Hotel Management SystemSalman Dayal
 
Software project management
Software project managementSoftware project management
Software project managementR A Akerkar
 
Software Engineering ppt
Software Engineering pptSoftware Engineering ppt
Software Engineering pptshruths2890
 
Software engineering presentation
Software engineering presentationSoftware engineering presentation
Software engineering presentationMJ Ferdous
 

En vedette (10)

Domain Modeling
Domain ModelingDomain Modeling
Domain Modeling
 
Sequence Diagram of Hotel Management System
Sequence Diagram of Hotel Management SystemSequence Diagram of Hotel Management System
Sequence Diagram of Hotel Management System
 
Hotel management or reservation system document
Hotel management or reservation system document Hotel management or reservation system document
Hotel management or reservation system document
 
Domain model
Domain modelDomain model
Domain model
 
Hotel Management System SRS
Hotel Management System SRS Hotel Management System SRS
Hotel Management System SRS
 
SRS document for Hotel Management System
SRS document for Hotel Management SystemSRS document for Hotel Management System
SRS document for Hotel Management System
 
Documentation Hotel Management System
Documentation Hotel Management SystemDocumentation Hotel Management System
Documentation Hotel Management System
 
Software project management
Software project managementSoftware project management
Software project management
 
Software Engineering ppt
Software Engineering pptSoftware Engineering ppt
Software Engineering ppt
 
Software engineering presentation
Software engineering presentationSoftware engineering presentation
Software engineering presentation
 

Similaire à Software engineering

Introduction to software engineering
Introduction to software engineeringIntroduction to software engineering
Introduction to software engineeringHitesh Mohapatra
 
Software engineering -core topics
Software engineering -core topicsSoftware engineering -core topics
Software engineering -core topicsAmnah_Ch
 
Introduction of Software Engineering
Introduction of Software EngineeringIntroduction of Software Engineering
Introduction of Software EngineeringMuhammadTalha436
 
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
softwareengineeringpractice-141002214920-phpapp02 (1).pdfsoftwareengineeringpractice-141002214920-phpapp02 (1).pdf
softwareengineeringpractice-141002214920-phpapp02 (1).pdfSanRock2
 
Week_01-Intro to Software Engineering-1.ppt
Week_01-Intro to Software Engineering-1.pptWeek_01-Intro to Software Engineering-1.ppt
Week_01-Intro to Software Engineering-1.ppt23017156038
 
01 fse software&sw-engineering
01 fse software&sw-engineering01 fse software&sw-engineering
01 fse software&sw-engineeringMohesh Chandran
 
ccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdfccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdfVijayakumarKadumbadi
 
Introduction of software engineering
Introduction of software engineeringIntroduction of software engineering
Introduction of software engineeringBhagyashriMore10
 
Software design.edited (1)
Software design.edited (1)Software design.edited (1)
Software design.edited (1)FarjanaAhmed3
 
Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2Raj vardhan
 
Chapter_01.ppt
Chapter_01.pptChapter_01.ppt
Chapter_01.pptMSahibKhan
 
Chapter 01
Chapter 01Chapter 01
Chapter 01ryan aja
 

Similaire à Software engineering (20)

Introduction to software engineering
Introduction to software engineeringIntroduction to software engineering
Introduction to software engineering
 
Chapter1
Chapter1Chapter1
Chapter1
 
Software engineering -core topics
Software engineering -core topicsSoftware engineering -core topics
Software engineering -core topics
 
Introduction of Software Engineering
Introduction of Software EngineeringIntroduction of Software Engineering
Introduction of Software Engineering
 
Software Engineering Practice
Software Engineering PracticeSoftware Engineering Practice
Software Engineering Practice
 
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
softwareengineeringpractice-141002214920-phpapp02 (1).pdfsoftwareengineeringpractice-141002214920-phpapp02 (1).pdf
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
 
Lecture 1 SE.pptx
Lecture 1 SE.pptxLecture 1 SE.pptx
Lecture 1 SE.pptx
 
SE
SESE
SE
 
Week_01-Intro to Software Engineering-1.ppt
Week_01-Intro to Software Engineering-1.pptWeek_01-Intro to Software Engineering-1.ppt
Week_01-Intro to Software Engineering-1.ppt
 
01 fse software&sw-engineering
01 fse software&sw-engineering01 fse software&sw-engineering
01 fse software&sw-engineering
 
Unit i software design principles 9
Unit i software design principles 9Unit i software design principles 9
Unit i software design principles 9
 
3.pptx
3.pptx3.pptx
3.pptx
 
ccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdfccs356-software-engineering-notes.pdf
ccs356-software-engineering-notes.pdf
 
Chapter 01
Chapter 01Chapter 01
Chapter 01
 
Introduction of software engineering
Introduction of software engineeringIntroduction of software engineering
Introduction of software engineering
 
Software design.edited (1)
Software design.edited (1)Software design.edited (1)
Software design.edited (1)
 
Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2Introduction To Software Concepts Unit 1 & 2
Introduction To Software Concepts Unit 1 & 2
 
Chapter_01.ppt
Chapter_01.pptChapter_01.ppt
Chapter_01.ppt
 
Chapter 01
Chapter 01Chapter 01
Chapter 01
 
Unit 1.pdf
Unit 1.pdfUnit 1.pdf
Unit 1.pdf
 

Dernier

Ultra structure and life cycle of Plasmodium.pptx
Ultra structure and life cycle of Plasmodium.pptxUltra structure and life cycle of Plasmodium.pptx
Ultra structure and life cycle of Plasmodium.pptxDr. Asif Anas
 
What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?TechSoup
 
The Stolen Bacillus by Herbert George Wells
The Stolen Bacillus by Herbert George WellsThe Stolen Bacillus by Herbert George Wells
The Stolen Bacillus by Herbert George WellsEugene Lysak
 
Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...raviapr7
 
Over the counter (OTC)- Sale, rational use.pptx
Over the counter (OTC)- Sale, rational use.pptxOver the counter (OTC)- Sale, rational use.pptx
Over the counter (OTC)- Sale, rational use.pptxraviapr7
 
5 charts on South Africa as a source country for international student recrui...
5 charts on South Africa as a source country for international student recrui...5 charts on South Africa as a source country for international student recrui...
5 charts on South Africa as a source country for international student recrui...CaraSkikne1
 
Prescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptxPrescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptxraviapr7
 
ARTICULAR DISC OF TEMPOROMANDIBULAR JOINT
ARTICULAR DISC OF TEMPOROMANDIBULAR JOINTARTICULAR DISC OF TEMPOROMANDIBULAR JOINT
ARTICULAR DISC OF TEMPOROMANDIBULAR JOINTDR. SNEHA NAIR
 
How to Make a Field read-only in Odoo 17
How to Make a Field read-only in Odoo 17How to Make a Field read-only in Odoo 17
How to Make a Field read-only in Odoo 17Celine George
 
How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17Celine George
 
Education and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptxEducation and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptxraviapr7
 
Department of Health Compounder Question ‍Solution 2022.pdf
Department of Health Compounder Question ‍Solution 2022.pdfDepartment of Health Compounder Question ‍Solution 2022.pdf
Department of Health Compounder Question ‍Solution 2022.pdfMohonDas
 
How to Manage Cross-Selling in Odoo 17 Sales
How to Manage Cross-Selling in Odoo 17 SalesHow to Manage Cross-Selling in Odoo 17 Sales
How to Manage Cross-Selling in Odoo 17 SalesCeline George
 
SOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptx
SOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptxSOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptx
SOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptxSyedNadeemGillANi
 
EBUS5423 Data Analytics and Reporting Bl
EBUS5423 Data Analytics and Reporting BlEBUS5423 Data Analytics and Reporting Bl
EBUS5423 Data Analytics and Reporting BlDr. Bruce A. Johnson
 
How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17Celine George
 
Slides CapTechTalks Webinar March 2024 Joshua Sinai.pptx
Slides CapTechTalks Webinar March 2024 Joshua Sinai.pptxSlides CapTechTalks Webinar March 2024 Joshua Sinai.pptx
Slides CapTechTalks Webinar March 2024 Joshua Sinai.pptxCapitolTechU
 
3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptx3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptxmary850239
 

Dernier (20)

Ultra structure and life cycle of Plasmodium.pptx
Ultra structure and life cycle of Plasmodium.pptxUltra structure and life cycle of Plasmodium.pptx
Ultra structure and life cycle of Plasmodium.pptx
 
What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?What is the Future of QuickBooks DeskTop?
What is the Future of QuickBooks DeskTop?
 
Finals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quizFinals of Kant get Marx 2.0 : a general politics quiz
Finals of Kant get Marx 2.0 : a general politics quiz
 
The Stolen Bacillus by Herbert George Wells
The Stolen Bacillus by Herbert George WellsThe Stolen Bacillus by Herbert George Wells
The Stolen Bacillus by Herbert George Wells
 
Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...Patient Counselling. Definition of patient counseling; steps involved in pati...
Patient Counselling. Definition of patient counseling; steps involved in pati...
 
Over the counter (OTC)- Sale, rational use.pptx
Over the counter (OTC)- Sale, rational use.pptxOver the counter (OTC)- Sale, rational use.pptx
Over the counter (OTC)- Sale, rational use.pptx
 
5 charts on South Africa as a source country for international student recrui...
5 charts on South Africa as a source country for international student recrui...5 charts on South Africa as a source country for international student recrui...
5 charts on South Africa as a source country for international student recrui...
 
Prescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptxPrescribed medication order and communication skills.pptx
Prescribed medication order and communication skills.pptx
 
ARTICULAR DISC OF TEMPOROMANDIBULAR JOINT
ARTICULAR DISC OF TEMPOROMANDIBULAR JOINTARTICULAR DISC OF TEMPOROMANDIBULAR JOINT
ARTICULAR DISC OF TEMPOROMANDIBULAR JOINT
 
How to Make a Field read-only in Odoo 17
How to Make a Field read-only in Odoo 17How to Make a Field read-only in Odoo 17
How to Make a Field read-only in Odoo 17
 
How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17How to Add Existing Field in One2Many Tree View in Odoo 17
How to Add Existing Field in One2Many Tree View in Odoo 17
 
Education and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptxEducation and training program in the hospital APR.pptx
Education and training program in the hospital APR.pptx
 
Department of Health Compounder Question ‍Solution 2022.pdf
Department of Health Compounder Question ‍Solution 2022.pdfDepartment of Health Compounder Question ‍Solution 2022.pdf
Department of Health Compounder Question ‍Solution 2022.pdf
 
How to Manage Cross-Selling in Odoo 17 Sales
How to Manage Cross-Selling in Odoo 17 SalesHow to Manage Cross-Selling in Odoo 17 Sales
How to Manage Cross-Selling in Odoo 17 Sales
 
SOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptx
SOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptxSOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptx
SOLIDE WASTE in Cameroon,,,,,,,,,,,,,,,,,,,,,,,,,,,.pptx
 
EBUS5423 Data Analytics and Reporting Bl
EBUS5423 Data Analytics and Reporting BlEBUS5423 Data Analytics and Reporting Bl
EBUS5423 Data Analytics and Reporting Bl
 
How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17How to Create a Toggle Button in Odoo 17
How to Create a Toggle Button in Odoo 17
 
Slides CapTechTalks Webinar March 2024 Joshua Sinai.pptx
Slides CapTechTalks Webinar March 2024 Joshua Sinai.pptxSlides CapTechTalks Webinar March 2024 Joshua Sinai.pptx
Slides CapTechTalks Webinar March 2024 Joshua Sinai.pptx
 
Prelims of Kant get Marx 2.0: a general politics quiz
Prelims of Kant get Marx 2.0: a general politics quizPrelims of Kant get Marx 2.0: a general politics quiz
Prelims of Kant get Marx 2.0: a general politics quiz
 
3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptx3.26.24 Race, the Draft, and the Vietnam War.pptx
3.26.24 Race, the Draft, and the Vietnam War.pptx
 

Software engineering

  • 1. UNIT I Introduction to Software Engineering Presented By Prof.Hitesh Mohapatra Dept. of Computer Engg.
  • 2. Software’s Dual Role  Software is a product    Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits information Software is a vehicle for delivering a product     Supports or directly provides system functionality Controls other programs (e.g., an operating system) Effects communications (e.g., networking software) Helps build other software (e.g., software tools)
  • 3. What is Software? Software is a set of items or objects that form a “configuration” that includes • programs • documents • data ...
  • 4. What is Software?    software is engineered software doesn’t wear out software is complex
  • 5. Wear vs. Deterioration in re s d fa re c ae ilu ra d e to s e e c te u id ffe ts F ilue a r rt ae cag hne a t ac r e cu l uv id a e c r e e liz d uv T e im
  • 6. Software Applications        system software application software engineering/scientific software embedded software product-line software Web Apps (Web applications) AI software
  • 7. Software—New Categories     Ubiquitous computing—wireless networks Net sourcing—the Web as a computing engine Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) Also … (see Chapter 32)     Data mining Grid computing Cognitive machines Software for nanotechnologies
  • 8. Legacy Software Why must it change?     software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases. software must be re-architected to make it viable within a network environment.
  • 9. Software Myths  Management Myths      Customer myths    We have books of standards, my staff will have sufficient info. I work very hard to put the latest, greatest, fastest, state-of-the-art hardware in front of all my programmers. We have the greatest CASE tools around. If we get behind, we can just add more programmers. A general statement of objectives is sufficient to start coding, fill in the details later. Project requirements change constantly, but change is easy because software is flexible. Programmer myths    Once the program is written and working, our job is done. Until the program is running, there is no way to assess quality. The only deliverable for a successful project is the working program.
  • 10. Software Engineering Practice Software engineering practice - Communication practices - Planning practices - Analysis modeling practices - Design modeling practices - Construction practices - Deployment practices -
  • 11. Software Engineering Practice     Consists of a collection of concepts, principles, methods, and tools that a software engineer calls upon on a daily basis Equips managers to manage software projects and software engineers to build computer programs Provides necessary technical and management how to’s in getting the job done Transforms a haphazard unfocused approach into something that is more organized, more effective, and more likely to achieve success
  • 12. The Essence of Problem Solving Understand the problem (communication and analysis) 1) • • • • Who has a stake in the solution to the problem? What are the unknowns (data, function, behavior)? Can the problem be compartmentalized? Can the problem be represented graphically? Plan a solution (planning, modeling and software design) 1) • • • Have you seen similar problems like this before? Has a similar problem been solved and is the solution reusable? Can sub problems be defined and are solutions available for the sub problems?
  • 13. The Essence of Problem Solving (continued) Carry out the plan (construction; code generation) 3) • • Does the solution conform to the plan? Is the source code traceable back to the design? Is each component of the solution correct? Has the design and code been reviewed? Examine the results for accuracy (testing and quality assurance) 3) • • Is it possible to test each component of the solution? Does the solution produce results that conform to the data, function, and behavior that are required?
  • 14. Seven Core Principles for Software Engineering 1) Remember the reason that the software exists • 1) Keep it simple, stupid (KISS) • 1) Never design yourself into a corner; build software that can be easily changed and adapted Plan ahead for software reuse • 1) Always specify, design, and implement knowing that someone else will later have to understand and modify what you did Be open to the future • 1) A clear vision is essential to the project’s success Others will consume what you produce • 1) All design and implementation should be as simple as possible Maintain the vision of the project • 1) The software should provide value to its users and satisfy the requirements Reuse of software reduces the long-term cost and increases the value of the program and the reusable components Think, then act • Placing clear, complete thought before action will almost always produce better results
  • 15. Communication Practices (Requirements Elicitation) Communication Project initiation Requirements gathering Planning Estimating Scheduling Modelling Analysis Tracking Design Construction Code Test Deployment Delivery Support Feedback 15
  • 16. Communication Principles 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) Listen to the speaker and concentrate on what is being said Prepare before you meet by researching and understanding the problem Someone should facility the meeting and have an agenda Face-to-face communication is best, but also have a document or presentation to focus the discussion Take notes and document decisions Strive for collaboration and consensus Stay focused on a topic; modularize your discussion If something is unclear, draw a picture Move on to the next topic a) after you agree to something, b) if you cannot agree to something, or c) if a feature or function is unclear and cannot be clarified at the moment Negotiation is not a contest or a game; it works best when both parties win
  • 17. Planning Practices (Defining a Road Map) Communication Project initiation Requirements gathering Planning Estimating Scheduling Modelling Tracking Analysis Design Construction Code Test Deployment Delivery Support Feedback 17
  • 18. Planning Principles 1) 2) 3) 4) 5) 6) 7) 8) 9) 10) Understand the scope of the project Involve the customer in the planning activity Recognize that planning is iterative; things will change Estimate based only on what you know Consider risk as you define the plan Be realistic on how much can be done each day by each person and how well Adjust granularity as you define the plan Define how you intend to ensure quality Describe how you intend to accommodate change Track the plan frequently and make adjustments as required
  • 19. Barry Boehm’s W5HH Principle        Why is the system being developed? What will be done? When will it be accomplished? Who is responsible for each function? Where are they organizationally located? How will the job be done technically and managerially? How much of each resource is needed? The answers to these questions lead to a definition of key project characteristics and the resultant project plan.
  • 20. Modeling Practices (Analysis and Design) Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Modelling Analysis Design Construction Code Test Deployment Delivery Support Feedback
  • 21. Analysis Modeling Principles 1) 2) 3) 4) 5) The information domain of a problem (the data that flows in and out of a system) must be represented and understood The functions that the software performs must be defined The behavior of the software (as a consequence of external events) must be represented The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion The analysis task should move from essential information toward implementation detail
  • 22. Design Modeling Principles 1) 2) 3) 4) 5) 6) 7) 8) 9) The design should be traceable to the analysis model Always consider the software architecture of the system to be built Design of data is as important as design of processing functions Interfaces (both internal and external) must be designed with care User interface design should be tuned to the needs of the end-user and should stress ease of use Component-level design should be functionally independent (high cohesion) Components should be loosely coupled to one another and to the external environment Design representations (models) should be easily understandable The design should be developed iteratively; with each iteration, the designer should strive for greater simplicity External quality factors: those properties that can be readily observed Internal quality factors: those properties that lead to a high-quality design from a technical perspective
  • 24. Coding Principles (Preparation before coding) 1) 2) 3) 4) 5) Understand the problem you are trying to solve Understand basic design principles and concepts Pick a programming language that meets the needs of the software to be built and the environment in which it will operate Select a programming environment that provides tools that will make your work easier Create a set of unit tests that will be applied once the component you code is completed
  • 25. Coding Principles (As you begin coding) 1) 2) 3) 4) 5) 6) 7) 8) Constrain your algorithms by following structured programming practices Select data structures that will meet the needs of the design Understand the software architecture and create interfaces that are consistent with it Keep conditional logic as simple as possible Create nested loops in a way that makes them easily testable Select meaningful variable names and follow other local coding standards Write code that is self-documenting Create a visual layout (e.g., indentation and blank lines) that aids code understanding
  • 26. Coding Principles 1) 2) 3) (After completing the first round of code) Conduct a code walkthrough Perform unit tests (black-box and white-box) and correct errors you have uncovered Refactor the code
  • 27. Testing Principles 1) 2) 3) All tests should be traceable to the software requirements Tests should be planned long before testing begins The Pareto principle applies to software testing • 1) Testing should begin “in the small” and progress toward testing “in the large” • 1) 80% of the uncovered errors are in 20% of the code Unit testing --> integration testing --> validation testing --> system testing Exhaustive testing is not possible .
  • 28. Test Objectives 1) 2) 3) Testing is a process of executing a program with the intent of finding an error A good test case is one that has a high probability of finding an asyet undiscovered error A successful test is one that uncovers an as-yet undiscovered error
  • 29. Deployment Practices Communication Project initiation Requirements gathering Planning Estimating Scheduling Tracking Modelling Analysis Design Construction Code Test Deployment Delivery Support Feedback
  • 30. Deployment Principles 1) Customer expectations for the software must be managed • 1) 2) 3) 4) Be careful not to promise too much or to mislead the user A complete delivery package should be assembled and tested A support regime must be established before the software is delivered Appropriate instructional materials must be provided to end users Buggy software should be fixed first, delivered later
  • 32. Process Models   Waterfall model Incremental Process Models    Evolutionary Process Models    Prototyping model Spiral model Specialized Process Models    Rapid application development model Incremental model Component-Based Development Formal Method model Comparison of life-cycle models
  • 33. Waterfall model    Requirements are reasonably understood. When work flow is linear in fashion Systematic sequential approach
  • 34. r) r) (o e (o el l de y cl M od o c l M ife ti a l l rfa a l L ue n a te sic e q W as S C l ne a r Li
  • 36. Incremental model    Evolution of waterfall model New features added to 1st Increment(core product) Incremental software development model may be applicable to projects where:   Software Requirements are well defined, but realization may be delayed. The basic software functionality are required early
  • 37. SW Functionality and features Time Inc 1 Inc 2 Inc 3
  • 38. RAD Model         Rapid Application Development Short development cycle Faster development (60-90) days High quality results Use of (CASE) Tools Component based construction System delivered in short time (2 to 3 months) Useful where requirements are well understood and scope is limited
  • 39. The RAD Model Team # n M o d e lin g bus ines s m odeling dat a m odeling proc es s m odeling C o n s t r u c t io n c om ponent reus e aut om at ic c ode generat ion t es t ing Team # 2 Com m unicat ion Mo d eling b u si n e ss m o d e l i n g dat a m odeling p ro ce ss m o d e l i n g Planning Co nst r uct io n Team # 1 co m p o n e n t re u se a u t o m a t i c co d e g e n e ra t i o n t e st i n g Mode ling De ploym e nt int egrat ion deliv ery feedback business modeling dat a modeling process modeling Const r uct ion component reuse aut omat ic code generat ion t est ing 6 0 - 9 0 days 40
  • 40. Process Models   Waterfall model Incremental Process Models    Evolutionary Process Models      Prototyping model Spiral model Specialized Process Models   Rapid application development model Incremental model Component-Based Development Formal Method model Unified Process Comparison of life-cycle models
  • 41. Prototyping      Early approximation of a final system Linear and iterative Customer is unable to define the system Requirements are not freezed a prototype is built to understand the requirements
  • 42. Evolutionary Models: Prototyping Qu ick p lan Quick Com m unicat ion plan communication Mo d e lin g Modeling Qu ick d e sig n Quick design Deployment Deployment De live r y delivery & & Fe e dback feedback Const r uct ion Construction of of prototype pr ot ot ype 43
  • 43. Spiral Model  Simplified form   Precede each phase by    Waterfall model plus risk analysis Alternatives Risk analysis Follow each phase by   Evaluation Planning of next phase
  • 44. Evolutionary Models: The Spiral planning estimation scheduling risk analysis communication modeling analysis design start deployment delivery feedback construction code test 45
  • 45. Specialized Process Models 1)Component Based Development  COTS   Commercial off-the-shelf software components developed by vendors who offer them as products. Decomposition of the engineered systems into functional or logical components with well-defined interfaces used for communication across the components.
  • 46. Co De m M s ig p on C o odu n e n m le a r c t i n pr I n h te e h te ite g e n ge ct u r a t s i ra r e ion ve tio te n. st in g.
  • 47. 2) Formal Methods Model   Mathematically based techniques for representing and analysis of software. Formal methods include     Formal specification Specification analysis and proof Transformational development Program verification
  • 48. Formal Methods Model      Reduces requirements errors as it forces a detailed analysis of the requirements Incompleteness and inconsistencies can be discovered and resolved Currently very time consuming and expensive Extensive training required Difficult to use this model to communicate with the customer.
  • 49. Unified Process   Contains features of OOA and OOD. UML- Unified Modeling Language   It was created to support the OO design and modeling. iterative and incremental process
  • 50. Phases of Unified process All the phases are concurrent in nature  Inception  Elaboration  Construction  Transition  Production
  • 51. The Unified Process (UP) Elab o r at io n elaboration Incep t inceptionio n inception co nst r uct io n Release soft ware increment t r ansit io n p r o d uct io n 52
  • 52. UP (contd)  Inception   Customer communication Planning   Business requirements are identified   Identify resources, assess risks, defines schedule In the form of use cases. Rough architecture  A tentative outline of major sub-systems, functions and features that populate them.
  • 53. UP (contd)  Elaboration     Customer communication Modeling activity Expands the use cases. Expands the architecture to:   Use case model, analysis model, design model, implementation model and deployment model. Review plan and make modifications  Evaluate scope, risks, project delivery dates
  • 54. UP (contd)  Construction      Develop software components (that make the use cases operational). Complete the analysis and design models. Implement all functions and features for that increment. Conduct unit testing for the components Integrate components.
  • 55. UP (contd)  Transition     Create user manuals, guidelines, installation procedures. Software is given to users for beta testing. Get user feedback The increment is now a useable software release.
  • 56. Incept ion phase Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary . One or more prot ot y pes I nc e pt i o n UP Work Products Elaborat ion phase Use-case model Supplement ary requirement s including non-funct ional Analy sis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot y pe. Preliminary design model Rev ised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual Const ruct ion phase Design model Sof t ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment Transit ion phase Deliv ered soft ware increment Bet a t est report s General user feedback 57
  • 57. Agile Software Development    Is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Self Organization: is the process where a structure or pattern appears in a system without central authority. Cross-Functional team : is a group of people with different functional expertise working toward a common goal.
  • 58. Extreme Programming       Is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. It releases product in short development cycles (time boxing) Pair Programming: Driver and Observer Time Boxing Code Review Unit Testing

Notes de l'éditeur

  1. Requirement Engineering Identify real needs of the client Requirements are set in stone. “What system will do” Contract between client and the developer SRS is the product Design Specification SRS is the input “How system will do” High level design (Specifying common needs) Low level design (Crucial details) Implementation Design Specification Input Modules (to decrease complexity) Verification Testing is crucial to integration Unite modules Acceptance testing (to chk whether requirements are met or not) Product ready to be used.