CHAPTER ONE

SOFTWARE ENGINEERING (SE) TOOLS & PRACTICES FOR

SOFTWARE ENGINEERING
Before discussing about the SE Practices you have to…
• Learn software process framework activities
• Know umbrella activities for SE practices
1. Generic Frame work (SW process frame work activities)
Software Process Framework is a collection of activities, actions, and
tasks which are performed when some work product is to be created. It
consists of five frame work activities that are applicable to all software
projects. It also includes all set of umbrella activities.

3
Figure 1 - Software process framework activities
Cont…
•
Cont…
A generic process framework encompasses five activities which are given
below.
• Communication: In this activity, heavy communication with
customers and other stakeholders, requirement gathering is done.
• Planning: In this activity, we discuss the technical related tasks, work
schedule, risks, required resources etc.
• Modeling: Modelling is about building representations of things in the

5
 ‘real world’. In modelling activity, a product’s model is created in
order to better understanding and requirements.
Construction: In software engineering, construction is the application
of set of procedures that are needed to assemble the product. In this
activity, we generate the code and test the product in order to make
better product.
• Deployment: In this activity, a complete or non-complete products or
software are represented to the customers to evaluate and give
feedback. on the basis of their feedback we modify the products for
supply better product.

6
Cont…
•
2. Umbrella Activities
It is a set of steps or procedures that the software team follows to maintain
the progress, quality, change and risk of the overall development task.
Umbrella activity includes.
• Software Project Tracking and Control - Before the actual
development begins, a schedule for developing the software is created.
Based on that schedule the development will be done. However, after a
certain period of time it is required to review the progress of the
development to find out actions which are in need to be taken to

7
 complete the development, testing etc. in time. The outcome of the
review might require the development to be rescheduled.
Risk Management - It is a series of steps that help a software team to
understand and manage uncertainty. It’s a really good idea to identify
it, assess its probability of occurrence, estimate its impact, and
establish a contingency plan that─ ‘should the problem actually
occur’.
• Software Quality Assurance - The quality of the software such as user
experience, performance, load handling capacity etc. should be tested
and confirmed after reaching predefined milestones. This reduces the

8
Cont…
•
task at the end of the development process. It should be conducted by
dedicated teams so that the development can keep going on.

9
Cont…
•
Formal Technical Reviews - Software engineering is done in clusters
or modules, after completing each module, it is good practice to
review the completed module to find out and remove errors so their
propagation to the next module can be prevented.
• Measurement & Metrics - This will include all the measurement of
every aspects of the software project.
• Software Configuration Management (change management) - It is a
set of activities designed to control change by identifying the work
products that are likely to change, establishing relationships among

10
Cont…
•
them, defining mechanisms for managing different versions of these
work products.
Re-usability Management - This includes the backing up of each
part of the software project they can be corrected or any kind of
support can be given to them later to update or upgrade the software at
user/time demand.
• Document preparation and production - All the project planning
and other activities should be hardly copied and the production get
started here.

11
 The Essence of Practice
• Essence is a language for defining methods and practices common to
all software engineering.
• Essence was created by Software Engineering Method and Theory
(SEMAT) and approved by The Object Management Group (OMG)
as a standard in 2014.
• Essence intuitively/automatically describes all common aspects of a
software development endeavour and helps teams understand where
they are, what’s missing or what needs to be addressed - regardless of
each team’s prescribed way of working.

12
Cont…
•
• Practice is a broad array of concepts, principles, methods, and tools
that you must consider as software is planned and developed.

13
Cont..
George Polya, in a book written in 1945 (!), describes the essence of
software engineering practice as follow…
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).
In the context of software engineering, these common sense steps lead to
a series of essential questions.

14
Cont..
1. Understand the problem (communication and analysis)
• Who are the stakeholders?
• What are the unknowns? “Data, functions, features to solve the
problem?”
• Can the problem be compartmentalized /sorted/classified? “Smaller
that may be easier to understand?
• Can the problem be represented graphically? Can an analysis model
be created?

15
Cont..
2. Plan a solution (modeling and software design)
• Have you seen a similar problem before?
• Has a similar problem been solved? If so, is the solution reusable?
• Can sub-problems be defined?
• Can you represent a solution in a manner that leads to effective
implementation?
3. Carry out the plan (code generation).
• Does the solution conform to the plan?

16
 • Is each component part of the solution probably correct?
Cont..
4. Examine the result for accuracy (testing and quality assurance)
• Is it possible to test each component part of the solution?
• Does the solution produce results that conform to the data, functions,
features, and behavior that are required?

17
 Hooker’s General Principles
David Hooker has proposed seven core principles that focus on software
engineering practice as a whole. They are as follows.
1. The Reason It All Exists - Provide value to the customer and the user.
If you can’t provide value, then don’t do it.
2. KISS—Keep It Simple, Stupid! - All designs should be as simple as
possible, but no simpler. This facilitates having a more easily
understood and easily maintained system.

18
 3. Maintain the product and project “vision.” - A clear vision is
essential to the success of a S/W project. You have to know what and
why you are doing?
The STUPID practice group consists of:

• Singleton:

• Tight Coupling

• Untestability

19
• Premature Optimization

• Indescriptive Naming

• Duplication

20
Cont…
4. What you produce, others will consume - Always specify, design,
and implement knowing someone else has to understand what you are
doing.
5. Be open to the Future - Never design yourself into a corner. Always
ask “what if,” and prepare yourself for all possible answers by creating
systems that solve the general problem, not just the specific one. (It
should be ready for any change, ex. SQL, SQLi and PDO)
6. Plan Ahead for Reuse - Planning ahead for reuse reduces the cost and
increases the value of both the reusable components and the systems
into which they are incorporated.

21
7. Think for better solution! - Placing clear, complete thought before
action almost always produces better results.
1. Communication Practices
Before customer requirements can be analyzed, modeled, or specified
they must be gathered through a communication (also called requirement
elicitation) activity.
So there is many principles apply equally to all of communication that
occur within software project.
Some principles are following:-

22
Cont…
1. Listen carefully- focus on the speaker’s words, rather than
formulating your response to those words. Be a polite listener.
2. Prepare before you communicate - Spend the time to understand the
problem before you meet with others “research”.
3. Someone should facilitate the communication activity - Have a
leader “moderator” to keep the conversation moving in a productive
direction.
4. Face-to-face communication is best - Face-to-face communication is
beer but even if some document related to that particular subject or
discuss is given.

23
5. Take notes and document decisions - Note down all important points
and issue raised in the meeting maintain record. One participant of
meeting may act as a recorder for the notes and document decision.
Cont…
6. Collaborate with the customer - Each small collaboration serves to
build trust among team members and creates a common goal for the
team.
7. Stay focused, modularize your discussion - The facilitator should
keep the conversation modular; leaving one topic only after it has been
resolved.

24
Cont…
8. Draw pictures when things are unclear - Though verbal
communication is important a sketch or drawing can be often provide
clarity when words fails to do job.
9. Keep the discussion to “ move on ” -
A. Once there is an agreement to do something
B. If you cannot agree to something
C. If a feature of function is not clear. In the meeting many people
require to discussion different issues
10. Negotiation is successful when both parties agree - there are many
instances in which software engineer and customer must negotiate
function and feature priorities and delivery dates.
25
 2. Planning Practices
The planning activity encompasses a set of management and technical
practices that enable the software team to define a road map as it travels
toward its strategic goal and tactical objectives. There are some principles
as follow:-
1. Understand the scope of project - Scope provides the software team
with a destination as scope represent the range within which
development take place.
2. Involve the customer in the planning activity - The customer
defines priorities and establishes project constraints. S/W engineers

26
Cont…
must often negotiate orders of delivery, timelines, and other related
issues.
3. Recognize that planning is iterative - A plan must be adjusted to
accommodate changes.
4. Estimate based on what you know - If efforts, cost and task
estimates are reliable so estimation provides reliability and
conveniences to software team if the information is reliable. (Example
Big and Small company)
5. Consider risk as you define the plan - Risk is event when cause
happens some unwanted outcomes because risk may have high impact

27
 and high probability on project, which will destroy it. So proper
management of risk is a required
6. Be realistic - Even the best S/W engineers make mistakes.

28
Cont…
7. Adjust granularity as you plan - A fine granularity plan provides
significant work task detail that is planned over relatively short time
increments.
8. Define how quality will be achieved - Formal technical review is
meeting conducted by technical staff to find out defects in any stage
of development and quality is improved by removing defects that is
why it mention very clear to achieve quality.
9. Plan well to absorb the change- “Can the customer request a
change at any time?”

29
10. Always keep track of the plan and make changes as required -
Track the progress of project development on daily basis all team
members should participate in planning activity so that they will
accept to recover the lagging schedule.

30
Cont…
Boehm’s Seven Principles
Boehm has presented W5HH questions for effective project planning.
1. Why is the system being developed? Does the business purpose
justify the expenditure of people, time, and money?
2. What will be done? Identify the functionality to be built.
3. When will it be accomplished? Establish a workflow and timeline
for key project tasks and identify milestones required by the customer.
4. Who is responsible for a function? Define members’ roles and
responsibilities of software members.

31
5. Where are they located (organizationally)? Customers also have
roles and responsibilities.
6. How will the job be done technically and managerially? Once a
scope is defined, a technical strategy must be defined. Everything
should defined or do in terms of technical terms only.
7. How much of each resource is needed? The answer is derived by
developing estimates based on answers to earlier questions.

32
Cont…
3. Modeling Practices
Modeling helps to understand the actual entity to be built. In software
engineering work, two models are created: analysis models and design
models.
• Analysis models - represent the customer requirements by depicting
the S/W in three different domains: the information domain, the
functional domain, and the behavioral domain.
• Design models - represent characteristics of the S/W that help
practitioners to construct it effectively: the architecture, the user
interface, and component-level detail.

33
 Analysis Modeling Principles
1. The information domain of the problem (the data that flows in and out
of a system) must be represented and understood.
2. The functions that the software performs must be defined.
3. The behaviour of the software (as a consequence of external events)
must be represented. Use state chart diagram
4. The models that depict information, function, and behaviour must be
partitioned in manner that uncovers detail in a layered (or hierarchical)
fashion.

34
5. The analysis task should move from essential information toward
implementation detail (Analysis should be clear enough to convert
into design model)
Design Modeling Principles
The software design model is the equivalent of an architect’s plans for a
house.
1. Design must be traceable from the analysis model
2. Always consider the software architecture of the system to be built.
3. Design of data is as important as design of functions (ER diagram).
4. Interfaces (both internal and external) must be designed with care.
35
5. User interface design must satisfy all needs of end user.
6. Component-level design should be functionally independent
7. Components should be loosely coupled to one another and to the
external environment.
Cont…
8. Design models (representations) should be easily understandable.
9. The design should be developed iteratively; with each iteration the
designer should strive for greater simplicity.

36
 4. Construction Practices
In this text “construction” is defined as being composed of both coding
and testing.
4.1 Coding principles
There are a number of fundamental principles that can be stated –
❖ Preparation Principles - Before writing one line of code, be sure of
• Understand the problem you are trying to solve.
• Understand the basic design principles.
• Pick a programming language that meets the needs of the S/W to
be built.
37
 4. Construction Practices Cont…
• Select a programming environment that provides a tool that will
make your work easier (example – eclipse, PyCharm etc.).
• 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
• Constrain your algorithm by following structured programming
practice.
• Select the proper data structure.
• Understand the software architecture.
38
 • Keep conditional logic as simple as possible.
4. Construction Practices Cont…
• Create easily tested nested loops
• Write self-documenting code (with comments)
❖ Validation Principles - After you’ve completed your first coding pass,
be sure you
• Conduct a code walkthrough (Peer review between programmer
and other teams).
• Perform unit tests and correct errors.
• Refactor the code (removing unwanted things).
39
 4. Construction Practices Cont…
4.2 Testing Principles
• Test must be conducted to validate customer requirements
• Tests should be well planned before starting testing work
• The pareto principles is applicable to software testing
• Testing should start from individual unit and finally go toward testing
of complete system as whole
• Accept testing of every combination of path is not possible (check
their similarity)

40
 5. Deployment Practices
• Customer Expectations for the software must be managed. “Don’t
promise more than you can deliver.”
• A complete delivery package should be assembled and tested (not only
SW but also delivering installation procedure etc.)
• A support regime must be established before the software is delivered.
• Appropriate instructional materials must be provided to end-users.
• Don’t delivered buggy or defective software.

41
42