SEF9 - 05 Why Software Engineering is (a) systematic, (b) disciplined, (c) quantifiable, etc?

The IEEE Definition of Software Engineering (SE).

Software Engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.

QUESTION: What does it mean that Software Engineering (SE) is about the following approaches to the development, operation, and maintenance of software?

(a) systematic,
(b) disciplined,
(c) quantifiable.

HA HA HA.

(a) systematic - Conducting software engineering in a systematic way means following a clear and well defined system in a step-by-step approach. The opposite practice against being systematic is to execute software engineering activities without concern to any system or well defined procedures.

(b) disciplined - Conducting software engineering in a disciplined way means executing software engineering activities in a managed and well controlled manner. The opposite practice against being disciplined is to execute software engineering activities in a free and uncontrolled manner.

(c) quantifiable - Conducting software engineering in a quantifiable way means executing software engineering activities in a way such that the “activities or its elements” are capable of being measured or expressed as a quantity that can be measured. The opposite practice against being quantifiable is to execute software engineering activities without any means to monitor and measure progress and this makes it difficult to make decisions at important and critical points in the software engineering project.


WHAT HAPPENS IF WE ARE NOT SYSTEMATIC, NOT DISCIPLINED AND NOT QUANTIFIABLE IN OUR APPROACH TO SE?

The following things can happen.

(1) Think about "spaghetti code" and "cowboy coding".
===========================================================

http://en.wikipedia.org/wiki/Spaghetti_code

Programmers start writing spaghetti codes.

Spaghetti code is a pejorative term (bad or negative term) used for source code that has a complex and tangled control structure, especially one using many GOTOs, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow tends to look like a bowl of spaghetti, i.e. twisted and tangled. Spaghetti code can be caused by several factors, including inexperienced programmers and a complex program which has been continuously modified over a long life cycle. Structured programming greatly decreased the incidence of spaghetti code.

http://en.wikipedia.org/wiki/Cowboy_coding

Programmers behaving like cowboys.

Cowboy coding is software development where programmers have autonomy over the development process. The programmer can do whatever he wants on anything regarding the software development. This includes control of the project's schedule, languages, algorithms, tools, frameworks and coding style. A cowboy coder can be a lone developer or part of a group of developers working with minimal process or discipline or free and without shared disciplines. It can cause the software project getting into problems like there is little participation by business users, or getting out of control busting agreed targets, going over budgets, missing timelines, unaccomplished milestones, scope creeps, and anything else.

(2) Think about BSOD (Blue Screen of Death).
==========================================================

We can end up with system crashes like BSODs.

http://en.wikipedia.org/wiki/Blue_Screen_of_Death

The Blue Screen of Death (BSOD), officially a STOP Error, also known as Deadscreen, Blue Screen Error, Bluescreen, or bug check, is the error screen displayed by the Microsoft Windows family of operating systems upon encountering a critical error, of a non-recoverable nature, that causes the system to crash. The term is named after the color of the screen generated by the error.

(3) Think about "Software Coding Standards" or "Coding Conventions".
===========================================================

http://en.wikipedia.org/wiki/Coding_standards

We can end up with software codes not understandable by others except the programmer who wrote it. Very hard to maintain code if the "programmer died" or left the company.

Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices and methods for each aspect of a piece program written in this language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality.

Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers. As a result, not following some or all of the rules has no impact on the executable programs created from the source code.

(4) Think about "High Integrity C++ Coding Standards".
===========================================================

http://www.codingstandard.com/HICPPCM/index.html

Without applying good standards, programmers may write code that is prone to bugs and/or difficult for someone else to pick up and maintain.

High quality code is portable, readable, clear and unambiguous. This document defines a set of rules for the production of high quality C++ code. An explanation is provided for each rule. Each rule shall be enforced unless a formal deviation is recorded. Note that Rule 2.1 outlines the process for deviation where this is deemed necessary. The guiding principles of this standard are maintenance, portability, readability and safety.

This standard adopts the view that restrictions should be placed on the ISO C++ language standard in order to limit the flexibility it allows. This approach has the effect of minimising problems created either by compiler diversity, different programming styles, or dangerous/confusing aspects of the language. Different compilers may implement only a subset of the ISO C++ standard or interpret its meaning in a subtly different way that can lead to porting and semantic errors.

And you can think of many more.



--
WASSALAM
wruslan.hahaha

Microsoft Word Version
Return to Software Engineering Fundamentals (SEF9MMUWRY)
Previous Topic: 04 About "software" and about "SWEBOK"
Next Topic: 06 When it comes to big and complex software, Software Engineering (SE) gets ...