omission.

2.2.2 Principles That Guide Practice

Sotware engineering pratice has a sngle overiding goal-to deliver on-time, high quality, operational
software that contains funtions and features that meet the needs of all stakeholders. To achieve this goal, you

shoukd adopt a set of core principles hat guide your technical work. The following set of core principles are
fundamental to the practice of software engineering:
Principle - Divide and conquer: Staled in a more technical manner, analysis and design should always

emphasize separat ion of concerns (SoC). Alarge problem is easier to solve if it is subdivided into a collection
of elements (or concerns). ldeally, each concern delivers distinct functionality that can be developed, and in some
Gases validated, independently of other concerns.

Principle 2- Understand the use of abstraction: At its core, an abstraction is a simplification of some complex
element of asysem used to communicate meaning in asingle phrase. When Iuse the abstraction sprendsheet, it
sassumed that you understand what a spreadsheet is, the general structure of content that a spreadsheet presents,
and the typical functions that can be applied to it. In software engineering practice. you use many different levels

of abstraction, cach imparting or inplying meaning that must be communicated. In analysis and design work, a
software tcam normally begins wih models that represent high levels of abstraction (e.g.. asprcadsheet) and
sJowly refines thoe models into lower levels of abstraction (e.g., a column or the SUM function).

The intent of an abstraction is to eliminate the necd to communicate details. But sometimes, prohematic effects
preciptated by these details leak" through Wtbout an understanding of the details, the cause of u problem
cannot be easily diagnosed.
Principle 3- Strive for consistency: Whether it's creating a requirements model, developing a software design,

generat ing source code, or creating test cases, the principle of consiskency suggests that afamiliar contexi makes
Dept. af CSE, CIT Mandya Page 19

Software Engineeringand Project Management (BCS501)

software easier to use. As an example, consider the design of a user interface for a WebApp. Cansistent
placement of menu options, the use of aconsistent color scheme, and the consistent use of recognizahle icons al!
help to make the interface ergonomically sound.
Principle 4-Focus on the transfer af information: Sofware is about information transfer from adatabase to
an end user, from a legacy sytem to a WebApp. from an end user into a graphic user interface (GUL), from an
operating syssem to an application, from one software component to another the list is alnos endless. In every
case, information flows acros an interface, and as a consequence, there are opportunities for error, or omission,

or ambiguty. The implication of this principle is that you must pay special atention to the analysis, design,
construction, and testing of interfaces.
Principle 5- Buikd software that exhibits effective modularity: Separation of concerns (Principle 1)
establishes a philosophy for sofware. Modularity provides a mechanism for realizing the philosophy. Any
complex system can be divided into modules (components), but good software engineering practice demands

more. Modularity must be effective. That is, cach module shoukd focus exclusively on one well-constraine d
aspect of the sytem-it should be cohesive in its function and'or constraincd in the content t represents.

Addtionally. modules shoukd be intercoanected in a relatively simpke manner cach module should exhibit low
coupling to other modules, to data sources, and to other environmental aspects.
Principle 6- Look lor patterns: Brad Appleton |App0] suggests that: The goal of patterns within the software
community is to create a body of literature to help software developers resolve recurring problems encountered
throughout all of software development. Patterns help create a shared language for communicating insight and
experience about these problems and their solutions. Formally codifying these solutions and their relationships
lets us successfully capture the body of knowedge which defines our undenstanding of good architectures that
meet the needs of their users

Principle 7. When possible, represent the problem and its solution from a number of different
perspectives: When a problem and its solution are examined from a number of different perspectives, it is more

likely that greater insigh will be achieved and that errors and omissions will be uncovered. For example. a
requirements model can be represented using a data-oriented viewpoint, a function-oriented viewpoint, or
behavioral viewpoint. Each provides adifferent view of the problem and its requirements.
Principe &-Remenber that someone will maintain the software: Over the long term, software will be

corected as defects are uncovered. adapted as its environment changes, and enhanced as stakeholders request
more capabilities. Thexe maintenance activities can be facilitated if solid software engineering practice is applied
throughout the software process.

Dept of CSE,CIT Mandya Page 20

 sensitive device might be waved in the air.

DESIGNMODELING PRNCIPLEs
Principle 1. Design should be traceable to the requirements model. The requirements model describes the
information domain of the problem, user-visible functions, system behavior, and a set of requirements classes
that package business objects with the methods that service them. The design model translates this information
into architecture, a set of subsystems that implement major functions, and a set of components that are the
realization of requirements classes. The elements of the design model shoul |be traceable to the requirements
model.

Principle 2. Always consider the architecture of the system to be built. Sofware architecture is the skeleton
of the system to be buit. It affects interfaces, data structures, program control flow and behavior, the manner i
which testing can be conducted, the maintainability of the resultant system, and uch more. For all of these
reasons, design shoukd start with architectural considerations. Only after the architecture has been established
should component-Jevel issues be considered.

Principle 3. Design of data is as important as design of processing functions. Data design is an essential
element of architectural design. The manner in which data objects are realized within the design cannot be left
Dept. of CSE, CIT Mandya Page 25

Software Engineering and Project Management (BCS501)

to chance. Awell-structured data design helps to simplify program fow, makes the design and implementation
of software components easier, and makes overall processing more efficient
Principle 4. Interfacs (both internal and external) must be designed with care. The manner in which data
flows between the components of a system has much to do with processing effxiency, error propagation, and
design simplicity. A well-designed interface mukes integration easier and assists the teter in validating component
functions.

Principle 5. User interface design should be tuned lo the needs of the end user. However, in every case,
should stress ease of use. The user interface is the visible manifestation of the sofware. No matter how
sophisticated its internal functions, no matter how conprehensive its data structures, no matter how well designed
its architecture, a poor interface design often leads to the perception that the software is "bad.
Principle 6. Component-level design should be functionally independent. Functional independence is a
measure of the "single-mindedness" of a software component. The functionality that is delivered by a component
shoukd be cohesive that is, it shoukd focus on one and only one function or sub function.
Principle 7. Components should be oasely coupled to one another and to the exdernal environment.
Coupling is achieved in many ways- via acomponent interface, by messaging. through global data. As the level
of coupling increases, the likelihood of error propagation also increases and the overall maintainability of the
software decreases. Therefore, component coupling shoukd be kept as low as is reasonable.
Principle 8. Design representations (models) should be easily understandable. The purpose of design is

to communicate information to practitioners who will generate code. to those who will test the sofware. and
to others who may maintain the software in the future. If the design is difficuk to understand, it will not serve
as an effective communication medium

Principle 9. The design shoukd be developed iteratively. Wth each iteration, the designer shoukd strive for
greater simplicty. Like almost all creative activities, design occurs iteratively. The first iterations work to
refine the design and correct errors, but later iterations should strive to make the design as simple as is
possible.
 2.3 PRINCIPLES THATGUDE EACHERAMEWORK ACTIVTY

2.31COMMUNICATIONPRINCIPLES
Principle 1- Listen: Try to focus on the speaker's words, rather than formulating your response to
those words.
Ask for clarification if something is unclear, but avoid constant interruptions. Never become
contentious in your
words or actions (e.g.. rolling your eyes or shaking your hcad) as a person is talking.

Principle 2- 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.
Principle 3- Someone should facilitate the activity: Every communication meet ing shoukd have a leader (a

facilitator) to keep the conversation moving in aproductive direction, (2) to mcdiate any conflict that does occur.
and (3) to ensure than other principles are folkowed.
Principle 4- Face-to-face communication is best: But it usually works better when some other representation
ofthe relevant information is present. For example. aparticipant may create adrawing or a"strawman" document
that serves as a focus for discussion.

Principle 5. Take notes and document decisions: Things have a way of falling into the cracks. Someone
participating in the communication shoukd serve as a "recorder" and write down all important points and
decisions.

Principle 6- Strive for collaboration: Collaboration and consensus occur when the collective knowiedge of
members of the team is used to describe product or system functions or features. Each small collaboration serves
to build trust among team members and creates a common goal for the team
Principle 7-Stay focused; modularize your discussion: The more 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 only after it has been resolved.
Principle 8- 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.

Principle 9- (a) Once you agree to something. move on.

(b) If you cant agree to something, move on.

(c) If a feature or function is unclear and cannot be clarificd at the moment, move on.

Communication, like any software engincering activity, takes time. Rather than terating endlessly, the people

Dept. of CSE, CIT Mandya Page 21

Software Engineering and Project Management (BCS501)

who participate shoukd recognize that many topics require discussion (see Principle 2) andthat "moving on" is
sometimes the best way to achieve communication agility.
Principle 10-Negotiationis not a contest or a game. It works best when both parties win: T
instances in which you and other stakeholders must negotiate functions and features, prioriti
dates. If the team has collaborated well, all parties have a common goal Still, negotiati
compromise from all parties.
 Feature Driven Development (FDD)

Like other agile approaches, FDD adopts a phikosophy that

(1) emphasizes collaboration among people on an FDD team;
(2) manages problem and project complexity using feature-based decomposition followed by the
integration of software increments, and
(3) Communication of technical detail using verbal, graphical, and text-based means. FDD
cmphasizes software quality assurance activities by encouraging an incremental development strategy.
the use of design and code inspections, the application of software quality assurance audits, the
collection of metrics, and the use of patterns
In the context of FDD. a feature "is a client-valued function that can be implemented in two weeks or
less".

" The emphasis on the definition of features provides the following benefits:
Because features are small blocks of deliverable functionality, users can describe them more easily:
understand how they relate to one another more readily: and better review them for ambiguity, error, or
omissions.
" Features can organized into a hierarchical business-related grouping.
Since a feature is the FDD deliverable software increment, the team develops operational features every
two weeks. Because features are small, their design and code representations are easier to inspect
effectively.
Project planning, scheduling. and tracking are driven by the feature hierarchy, rather than an arbitrarily
adopted software engincering task set.
Fisun 3.5

Feature Driven

ICou991 (uih
permissian) Develop Build a Plan Design Build
Overal Features By By By
Ust Feature Feature Feature
Model

(mare shape A i t d teatures A deve opment plan

thar cotent
A desigr Completed
grouped rto sas Class owers ciert-vaue
package
and subject areas Feature Set Owners (sequences) functior
 Adaptive Software Development (ASD):
Adaptive Software Development (ASD) has been proposed by Jim Highsmith as a technique for
building complex software and systems.
The philosophical underpinnings of ASD focus on human collaboration and team self organization.
He defines an ASD "ife cycle" (Figure 3.3) that incorporates three phases, speculation,
collabortion, and learning.

bec

During speculation, the project is initiated and adaptive cycle planning is conducted.
Adaptive cycle planning uses project initiation information-the customer's mission statement,
project constraints (e.g.. delivery dates or user descriptions), and basic requirements-to define the
set of release cycles (software increments) that will be required for the project.
No matter how complete and farsighted the cycle plan, it will invariably change.
Based on information obtained at the completion of the first cycle, the plan is reviewed and adjusted
so that planned work better fits the reality in which an ASD team is working.
Motivated people use collaboration in a way that mutiplies their talent and creative output beyond
their absolute numbers.

This approach is a recurring theme in all agile methods. But collaboration is not easy. It
encompasses communication and teamwork, but it also emphasizes individualism, because
individual creativity plays an important role in collaborative thinking.
It is, above all, a matter of trust. People working together must trust one another to
(1) criticize without animosity.
(2) assist without rescntment,

(3) work as hard as or harder than they do,

(4) have the skill set to contribute to the work at hand, and

L. of CSE, CIT Mandya Page 9

Software Engineering and Project Management(BCS501)

(5) communicate problems or concerns in a way that leads to effective action.
As members of an ASD team begin to develop the components that are part of an adaptive cycle,
the emphasis is on "learning" as much as it is on progress toward a completed cycle.
In fact, Highsmith argues that software developers often overestimate their own understanding (of
the technaology, the process, and the project) and that earning will help them to improve their level
of real understanding.

ASD teams learn in three ways: focus groups, technical reviews, and project postmortems.
The ASD philosophy has merit regardless of the process model that is used.
ASD's overall emphasis on the dynamics of self-organizing teams, interpersonal collaboration, and
individual and team learning yield software project teams that have a much higher likelihood of
 22 CORE PRINCIPLES

Soffware engincering is guided by a collection of core principles that help in the upplication of a
meaningful software process and the execution of effective software engincering methods. At the
process level, core principles establish a philosophical foundation that guides a software team as it
performs framework and umnbrella activities, navigates the process flow, and produces a sct of software
engincering work products,

At the level of practice, core principles establish a collection of values and rules that serve as a guide as
you analyze
a a problem, design a solution, implement and test the solution, and ultimately deploy the
software in the community identified a set of general principles that span software engincering
process and practice:

(1) Provide value to end users,

(2) Keep it simple.
(3) Maintain the vision (of the product and the project).
(4) Recognize that others consume (and must understand)what you produce.
(5) Be open to the future.
(6) plan ahead for reuse, and
(7) think !

Akbougn these gencral principles are important, they are characterized at such a high level of
abstraction that they are sometimes difficult to translate into day-to-day software engincering practice.
2.2.1 Principles That Guide Process
Principe 1-Be agile: Whether the process model you choose is prescriptive or agile, the basic tenets of agile
development shoukd govern your approach. Every aspect of the work you do shoukd emphasize economy of
action keep your technical approach as simple as possible. keep the work products you produce as concise a
possible, and make decisions locally whenever possible.

Principle 2- Focus on quality at every step: The exit condition for every process activity, action, and task
shoukd focus on the quality of the work product that has been produced.

Principle 3-Be ready to adapt: When necessary, adapt your approach to constraints imposed by the problem,
the people, and the project itself.
Principle 4- Build an effective team: Software engineering process and practice are important, but the bottom
line is people. Build a self-organizing team that has mutual trust and respect.

Principle 5- Establish mechanisms for communication and coordination: Projects fail because important
informat ion falls into the cracks and'or stakehokders fail to coordinate their efforts to create a successful end
product. These are management issues and they must be addressed.

Dept. of CSE,CIT Mandya Page 18

Software Engineering and Project Management (BCS501)

Principle 6- Manage change: The approach may be either formal or informal, but mechanisms must be
estabished to manage the way changes are requested, assessed, approved, and inmplemented.
Principle 7- Assess risk: Lots of things can go wrong a software is being developed. It's essential that you
establish contingency plans.

Principle 8 Create work products that provide value for others: Create only those work products that
provide value for other process activities, actions, or tasks. Every work product that is produced as part of
software engineering practice will be passed on to someone else. A list of required functions and features will
be passed along to the person (people) who will develop a design, the design will be passed along to those who
generate code, and so on Be sure that the work product imparts the necessury information without ambiguity or
omission