Sunteți pe pagina 1din 56

Chapter 2

Software engineering practices And Software


requirements Engineering

Marks-16
 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?

Problem: Write a function which takes two numbers and returns their sum.
Plan a solution
 Have you seen similar problems before?
 Has a similar problem been solved?
 Can sub-problems be defined?
 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?
 Is each component part of the solution
provably correct?
 Has the design and code been 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!
The First 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.
The Second 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.

Indeed, the more elegant designs are usually the
more simple ones.
The Third 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.
The Fourth 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.
The Fifth 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.
 Never design yourself to a corner.

Always keep asking “what if?” and prepare for all
possible answers.
The Sixth 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.
The Seventh 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
Principle #1: Listen. Try to focus on speakers words.
If something is unclear, ask for clarification.
Principle #2: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.
Principle #3:Someone should facilitate the activity.
Every communication meeting should have a leader
to keep conversation moving in a productive direction
Principle #4: 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
Principle #5: Take notes and document decisions.
Someone participating in the communication should
serve as a “recorder”
Principle #6: Strive for collaboration. trust among team
members and creates a common goal for the team.
Principle #7: Stay focused, modularize your
discussion. discussion will bounce from one topic to
the next
Principles
Principle #8:Draw a picture to clear your idea: A
sketch or drawing can often provide clarity when
words fail to do the job.
Principle #9: 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.
Principle #10:Negotiation is successful when
both parties win.
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.
Validating principles
After you've completed your first coding pass, be
sure you:
1.Conduct a code walk through when
appropriate.
2.Perform unit tests and correct errors you've
uncovered.
3.Re-factor the code.
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 long
before testing begins.
Principle #3: The Pareto 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.
 Modern software process models are
evolutionary in nature, 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.
 Each support cycle provides documentation
& human assistance for all functions and
features introduced during all deployment cycles
to date.
 Each feedback cycle provides the software
team with important guidance that results in
modifications to the functions, features and
approach taken for the next increment.
Principle #1: Customer expectations for the
software must be managed.

Principle #2: A complete delivery package should


be assembled and tested.

Principle #3: A support regime must be


established before the software is delivered.

Principle #4: Appropriate instructional materials


must be provided to end users.

Principle #5: Buggy software should be fixed first,


delivered later.
Requirement Engineering
 Requirements engineering, like all other
software engineering activities, must be
adapted to the needs of the process, the
project , the product, and the people doing
the work.
 Software process perspective, requirements
engineering is a software engineering action
that begins during the communication
activity and continues into the modeling
activity.
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 that is desired and
 effectiveness of preliminary 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?
 What is to be accomplished?
 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?
 Christel and Kang identified a number of problems that help
us understand why requirements elicitation is difficult
1. Problem of scope.
2. Problem of understanding
3. Problem of volatility
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
 The requirements engineer must reconcile conflicts
through process of negotiation.
 Customers, users & stakeholders are asked to rank
requirements and discuss conflicts in priority.
 Risks associated with each requirements are
identified and analyzed.
 Rough “guesstimates” of development effort are
made and used to assess the impact of each
requirement on project cost and delivery time.
 Using an iterative approach, requirements are
eliminated, combined, and /or modified so that
each party achieves some measure of satisfaction.
Specification
“Standard template” should be developed and used
for a specification, arguing that this leads to
requirements that are presented in a consistent
and therefore more 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 as a consequence 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 unambiguously.
The review team that validates requirements
includes software engineers, customers, users
and other stakeholders.
Requirements 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.
Software requirements specification
(SRS)

A requirements specification for a software system,


is a description of the behavior of a system to be
developed and may include a set of use cases that
describe interactions the users will have with the
software.
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 and also on the expertise
of the people doing the requirement elicitation.
1.Project scope section
2.Functional requirements
3.Requirement analysis models
4.External interface requirements
5.Non functional requirements
The importance of SRS documents
Establish the basis for agreement: SRS helps in
establishing agreement between the customers and the
suppliers on what the software product is to do. The
complete description of the functions to be performed by
the software specified in the SRS will assist the potential
users to determine if the software specified meets their
needs or how the software must be modified to meet their
needs. Reduce the development effort.
Provide a basis for estimating costs and schedules. The
description of the product to be developed as given in the
SRS is a realistic basis for estimating project costs and
can be used to obtain approval for bids or price estimates.
Provide a baseline for validation and
verification. Organizations can develop their
validation and Verification plans much more
productively from a good SRS.
Facilitate transfer. The SRS makes it easier to
transfer the software product to new users or
new machines. Customers thus find it easier to
transfer the software to other parts of their
organization, and suppliers find it easier to
transfer it to new customers.
Serve as a basis for enhancement. Because
the-SRS discusses the product but not the
project that developed it, the SRS serves as a
basis for later enhancement of the finished
product.

S-ar putea să vă placă și