SlideShare a Scribd company logo
Unit 2
Software engineering
practices
 Software engineering practice is a collection of
concepts, principals, methods and tools that
a software engineer calls upon on daily basis.
 Practice allows managers to manage software
projects and software engineers to build
computer programs.
Essence of practice
1.Understand the problem.(communication and
analysis)
2.Plan a solution.(modeling and software design)
3.Carry out the plan.( code generation)
4.Examine the result for accuracy(testing and quality
assurance)
Understand the problem
 Who are the stakeholder?
 What data, functions, features and behavior are
required to properly solve the problem?
 Is it possible to represent smaller problems that may
be easier to understand?
 Can the problem be represented graphically?
Plan a solution
 Have you seen similar problems before?
 Has a similar problem been solved?
 Can you represent a solution in a manner that leads to
effective implementation?
 Can a design model be created?
Carry out the plan.
 Does the solution conform to the plan?
 Each component part of the solution is correct?
 Has the design reviewed?
Examine the result
 Is it possible to test each component part of the
solution?
 Has a reasonable testing strategy been
implemented?
 Has the software been validated against all
stakeholder requirements?
Core principles of Software
Engineering
1. The Reason It All Exists.
2.Keep It Simple, Stupid!
3.Maintain The Vision.
4.What you produce ,Others will Consume.
5.Be Open To The Future.
6.Plan Ahead For Reuse
7.Think!
1st Principle: The Reason It All Exists
 The software exists for one reason: to provide value to
its users.
 Before specifying system requirement, functionality,
hardware platform, development process ask question
such as:
“Dose this add real value to the system?”
 If answer is no, don't do it.
2nd Principle: Keep It Simple, Stupid!
 All design should be as simple as possible, but no
simpler.
 This facilitates having a more easily understood and
easily maintained system.
 Simple does not mean that features should be
discarded in the name of simplicity.
3rd Principle: Maintain The Vision
 A Clear vision is essential to the success of a software project.
 Compromising the architectural vision of a software system
weakens and will eventually break even a well designed
system.
 Having an empowered architect who can hold the vision and
enforce compliance helps ensure a very successful software
project.
4th Principle: What you produce
,Others will Consume
 Always specify design and implement knowing someone
else will have to understand what you are doing.
 Someone may have to debug the code you write, and
that makes them a user of your code.
 Making their job easier adds value to the System.
5th Principle: Be open to the Future
 A system with a long lifetime has more value.
 Software lifetimes are typically measured in months
instead of years.
 System should be ready to adapt changes.
 System that adapt changes have been designed this way
from start.
 Always keep asking “what if?” and prepare for all
possible answers.
6th Principle: Plan ahead for Reuse
 Reuse saves time and effort.
 Achieving a high level of reuse is arguably the hardest
goal to accomplish in developing a software system.
 The reuse of code and designs has been proclaimed as
a major benefit of using object oriented technologies.
7th Principle: Think!
 Placing clear, complete thought before action almost
always produces better results.
 When you think about something, you are more likely to
do it right.
 You also gain knowledge about how to do it right again.
 When clear thoughts has gone into system, value comes
out.
Communication Practices
 Before customer requirements can be analyzed,
modeled, or specified they must be gathered through
a communication activity.
 Effective communication is among the most challenging
activities that confront a software engineer.
Principles
1st : Listen. Try to focus on speakers words. If something is
unclear, ask for clarification.
2nd :Prepare before you communicate.
Spend some time to understand the problem before you
meet with others. If you have responsibilities for conducting
a meeting, prepare an agenda in advance of the meeting.
3rd :Someone should facilitate the activity.
Every communication meeting should have a leader to keep
conversation moving in a productive direction
4th : Face to face communication is best.
Works better when some other representation of the relevant
information is present.
For example, a participant may create a drawing
5th : Take notes and document decisions.
Someone participating in the communication should
serve as a “recorder”
6th : Strive for collaboration. trust among team members and
creates a common goal for the team.
7th : Stay focused, modularize your discussion. discussion
will bounce from one topic to the next
Principles
8th :Draw a picture to clear your idea: A sketch or
drawing can often provide clarity when
words fail to do the job.
9th : Keep the discussion to “ move on ”
1. once there is an agreement to do something .
2. If you cannot agree to something.
3. If a feature of function is not clear.
Planning practices
 Good planning leads to successful result.
 The planning activity encompasses a set of
management and technical practices that enable the
software team to define a road map as it travels
towards its strategic goal and tactical objectives.
 Planning includes complete cost estimation,
resources, scheduling and also risk analysis.
Principle 1: Understand the scope of
the project.
Its impossible to use a road map if you don't know
where you are going. Scope provides the
software team with destination.
Principle 2: Involve the customer in
the planning activity.
The customer defines priorities and establishes
project constraints.
To accommodate these realities software
engineers must often negotiate order of
delivery,time lines and other project related
issues.
Principle 3: Recognize that planning is iterative.
Principle 4:Estimate based on what you know
Principle 5:Consider risk as you define the plan
Principle 6: Be realistic.
Principle 7: Adjust granularity as you define the
plan.
Principle 8: Define how you intend to ensure
Quality.
Principle 9: Describe how you intend to
accommodate change.
Principle 10: Track the plan frequently and make
adjustment as required.
Modeling Practice
 Models are created for better understanding of
the actual entity to be built or design.
 When the entity is a physical thing, we can build
model that is identical in form and shape but
smaller in scale.
 When entity is software our model must take
different form. It must be capable of representing
information, Architecture, functions ,features
and behavior of the system.
In SE work, Two classes of model is created.
1. Analysis Model.
2. Design Model.
Principle 1: The information domain of problem
must be clearly represented.
Information domain encompasses the data that flow
into the system(from end user, external
devices),data that flow out of the system(via user
interface, n/w interface, graphics), data stores
collection of objects(data i.e. maintained
permanently).
Principle 2: The function of the software must
be defined clearly.
 Functions are the processes those transform the
I/p flow to the o/p flow.
 The process specification for example
algorithms provides function details. The
specification must be clearly defined.
Principle 3: The Behavior of the software
must be defined clearly.
 Analysis model uses state transition
diagrams to represent the behavior of the
system clearly.
 It shows how the system makes transition
from one state to another on occurrence of
some external event.
Principle 4: The clear hierarchy among
information, functions and behavior must
be shown.
 The proper hierarchy of analysis model leads
to easy design. Hence information, functions
and behavior of the system must be
represented using proper hierarchy i.e. levels
or layers.
Principle 5: analysis should be clear
enough to convert it into design model.
 If analysis of requirements is clear and
simple then it will be easy for design and
implementation in construction step. Hence
requirement analysis should be clear
enough.
Design modeling
Principle 1: Design should be traceable from
analysis model.
Principle 2: Consider the architecture of the system
to be built.
Principle 3: Design of data is as important as
design of function.
Principle 4: Internal as well as external interfaces
must be designed.
Principle 5: user interface design must satisfy
all need of end user.
Principle 6: Component level design should be
functionally independent.
Principle 7: Components should be loosely
coupled to one another and to the external
environment.
Principle 8: designed modules should be easy
to understand.
Principle 9: Accept that design behavior is
Iterative.
Construction Practices
 The construction activity encompasses a set of
coding and testing tasks that lead to
operational software that is ready for delivery
to the customer or end user.
 The initial focus of testing is at the component
level, often called unit testing. Other levels of
testing include integration testing, validation
testing and acceptance testing.
Coding Principles & Concepts
Preparation Principles: Before you write one line of
code, be sure you,
1.Understand the problem you're trying to solve.
2.Understand basic design principles & concepts.
3.Pick a programming language that meets the needs
of the software to be built & the environment in
which it will operate.
4.Select a programming environment that provides
tools that will make you work easier.
5.Create a set of unit tests that will be applied once
the component you code is completed.
Coding Principles: As you begin writing code, be sure you:
1.Constrain your algorithms by following structured
programming practice.
2.Select data structures that will meet the needs of the
design.
3.Understand the software architecture and create
interfaces that are consistent with it.
4.Keep conditional logic as simple as possible.
5.Create nested loops in a way that makes them easily
testable.
6.Select meaningful variable names and follow other
local coding standards.
7.Write code that is self documenting.
8.Create a visual layout that aids understanding.
Testing principles
Testing rules or objectives:
• Testing is a process of executing a program with
the intent of finding an error.
• A good test is one that has a high probability
of finding an as yet undiscovered error.
• A successful test is one that uncovers an as
yet undiscovered error.
Principle 1: All tests should be traceable to
customer requirements.
Principle 2: Tests should be planned before
testing begins.
Principle 3: The Basic principle applies to
software testing.
Principle 4: Testing should begin “in the
small” and progress toward testing “in the
large”.
Principle 5: Exhaustive testing is not possible.
Deployment
 The deployment activity encompasses 3 actions:
delivery, support and feedback.
 Deployment happens not once, but a number of
times as software moves towards completion.
 Each delivery cycle provides the customer and end
users with an operational software increment that
provides usable functions and features.
Principles
1st : Customer expectations for the software must be
managed.
2nd : A complete delivery package should be assembled
and tested.
3rd: A support system must be established before the
software is delivered.
4th : Appropriate instructional materials must be
provided to end users.
5th : Buggy software should be fixed first, delivered
later.
Requirement Engineering
 The first two activities in the generic process framework is
that of communication and modelling.
 These activities are concerned with discovering the
requirements of the software which the customer is asking
to have developed.
 Requirements engineering is concerned with
understanding the software system that the customer has
requested. It provides the base on which software design
and programming can proceed.
Requirement Engineering
• Importantly, if the developers do not
understand the requirements, it is very likely
that the software will not meet the customer's
needs.
• This makes understanding the customer's
requirements important to the success of the
development project.
TYPES OF REQUIREMENTS
1.Functional requirements
– Statements of services the system should provide,
how the system should react to particular inputs and
how the system should behave in particular situations.
FUNCTIONAL REQUIREMENTS
• Descriptions of data to be entered into the system
• Descriptions of operations performed by each screen
• Descriptions of work-flows performed by the system
• Descriptions of system reports or other outputs
• Who can enter the data into the system?
EXAMPLE FUNCTIONAL REQUIREMENTS
• Library system - F1: Search Book function
– Input: an author’s name
– Output: details of the author’s books and the
location of these books in the library
• ATM (Cash Withdraw)- R1: withdraw cash
– R1.1: select withdraw amount option
• Input: “withdraw amount” option,
• Output: user prompted to enter the account type
– R1.2: select account type
• Input: user option,
• Output: prompt to enter amount
– R1.3: get required amount
• Input: amount to be withdrawn in integer values greater
than 100 and less than10,000 in multiples of 100.
• Output: The requested cash and printed transaction
statement.
2.Non-functional requirements
– Constraints on the services or functions
offered by the system such as timing
constraints, constraints on the development
process, standards, etc.
– Often apply to the system as a whole rather
than individual features or services.
NON-FUNCTIONAL REQUIREMENTS
• Characteristics of the system which can not be
expressed as functions
– Maintainability, Portability, Usability, Security, Safety,
Reliability, Performance, etc.
• Example: How fast can the system produce results?
– So that it does not overload another system to which
it supplies data, etc.
– Needs to be measurable (verifiability)
The requirements engineering process is accomplished
through the execution of seven distinct functions:
1.Inception
2.Elicitation
3.Elaboration
4.Negotiation
5.Specification
6.Validation
7.Management
Inception
 Inception-Starting point, beginning.
 At project inception, software engineers ask a set of
context free question.
 The intent is to establish a basic understanding of
 the problem,
 the people who want a solution,
 the nature of the solution
 effectiveness communication and collaboration between
the customers and the developer.
Elicitation-collecting intelligence information
 Ask the customer, the user and others
 what is objectives for the system?
 How the system fits into the needs of the business?
 How the system or product is to be used on a day to day
basis?
 understand why requirements elicitation is difficult
1. Problem of scope.
2. Problem of understanding
Elaboration
 It means to work out in detail.
 The information obtained from the customer during
inception and elicitation is expanded and refined in
elaboration.
 S/w engg focuses on developing a refined technical
model of software functions, features and constraints.
 It describes how the end user will interact with the
system.
 The end result is an analysis model that defines the
informational, functional, behavioral domain of the
problem.
Negotiation
• Customers, users & stakeholders are asked to rank
requirements and discuss conflicts in priority.
• Risks associated with each requirements are identified
and analyzed.
• To assess the impact of each requirement on project cost
and delivery time.
• Using an iterative approach, requirements are
combined, and /or modified so that each party achieves
some measure of satisfaction.
Specification
“Standard template” should be developed and used for
a specification, or understandable manner.
The specification is a final work product produced by
the requirements engineer. It serves as the
foundation for subsequent software engineering
activities.
Validation
• The work products produced of requirements
engineering are assessed for quality during a
validation step.
• Requirements validation examines the specification to
ensure that all software requirements have been stated
properly.
• The review team that validates requirements includes
software engineers, customers, users and other
stakeholders.
Management
• Requirements management is a set of activities that
help the project team identify, control and track
requirements and changes to requirements at any time
as the project proceeds.
• Requirement management begins with identification.
• Each requirement is assigned a unique identifier.
• Once requirements have been identified, traceability
table are developed.
• Each traceability relates requirements to one or more
aspects of the system.
unit - 2 - software engineer practices.ppt
Software requirements specification
(SRS)
• A software requirements specification (SRS) is a
document that describes what the software will do
and how it will be expected to perform. It also
describes the functionality the product needs to
fulfill all stakeholders (business, users) needs.
unit - 2 - software engineer practices.ppt
SRS format
There is no single precise template for writing good
Software Requirement Specifications. The contents of an
SRS document depends on the software product being
developed.
1.Project scope section
2.Functional requirements
3.Requirement analysis models
4.External interface requirements
5.Non functional requirements
Need of SRS document:
1.Development team require it for developing product
according to the need.
2.Test plans are generated by testing group based on
the describe external behavior.
3.Maintenance and support staff need it to understand
what the software product is supposed to do.
4.Project manager base their plans and estimates of
schedule, effort and resources on it.
5.As a contract between developer and customer.
6.in documentation purpose.
characteristics of a good SRS
document:
• Correctness: SRS is said to be correct if it covers all
the requirements that are actually expected from the
system.
• Completeness: covering all the functional and non-
functional requirements properly.
• Consistency:
Requirements in SRS are said to be consistent if
there are no conflicts between any set of
requirements.
• Modifiability:
SRS should be made as modifiable as possible and
should be capable of easily accepting changes to the
system
• Understandable by the customer:
An end user maybe an expert in his/her specific
domain but might not be an expert in computer
science.
• Right level of abstraction:
If the SRS is written for the requirements phase, the
details should be explained explicitly

More Related Content

PPT
Unit 1 - Introduction to Software Engineering.ppt
ODP
Evolutionary process models se.ppt
PPTX
Methods for handling deadlock
PPT
Object Oriented Analysis and Design
PPT
Architectural Design in Software Engineering SE10
PPTX
Two pass Assembler
PPTX
Staffing level estimation
PPTX
Software requirements specification
Unit 1 - Introduction to Software Engineering.ppt
Evolutionary process models se.ppt
Methods for handling deadlock
Object Oriented Analysis and Design
Architectural Design in Software Engineering SE10
Two pass Assembler
Staffing level estimation
Software requirements specification

What's hot (20)

PPT
Agile development, software engineering
PDF
Run time storage
PPT
PPTX
Use case diagram
PPT
PPTX
Unified process Model
PPT
Use Case Diagram
PPT
Verification and Validation in Software Engineering SE19
PPT
UML diagrams and symbols
PPTX
Software Engineering Layered Technology Software Process Framework
PPT
Slides chapters 26-27
PPTX
Overview of UML Diagrams
PPTX
Srs (software requirement specification) in software engineering basics by ra...
PPTX
Operating system critical section
PPT
UML Diagrams
PPTX
Lecture 3 threads
PPTX
Code Optimization
PPTX
Software Crisis
PPT
Architecture of net framework
PPTX
UML and Software Modeling Tools.pptx
Agile development, software engineering
Run time storage
Use case diagram
Unified process Model
Use Case Diagram
Verification and Validation in Software Engineering SE19
UML diagrams and symbols
Software Engineering Layered Technology Software Process Framework
Slides chapters 26-27
Overview of UML Diagrams
Srs (software requirement specification) in software engineering basics by ra...
Operating system critical section
UML Diagrams
Lecture 3 threads
Code Optimization
Software Crisis
Architecture of net framework
UML and Software Modeling Tools.pptx
Ad

Similar to unit - 2 - software engineer practices.ppt (20)

PPTX
It's computer science something UNIT 2.pptx
PDF
Introduction to software engineering
PPTX
Week 1Lecture2222222222222222222222.pptx
PPTX
Software engineering
PPT
Lecture note 3 on software engineering and development
PDF
5. ch 4-principles that guide practice
PPTX
Principles that Guide Practice
PPT
Software engineering
PPT
Software engineering -core topics
PPTX
software engineering 2 Chapter notes of software engineering in detail to stu...
PDF
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
PPTX
Software Engineering Practice
PPTX
Software engineering
PPT
04 Software Engin Practice with best example
PPT
lec9-ch7.ppt
PPT
Principles of guide practices for project
PPT
Chapter_04_of_Software_engineering_book.ppt
PPTX
sepm.pptx tttg. Y tfczAff. Rrfv vv f rfv.
PPT
Software System Engineering - Chapter 3
It's computer science something UNIT 2.pptx
Introduction to software engineering
Week 1Lecture2222222222222222222222.pptx
Software engineering
Lecture note 3 on software engineering and development
5. ch 4-principles that guide practice
Principles that Guide Practice
Software engineering
Software engineering -core topics
software engineering 2 Chapter notes of software engineering in detail to stu...
softwareengineeringpractice-141002214920-phpapp02 (1).pdf
Software Engineering Practice
Software engineering
04 Software Engin Practice with best example
lec9-ch7.ppt
Principles of guide practices for project
Chapter_04_of_Software_engineering_book.ppt
sepm.pptx tttg. Y tfczAff. Rrfv vv f rfv.
Software System Engineering - Chapter 3
Ad

Recently uploaded (20)

PDF
Caterpillar Cat 315C Excavator (Prefix CJC) Service Repair Manual Instant Dow...
PPT
ACCOMPLISHMENT REPOERTS AND FILE OF GRADE 12 2021.ppt
PDF
Renesas R-Car_Cockpit_overview210214-Gen4.pdf
PPTX
Intro to ISO 9001 2015.pptx for awareness
PDF
Caterpillar Cat 315C Excavator (Prefix ANF) Service Repair Manual Instant Dow...
PDF
Caterpillar CAT 311B EXCAVATOR (8GR00001-UP) Operation and Maintenance Manual...
PPTX
Materi Kuliah Umum Prof. Hsien Tsai Wu.pptx
PDF
industrial engineering and safety system
PDF
EC290C NL EC290CNL Volvo excavator specs.pdf
PPT
Kaizen for Beginners and how to implement Kaizen
PDF
Caterpillar CAT 312B L EXCAVATOR (2KW00001-UP) Operation and Maintenance Manu...
PDF
RPL-ASDC PPT PROGRAM NSDC GOVT SKILLS INDIA
PDF
3-REasdfghjkl;[poiunvnvncncn-Process.pdf
PPTX
Gayatri Cultural Educational Society.pptx
PDF
Volvo EC290C NL EC290CNL Hydraulic Excavator Specs Manual.pdf
PPT
Your score increases as you pick a category, fill out a long description and ...
PDF
Volvo EC290C NL EC290CNL excavator weight.pdf
PPTX
laws of thermodynamics with diagrams details
PPTX
laws of thermodynamics with complete explanation
PPTX
Robot_ppt_YRG[1] [Read-Only]bestppt.pptx
Caterpillar Cat 315C Excavator (Prefix CJC) Service Repair Manual Instant Dow...
ACCOMPLISHMENT REPOERTS AND FILE OF GRADE 12 2021.ppt
Renesas R-Car_Cockpit_overview210214-Gen4.pdf
Intro to ISO 9001 2015.pptx for awareness
Caterpillar Cat 315C Excavator (Prefix ANF) Service Repair Manual Instant Dow...
Caterpillar CAT 311B EXCAVATOR (8GR00001-UP) Operation and Maintenance Manual...
Materi Kuliah Umum Prof. Hsien Tsai Wu.pptx
industrial engineering and safety system
EC290C NL EC290CNL Volvo excavator specs.pdf
Kaizen for Beginners and how to implement Kaizen
Caterpillar CAT 312B L EXCAVATOR (2KW00001-UP) Operation and Maintenance Manu...
RPL-ASDC PPT PROGRAM NSDC GOVT SKILLS INDIA
3-REasdfghjkl;[poiunvnvncncn-Process.pdf
Gayatri Cultural Educational Society.pptx
Volvo EC290C NL EC290CNL Hydraulic Excavator Specs Manual.pdf
Your score increases as you pick a category, fill out a long description and ...
Volvo EC290C NL EC290CNL excavator weight.pdf
laws of thermodynamics with diagrams details
laws of thermodynamics with complete explanation
Robot_ppt_YRG[1] [Read-Only]bestppt.pptx

unit - 2 - software engineer practices.ppt

  • 2.  Software engineering practice is a collection of concepts, principals, methods and tools that a software engineer calls upon on daily basis.  Practice allows managers to manage software projects and software engineers to build computer programs.
  • 3. Essence of practice 1.Understand the problem.(communication and analysis) 2.Plan a solution.(modeling and software design) 3.Carry out the plan.( code generation) 4.Examine the result for accuracy(testing and quality assurance)
  • 4. Understand the problem  Who are the stakeholder?  What data, functions, features and behavior are required to properly solve the problem?  Is it possible to represent smaller problems that may be easier to understand?  Can the problem be represented graphically?
  • 5. Plan a solution  Have you seen similar problems before?  Has a similar problem been solved?  Can you represent a solution in a manner that leads to effective implementation?  Can a design model be created?
  • 6. Carry out the plan.  Does the solution conform to the plan?  Each component part of the solution is correct?  Has the design reviewed?
  • 7. Examine the result  Is it possible to test each component part of the solution?  Has a reasonable testing strategy been implemented?  Has the software been validated against all stakeholder requirements?
  • 8. Core principles of Software Engineering 1. The Reason It All Exists. 2.Keep It Simple, Stupid! 3.Maintain The Vision. 4.What you produce ,Others will Consume. 5.Be Open To The Future. 6.Plan Ahead For Reuse 7.Think!
  • 9. 1st Principle: The Reason It All Exists  The software exists for one reason: to provide value to its users.  Before specifying system requirement, functionality, hardware platform, development process ask question such as: “Dose this add real value to the system?”  If answer is no, don't do it.
  • 10. 2nd Principle: Keep It Simple, Stupid!  All design should be as simple as possible, but no simpler.  This facilitates having a more easily understood and easily maintained system.  Simple does not mean that features should be discarded in the name of simplicity.
  • 11. 3rd Principle: Maintain The Vision  A Clear vision is essential to the success of a software project.  Compromising the architectural vision of a software system weakens and will eventually break even a well designed system.  Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project.
  • 12. 4th Principle: What you produce ,Others will Consume  Always specify design and implement knowing someone else will have to understand what you are doing.  Someone may have to debug the code you write, and that makes them a user of your code.  Making their job easier adds value to the System.
  • 13. 5th Principle: Be open to the Future  A system with a long lifetime has more value.  Software lifetimes are typically measured in months instead of years.  System should be ready to adapt changes.  System that adapt changes have been designed this way from start.  Always keep asking “what if?” and prepare for all possible answers.
  • 14. 6th Principle: Plan ahead for Reuse  Reuse saves time and effort.  Achieving a high level of reuse is arguably the hardest goal to accomplish in developing a software system.  The reuse of code and designs has been proclaimed as a major benefit of using object oriented technologies.
  • 15. 7th Principle: Think!  Placing clear, complete thought before action almost always produces better results.  When you think about something, you are more likely to do it right.  You also gain knowledge about how to do it right again.  When clear thoughts has gone into system, value comes out.
  • 16. Communication Practices  Before customer requirements can be analyzed, modeled, or specified they must be gathered through a communication activity.  Effective communication is among the most challenging activities that confront a software engineer.
  • 17. Principles 1st : Listen. Try to focus on speakers words. If something is unclear, ask for clarification. 2nd :Prepare before you communicate. Spend some time to understand the problem before you meet with others. If you have responsibilities for conducting a meeting, prepare an agenda in advance of the meeting. 3rd :Someone should facilitate the activity. Every communication meeting should have a leader to keep conversation moving in a productive direction
  • 18. 4th : Face to face communication is best. Works better when some other representation of the relevant information is present. For example, a participant may create a drawing 5th : Take notes and document decisions. Someone participating in the communication should serve as a “recorder” 6th : Strive for collaboration. trust among team members and creates a common goal for the team. 7th : Stay focused, modularize your discussion. discussion will bounce from one topic to the next
  • 19. Principles 8th :Draw a picture to clear your idea: A sketch or drawing can often provide clarity when words fail to do the job. 9th : Keep the discussion to “ move on ” 1. once there is an agreement to do something . 2. If you cannot agree to something. 3. If a feature of function is not clear.
  • 20. Planning practices  Good planning leads to successful result.  The planning activity encompasses a set of management and technical practices that enable the software team to define a road map as it travels towards its strategic goal and tactical objectives.  Planning includes complete cost estimation, resources, scheduling and also risk analysis.
  • 21. Principle 1: Understand the scope of the project. Its impossible to use a road map if you don't know where you are going. Scope provides the software team with destination.
  • 22. Principle 2: Involve the customer in the planning activity. The customer defines priorities and establishes project constraints. To accommodate these realities software engineers must often negotiate order of delivery,time lines and other project related issues.
  • 23. Principle 3: Recognize that planning is iterative. Principle 4:Estimate based on what you know Principle 5:Consider risk as you define the plan Principle 6: Be realistic. Principle 7: Adjust granularity as you define the plan.
  • 24. Principle 8: Define how you intend to ensure Quality. Principle 9: Describe how you intend to accommodate change. Principle 10: Track the plan frequently and make adjustment as required.
  • 25. Modeling Practice  Models are created for better understanding of the actual entity to be built or design.  When the entity is a physical thing, we can build model that is identical in form and shape but smaller in scale.  When entity is software our model must take different form. It must be capable of representing information, Architecture, functions ,features and behavior of the system.
  • 26. In SE work, Two classes of model is created. 1. Analysis Model. 2. Design Model.
  • 27. Principle 1: The information domain of problem must be clearly represented. Information domain encompasses the data that flow into the system(from end user, external devices),data that flow out of the system(via user interface, n/w interface, graphics), data stores collection of objects(data i.e. maintained permanently).
  • 28. Principle 2: The function of the software must be defined clearly.  Functions are the processes those transform the I/p flow to the o/p flow.  The process specification for example algorithms provides function details. The specification must be clearly defined.
  • 29. Principle 3: The Behavior of the software must be defined clearly.  Analysis model uses state transition diagrams to represent the behavior of the system clearly.  It shows how the system makes transition from one state to another on occurrence of some external event.
  • 30. Principle 4: The clear hierarchy among information, functions and behavior must be shown.  The proper hierarchy of analysis model leads to easy design. Hence information, functions and behavior of the system must be represented using proper hierarchy i.e. levels or layers.
  • 31. Principle 5: analysis should be clear enough to convert it into design model.  If analysis of requirements is clear and simple then it will be easy for design and implementation in construction step. Hence requirement analysis should be clear enough.
  • 32. Design modeling Principle 1: Design should be traceable from analysis model. Principle 2: Consider the architecture of the system to be built. Principle 3: Design of data is as important as design of function. Principle 4: Internal as well as external interfaces must be designed.
  • 33. Principle 5: user interface design must satisfy all need of end user. Principle 6: Component level design should be functionally independent. Principle 7: Components should be loosely coupled to one another and to the external environment. Principle 8: designed modules should be easy to understand. Principle 9: Accept that design behavior is Iterative.
  • 34. Construction Practices  The construction activity encompasses a set of coding and testing tasks that lead to operational software that is ready for delivery to the customer or end user.  The initial focus of testing is at the component level, often called unit testing. Other levels of testing include integration testing, validation testing and acceptance testing.
  • 35. Coding Principles & Concepts Preparation Principles: Before you write one line of code, be sure you, 1.Understand the problem you're trying to solve. 2.Understand basic design principles & concepts. 3.Pick a programming language that meets the needs of the software to be built & the environment in which it will operate. 4.Select a programming environment that provides tools that will make you work easier. 5.Create a set of unit tests that will be applied once the component you code is completed.
  • 36. Coding Principles: As you begin writing code, be sure you: 1.Constrain your algorithms by following structured programming practice. 2.Select data structures that will meet the needs of the design. 3.Understand the software architecture and create interfaces that are consistent with it. 4.Keep conditional logic as simple as possible. 5.Create nested loops in a way that makes them easily testable. 6.Select meaningful variable names and follow other local coding standards. 7.Write code that is self documenting. 8.Create a visual layout that aids understanding.
  • 37. Testing principles Testing rules or objectives: • Testing is a process of executing a program with the intent of finding an error. • A good test is one that has a high probability of finding an as yet undiscovered error. • A successful test is one that uncovers an as yet undiscovered error.
  • 38. Principle 1: All tests should be traceable to customer requirements. Principle 2: Tests should be planned before testing begins. Principle 3: The Basic principle applies to software testing. Principle 4: Testing should begin “in the small” and progress toward testing “in the large”. Principle 5: Exhaustive testing is not possible.
  • 39. Deployment  The deployment activity encompasses 3 actions: delivery, support and feedback.  Deployment happens not once, but a number of times as software moves towards completion.  Each delivery cycle provides the customer and end users with an operational software increment that provides usable functions and features.
  • 40. Principles 1st : Customer expectations for the software must be managed. 2nd : A complete delivery package should be assembled and tested. 3rd: A support system must be established before the software is delivered. 4th : Appropriate instructional materials must be provided to end users. 5th : Buggy software should be fixed first, delivered later.
  • 41. Requirement Engineering  The first two activities in the generic process framework is that of communication and modelling.  These activities are concerned with discovering the requirements of the software which the customer is asking to have developed.  Requirements engineering is concerned with understanding the software system that the customer has requested. It provides the base on which software design and programming can proceed.
  • 42. Requirement Engineering • Importantly, if the developers do not understand the requirements, it is very likely that the software will not meet the customer's needs. • This makes understanding the customer's requirements important to the success of the development project.
  • 43. TYPES OF REQUIREMENTS 1.Functional requirements – Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.
  • 44. FUNCTIONAL REQUIREMENTS • Descriptions of data to be entered into the system • Descriptions of operations performed by each screen • Descriptions of work-flows performed by the system • Descriptions of system reports or other outputs • Who can enter the data into the system?
  • 45. EXAMPLE FUNCTIONAL REQUIREMENTS • Library system - F1: Search Book function – Input: an author’s name – Output: details of the author’s books and the location of these books in the library
  • 46. • ATM (Cash Withdraw)- R1: withdraw cash – R1.1: select withdraw amount option • Input: “withdraw amount” option, • Output: user prompted to enter the account type – R1.2: select account type • Input: user option, • Output: prompt to enter amount – R1.3: get required amount • Input: amount to be withdrawn in integer values greater than 100 and less than10,000 in multiples of 100. • Output: The requested cash and printed transaction statement.
  • 47. 2.Non-functional requirements – Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc. – Often apply to the system as a whole rather than individual features or services.
  • 48. NON-FUNCTIONAL REQUIREMENTS • Characteristics of the system which can not be expressed as functions – Maintainability, Portability, Usability, Security, Safety, Reliability, Performance, etc. • Example: How fast can the system produce results? – So that it does not overload another system to which it supplies data, etc. – Needs to be measurable (verifiability)
  • 49. The requirements engineering process is accomplished through the execution of seven distinct functions: 1.Inception 2.Elicitation 3.Elaboration 4.Negotiation 5.Specification 6.Validation 7.Management
  • 50. Inception  Inception-Starting point, beginning.  At project inception, software engineers ask a set of context free question.  The intent is to establish a basic understanding of  the problem,  the people who want a solution,  the nature of the solution  effectiveness communication and collaboration between the customers and the developer.
  • 51. Elicitation-collecting intelligence information  Ask the customer, the user and others  what is objectives for the system?  How the system fits into the needs of the business?  How the system or product is to be used on a day to day basis?  understand why requirements elicitation is difficult 1. Problem of scope. 2. Problem of understanding
  • 52. Elaboration  It means to work out in detail.  The information obtained from the customer during inception and elicitation is expanded and refined in elaboration.  S/w engg focuses on developing a refined technical model of software functions, features and constraints.  It describes how the end user will interact with the system.  The end result is an analysis model that defines the informational, functional, behavioral domain of the problem.
  • 53. Negotiation • Customers, users & stakeholders are asked to rank requirements and discuss conflicts in priority. • Risks associated with each requirements are identified and analyzed. • To assess the impact of each requirement on project cost and delivery time. • Using an iterative approach, requirements are combined, and /or modified so that each party achieves some measure of satisfaction.
  • 54. Specification “Standard template” should be developed and used for a specification, or understandable manner. The specification is a final work product produced by the requirements engineer. It serves as the foundation for subsequent software engineering activities.
  • 55. Validation • The work products produced of requirements engineering are assessed for quality during a validation step. • Requirements validation examines the specification to ensure that all software requirements have been stated properly. • The review team that validates requirements includes software engineers, customers, users and other stakeholders.
  • 56. Management • Requirements management is a set of activities that help the project team identify, control and track requirements and changes to requirements at any time as the project proceeds. • Requirement management begins with identification. • Each requirement is assigned a unique identifier. • Once requirements have been identified, traceability table are developed. • Each traceability relates requirements to one or more aspects of the system.
  • 58. Software requirements specification (SRS) • A software requirements specification (SRS) is a document that describes what the software will do and how it will be expected to perform. It also describes the functionality the product needs to fulfill all stakeholders (business, users) needs.
  • 60. SRS format There is no single precise template for writing good Software Requirement Specifications. The contents of an SRS document depends on the software product being developed. 1.Project scope section 2.Functional requirements 3.Requirement analysis models 4.External interface requirements 5.Non functional requirements
  • 61. Need of SRS document: 1.Development team require it for developing product according to the need. 2.Test plans are generated by testing group based on the describe external behavior. 3.Maintenance and support staff need it to understand what the software product is supposed to do. 4.Project manager base their plans and estimates of schedule, effort and resources on it. 5.As a contract between developer and customer. 6.in documentation purpose.
  • 62. characteristics of a good SRS document: • Correctness: SRS is said to be correct if it covers all the requirements that are actually expected from the system. • Completeness: covering all the functional and non- functional requirements properly. • Consistency: Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements.
  • 63. • Modifiability: SRS should be made as modifiable as possible and should be capable of easily accepting changes to the system • Understandable by the customer: An end user maybe an expert in his/her specific domain but might not be an expert in computer science. • Right level of abstraction: If the SRS is written for the requirements phase, the details should be explained explicitly