The document discusses principles and practices of software engineering. It begins by outlining the essence of problem solving and software engineering practice as understanding the problem, planning a solution, carrying out the plan, and examining the results. It then discusses core principles like ensuring value for users, keeping designs simple, maintaining a clear vision, and thinking before taking action. The document also covers communication practices for requirements gathering and planning practices for defining the project scope and managing risks.

1. Nadar saraswathi college of arts and
Science
Software Engineering
Software Engineering Practice
Submitted by,
S.Vijayalakshmi.

2. SOFTWARE ENGINEERING PRACTICE
 In this part of “software engineering; a practitioner’s approach”
you’ll learn about the principles, concepts, and methods that comprise
software engineering practice.
 Practice is a broad array of concepts, principles, methods, and tools
that you must consider as software planned and developed. It
represents the details-the technical considerations and how to—that are
below the surface of the software process: the things that you’ll need
to actually build high-quality computer software.
 Practice encompasses the technical activities that produce all work
products that are defined by the software process model that has been
chosen.

3. The essence Practice
 In a classic book, How to Solve It, written before modern computes
existed, gorge Polya outlined the essence of problem solving, and
consequently, the essence of software engineering 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 has a stake in the solution to the problem? That is, who are the
stakeholders?
 What are the unknowns? What data, functions, features, and behavior
are required to properly solve the problem?
 Can the problem be compartmentalized? Is it possible to represent
smaller problems that may be easier to understand?

4.  Can the problem be represented graphically? Can an analysis model be
created?
Plan the solution:
 Have you seen similar problems before? Are there patterns that are
recognizable in a potential solution? Is there existing software that
implements the data, functions, features, and behavior that are
required?
 Has a similar problem been solved? If so, are solutions readily
apparent for the sub-problems?
 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 confirm to the plan? IS source code traceable to the
design model?
 Is each component part of the solution probably correct? Have the
design and code been received, or better, has correctness proof been
applied to the algorithm?

5. Examine the result:
 Is it possible to test each component part of the solution? Has a
reasonable testing strategy been implemented?
 Does the solution produce results that confirm to the data? Functions,
features and behavior that are required? Has the software been
validated against all stakeholder requirements?
CORE PRINCIPLES
The Reason It All Exists
 A software system exists for one reason: to value to its users. All
decisions should be made with this in mind. Before specifying a
system requirement, before noting a piece of system functionality,
before determining the hardware platforms or development processes,
ask yourself questions such as: Does this add real value to the system?
If the answer is no, don’t do it. All other principles support this one.

6. KISS (Keep It Simple, Stupid)
 Software design is not a haphazard process. There are many factors to
consider in any design effort. All design should be as simple as
possible, but no simpler. This facilities having a more easily
understood, and easily maintained system. This is not to say that
features, even internal features, should be discarded in the name of
simplicity. Indeed, the more elegant designs are usually the simple
ones. Simple also does not mean “quick and dirty.” In fact, it often, it
often takes a lot of thought and works over multiple iterations to
simplify.
Maintain the Vision
 A clear vision is essential to the success of a software project. Without
one, a project almost unfailingly ends up being “of two [or more]
minds” about itself. Without conceptual integrity, a system threatens to
become a patchwork of incompatible designs, held together by the
wrong kind of screws…

7. what you produce, others will consume
 In some way or other, someone else will use, maintain, document, or
otherwise depend on being able to understand your system. So always
specify, design and implement knowing someone else will have to
understand what you are doing. The audience for any product of
software development is potentially large. Specify with an eye to the
users. Design, keeping the implementers in mind.. Someone may have
to debug the code you writ, and that makes them a user of your code.
Making their job easier adds value to the system.
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. If
you do think about something and still do it wrong, it becomes
valuable experience. A side effect of thinking is learning to recognize
when you don’t know something, at which point you can research the
answer. When clear thought has gone into a system, value comes out.
Applying the first Six Principles requires intense thought, for which
the potential rewards are enormous.

8. COMMUNICATION PRACTICES
 Before customer requirements can be analyzed, modeled, or specified
they must be gathered through a communication (also called
requirements elicitation) activity. A customer has a problem that may
be amenable to a computer- based solution. A developer responds to
the customer’s request for help. Communication has begun. But the
road from communication to understanding is often full of potholes
 Effective communication (among technical peers, with the customer
and other stakeholders, and with project managers) is among the most
challenging activities that confront software engineer. In this context,
we discuss communication principles that apply equally to all forms of
communication that occur within a software project.
Prepare before you communicate
 Spend the time to understand the problem before you meet with others.
If necessary, do some research to understand business domain jargon.
If you have responsibility for conducting a meeting, prepare an agenda
in advance of the meeting.

9. Someone should facilitate the activity.
 Every communication meeting should have a leader (facilitator) to
keep the conversation moving in a productive direction: (2) to mediate
any conflict that does occur; (3) to ensure that other principles are
followed.
Face–to-face communication is best.
 But it usually works better when some other representation of the
relevant information is present. For example, a participant may create
a drawing or a “strawman” document that serves as a focus for
discussion.
Take notes and documentation decisions:
 Things have a way of falling into the cracks. Someone
participating in the communication should serves to build trust
among team members and creates a common goal for the team.

10. Stay focused, modularize your discussion.
The more the people involved in any communication, the more likely
that discussion will bounce from one topic to the next. The facilitator
should keep the conversation modular, leaving one topic to the next.
The facilitator should keep the conversation modular, leaving one topic
only after it has been resolved
If something is unclear, draw a picture.
Verbal communication goes only so far. A sketch or drawing can often
provide clarity when words fail to do the job.
Negotiation is not a contest or a game. It works best when both parties
win.
There are many instances in which the software engineer and the
customer must negotiate functions and features, priorities, and delivery
dates. If the team has collaborated well, all parties have a common
goal. Therefore, negotiation will demand compromise from all parties.

11. PLANNING PRACTICES
 The communication activity helps a software team to define its
overall goals and objectives (subject, of course, to change as time
passes). However, understanding these goals and objectives is not
the same as defining a plan for getting there. The planning
activity encompasses a set of management and technical practices
that enable the software tam to define a road map as it travels
towards its strategic goal and technical objectives.
 Here are many different planning philosophies. Some people are
“minimalists, “arguing that change often obviates the need for a
detailed plan. Others are “traditionalists,” arguing that the plan
provides an effective road map, and the more detail it has, the
less likely the team will become lost. Still others are “agilists,”
arguing that quick “planning game” may be necessary, but that
the road map will emerge as “real work” on the software begins.

12. Understand the scope of the project
 It’s impossible to use a road map if you don’t know
where you’re going. Scope provides the software.
Involve the customer in planning activity
 The customer defines priorities and establishes the
project constraints.
Recognize that planning is iterative.
As work begins, it is very likely that things will
change. As a consequence, the plan must be adjusted
to accommodate these changes. In addition, iterative
and incremental process models dictate re-planning
based on feedback received from users.
Estimate based on what you know.
 The intent of estimation is to provide an indication of effort, cost, and task
duration, based on the team’s current understanding of the work to be done.

13. Consider risk as you define the plan
 If the team has defined risks that have high impact and high
probability, contingency planning is necessary.
Be realistic. People don’t work 100 percent every
day.
 Noise always enters into any human communication. Omission and
ambiguity are facts of life. Change will occur. Even the best software
engineers make mistakes. These and other realities should be
considered as a project plan is established.
Adjust granularity as you define the plan.
 Granularity refers to the level of detail that is introduced as a project
plan is developed. A “fine granularity” plan provides significant work
detail that is planned over relatively short time increments.

14. Define how you intend to ensure quality.
 The plan should identify how the software team intends to ensure
quality. If formal technical reviews are to be conducted, they should be
scheduled.
Describe how you intend to accommodate change.
 Even the best planning can be obviated by uncontrolled change. The
software team should identify how changes are to be accommodated as
software engineering work proceeds.
Track the plan frequently and make adjustments
are required.
 Software project falls behind schedule one day at a time. Therefore, it
makes sense to track progress on a daily basis, looking for a problem
areas and situation in which scheduled work does not confirm to actual
work conducted. When slippage is encountered, the plan is adjusted
accordingly.

15. Thank you