A set of fundamental principles can act as an enabler in the establishment of a discipline; however, software engineering still lacks a set of universally recognized fundamental principles. A fundamental principle is less specific and more enduring than methodologies and techniques. It should be phrased to withstand the test of time. It should not contradict a more general engineering principle and should have some correspondence with “best practice”. It should be precise enough to be capable of support and contradiction and should not conceal a trade off. It should also relate to one or more computer science or engineering concepts.

Principles are common and conceptual statements describing desirable properties of software products and processes. Principles become practice through methods and techniques, often methods and techniques are packaged in a methodology. Methodologies can be enforced by tools.

Principles of Software Engineering have a good impact on the process of software engineering and also on the final product. These principles facilitate to develop software in such a manner that it posses all the qualities like: efficiency, functionality, adaptability, maintainability, and usability. Principles are general, abstract statements describing desirable properties of software processes and products. The principles are applicable throughout the lifecycle of the software. Principles are the set of statements which describe the advantageous features of the product and process. Focus on both process and product is needed to deliver software systems. These principles help in controlling process which in turn helps to control the quality of the product. Only the control of process will not guarantee a quality product therefore it is important to concentrate on both process and quality.

As said earlier there are no fundamentally recognized principles of Software Engineering but we can list down few that may be used in all phases of software development.

• Rigor and formality
• Separation of concerns
• Modularity and decomposition
• Abstraction
• Anticipation of change
• Generality
• Incremental Development
• Reliability

What is Software Engineering?

The primary characteristic that differentiates engineers from scientists is that engineers design and build things, which solve societal problems. Engineers apply the principles of science and mathematics in building things. Software engineers design and build complex software-intensive systems using a range of computing and engineering technologies.

Producing large-scale, high-quality and secure software requires an approach that is rooted in the rigorous and systematic application of engineering principles and proven industry practices.

Rapid advances in search technologies, digital media, mobile computing, eCommerce, cloud computing, social networking and crowd-sourcing are fundamentally changing the way businesses compete and innovate in the era of software everywhere.

Principles explained.

Rigor and formality

Webster defines Rigor as.

• harsh inflexibility in opinion, temper, or judgment : severity
• the quality of being unyielding or inflexible : strictness
• severity of life : austerity b: an act or instance of strictness, severity, or cruelty 2: a tremor caused by a chill 3: a condition that makes life difficult, challenging, or uncomfortable; especially : extremity of cold
• strict precision : exactness

Webster defines Rigor as “harsh inflexibility in opinion”, but that’s not the general meaning of rigor in project management. In general Rigor means the strict precision with which you follow some project management belief or practice. Advancements of this approach enable us to construct more consistent product, organize their cost, and boost our confidence in their reliability. Formality is a stronger requisite than rigor; it requires the software process to be driven and evaluated by mathematical laws.

As it is seen that Software engineering is a very imaginative design activity, so it must be practiced systematically. Rigor is an essential match to imagination that increases our confidence in our developments. Formality is rigor at the highest degree. Software development can accept neither ambiguity nor inaccuracy. Where rigidness helps to produce consistent products, controlling cost and increases discretion in products, Formality checks the process of software production using mathematical laws.

For a project of a particular kind the degree of rigor with which the software procedure is applied may vary significantly. The degree of rigor is function of several project characteristics. For an example non-business, small, critical projects can commonly be addressed with somewhat less rigor which is large complex baseline critical applications. It should be noted however, in which all projects must be conducted in a manner which results in timely high quality deliverables. 4 various degrees of rigor can be defined that are:

Casual: In general umbrella tasks will be documentation and minimized needs will be reduced all basic principles of software engineering are yet applicable. All procedural frame work activities are applied but only a minimum task group is needed.

Structured: Framework related tasks and activities appropriate to the project type will be applied and umbrella activities necessary to ensure high quality will be applied. The process framework will be applied for this project. SQA, SCM measurement and documentation tasks will be conducted in a streamlined manner.

Strict: – The full process will apply for this project with a degree of discipline which will ensure high quality. Robust documentation will be produced and all umbrella activities will be applied.

Quick Reaction:  Framework of process will be applied for this project but because of an emergency condition only those tasks essential to maintaining good quality will be applied Back-filling example for developing a complete set of documentation conducting additional reviews will be accomplished after the application or product is delivered to the customer.

The project manager must have to develop a systematic approach for selecting the degree of rigor which is appropriate for a special project. To accomplish this project adaptation criteria are describe and a task set selector value is computed.

Even for a project of a particular type, the degree of rigor with which the software process is applied may vary significantly. The degree of rigor is a function of many project characteristics. As an example, small, non-mission
critical projects can generally be addressed with somewhat less rigor than large, complex mission critical applications. It should be noted, however, that all projects must be conducted in a manner that results in timely, high
quality deliverables. Four different degrees of rigor are defined for the APM:

Casual. All APM framework activities are applied, but only a minimum task set is required. In general, umbrella tasks will be minimized and documentation requirements will be reduced. All basic principles of software engineering are still applicable.

Structured. The APM framework will be applied for this project. Framework activities and related tasks appropriate to the project type will be applied and umbrella activities necessary to ensure high quality will be applied. SQA, SCM, documentation and measurement tasks will be conducted in a streamlined manner.

Strict. The APM will be applied for this project with a degree of discipline that will ensure high quality. All umbrella activities will be applied and robust documentation will be produced.

Quick Reaction. The APM will be applied for this project, but because of an emergency situation, only those tasks essential to maintaining good quality will be applied. “Back-filling” (e.g., developing a complete set of documentation, conducting additional reviews) will be accomplished after the application/product is delivered to the customer.

What do we mean by “rigor” in Computer Science?

Dictionary: “rigor” = “rigid accuracy, or precision,” or “great care or thoroughness in making sure that something is correct.”
“Rigor mortis” = “a muscular stiffening at time of death. (the rigor of death)
For computer science:
Rigorcs = a careful, thorough, systematic, and precise process for assuring that
solutions to computational problems are correct and robust.
Rigor mortiscs = a careless, partial, unsystematic, and imprecise process for solving computational problems. (the death of rigor)

Computer Science is a Rigorous Discipline

Liberal arts model curriculum [Gibbs 1986]:
“computer science is the systematic study of algorithms and data structures, specifically 1) their formal properties, 2) their mechanical and linguistic realizations, and 3) their applications.”
Computing as a Discipline [Denning 1988]:
“The discipline of computing is the systematic study of algorithmic processes
that describe and transform information: their theory, analysis, design, efficiency, implementation, and application.”
The discipline has three paradigms: theory (mathematics), abstraction (science),
design (engineering), and these occur in all subject areas.
Recent Curriculum models [ACM/IEEE 1991; Walker 1996]:
Theory (as well as abstraction and design) should be interwoven through all
courses, including algorithms, data structures, computer organization, programming languages, and software engineering

Viewing Rigor CS in Three Dimensions

I Curricular rigor = ensuring that the CS courses we teach are rigorous
II Methodological rigor = ensuring that the process for doing CS is rigorous
III Notational rigor = ensuring that our languages and notations are rigorous

I. Curricular Rigor

To be rigorous, a curriculum should meet three goals:
Goal 1: ensure that students can use precise mathematical ideas and notations in
all subject areas.
Goal 2: ensure that students can read and write precise problem specifications
and systematically demonstrate correctness in all subject areas.
Goal 3: ensure that students pay equal attention to design and verification, as to
coding and debugging.

(How) Can a Curriculum Meet these Goals?

Yes, claims the Revised Liberal Arts Model Curriculum [Walker 1996], and in the following way:
Introduce the tools for rigor early (i.e., make sure that discrete mathematics has equal status with CS1, and is thus a prerequisite for data structures)
Use rigorous techniques in CS1 and CS2 (i.e., confirm that the principles of mathematical logic are integral to good programming)
Continue using rigorous techniques in each core course (i.e., integrate the theory and rigorous precision with the practice

II. Methodological Rigor

In the practice of computer science, professionals should use:
Formal tools: discrete mathematics, including propositional and predicate logic,
the calculational method of logic [Gries 1993] and other techniques that demonstrate what a proof is and how to develop proofs.
Programming languages and paradigms that promote rigor by properly including formal specifications.
Software designs that result from a rigorous process, and are correct and robust

III. Notational Rigor

The consistency issue is huge, both in formal methods and in programming languages! E.g., the notation means “substitute N for every free occurrence of x in expression M.” But so does each of the following:
Quine, 1940
Church, 1956
Gries, 1993
Stansifer, 1995
Meyer, 1990 and Watt, 1991
Winksel, 1993 and Friedman, 1999
Sethi, 1996
Scott, 1999
The completeness issue is also huge! E.g., There is no direct representation for
even the basic logical operators in programming languages. (Instead we are
forced to use surrogates like && for , || for , and so forth.)