Software Engineering


Possible reference:


Topic objective: Students should understand what is software engineering and why it is needed. Principles and methods of software engineering should also be roughly mastered. 


  Software engineering:

  • Application of a systematic, disciplined and measurable approach to the development, operation and maintenance of software (that is, the application of engineering to software)
  • Studies on the available approaches to the above



The need for software engineering:

(especially for large software)

              to provide prudent software (costs of development, operation and maintenance which is optimum compared to the benefits of software usage)

              accuracy (according to specification), reliability (operating correctly for a certain period) and ketegapan (able to handle unexpected situations) perisian

              software efficiency


Software quality  - various perspectives:

            developer: increased productivity, low cost, re-use

            maintainer: easily readable code, minimum errors, good documentation, good design

            user: ease of usage (user-friendly), correct functioning, easily executable, easily remembered





  Principles of software engineering:

  • tightness and formalness
  • separation of consideration
  • modularity
  • abstraction
  • foretelling change
  • general
  • incremental



Tightness and Formalness


tightness: set of clear rules and steps, detailed and has to be followed

each step has to be clearly-defined


formalness: set of rules and steps which have a high level of tightness

in mathematical form


Separation of Consideration


      break up large complex problem into smaller scopes

      scheduling software development activities

      focus on different quality objective at a different times

      different individual for different system development task




Break-up of a complex system into simpler modules, which are developed separately and then combined.

Two approaches: decomposition and composition

Each module requires - high level of integrability : contribute to the same cause

                                    - low level of coupling : low dependence between modules




To raise up important aspects from the details of an object, phenomenon or function.

Facilitates the understanding of a large complex system.


Foretelling Change


Capability to expect changes that may happen, with respect to product or process.




Most general solution to a problem

            probably a simpler solution

            possible re-use, use existing available  




Advancing prototypes, versions





General phases of software development


  General phases of software development:

  • planning
  • needs analysis
  • design
  • implementation
  • verification and validation
  • operation and maintenance



In general, a software development life cycle contains the following phases. A phase ends with a milestone or a despatch, which is something tangible (e.g. report)



First phase, but can also appear in the middle if something unexpected occurs.

A part of software project management

Determines the general objective, scope of work, human resource and equipment, cost e.g. estimate using the COCOMO model), work planning schedule (e.g. aided by PERT diagram).



Basic COCOMO (Constructive Cost Model) model:


Effort (in man-months),

                     E = A (Nrbk)b

Duration (in months),

                     D = C (E)d

Nrbk is no. of lines of code (thousands), and

with the following values:

A = 2.4 (for basic project)

       3.0 (for intermediate project)

       3.6 (for advanced project)

b  = 1.05 (for basic project)

       1.12 (for intermediate project)

       1.20 (for advanced project)

C = 2.5 (for basic project)

       2.5 (for intermediate project)

       2.5 (for advanced project)

d  = 0.38 (for basic project)

       0.35 (for intermediate project)

       0.32 (for advanced project)

PERT (Program Evaluation and Review Technique) Chart:


directed graph where nodes represent activities and begin dates (which gives end dates for respective previous activities), and links display relationships between activities.




Needs analysis:

Find out software needs.

Study current problematics, user needs, organisation needs and standards.

Produce software specifications.

Analysis models – dataflow model (DFD), composition model (semantic model), object model.



Translates functions/processes in needs specification into software components.

Details process description and that of process relationships.

Breaks up into structured modular form, usually written in pseudocode.

Involves considerations for user interface, database, input form, reports produced

Activities – architecture design, interface design, component design, data structure design, algorithm design.



Translates detailed design into program code.


Verification and validation:

Software checked and validated by running program using data sample and comparing with expected output.

Also check project planning, needs specification and system design.

Software quality assurance activity.

Static technique (paper scrutiny of work produced) and dynamic technique (involves software implementation).

Testing process – test of units, test of integration, system test, acceptance test (benchmark test; pilot test: alpha test – by user under supervision of developer, beta test – by user without developer).

Testing strategy – top-down testing, bottom-up testing, stress test (system resilience; failures should be ‘soft’).


Operation and maintenance:

Handover to user includes training, manuals, technical support, etc.

Maintenance when changes needed to software, e.g. newly-discovered errors, new user needs, change in hardware environment, to increase software capabilities.

Modify certain parts and test.



Paradigms for software development

(software process)


     waterfall model

phases as sequential activities – output of first phase “flows” to the scond phase, and so on

linear; progress easily monitored; document-driven (output of most phases in the form of documents)

problem w linear system - software development not linear: error found in later phases needed to be fed back to the earlier phases

                                       - a lot of processes need to be frozen because not time to handle them yet


     prototype model (evolutionary model)

handle needs which are incomplete: build prototype first

prototype helps to clarify real needs

two approaches – exploratory prototype, disposable prototype

exploratory model – when the needs of the software have been clarified in detail (e,g. artificial intelligence system): no confirmation done, software accepted if suitable

increment driven


     enhancement model

handover of version with increased functionality


     formal transformation model

formal specifications checked and confirmed formally, then it is transformed into the form of programs

supports evolusion of programs later changes do not require restart, and can be done consistently  


     spiral model

metamodel, since it contains other models


combine prototype model and waterfall model with risk analysis

spiral: … determine objective, constraint alternative kekangan evaluate alternative, recognise & solve risks develop and verify product plan next phase

each spiral can use different model according to what is best


     code and repair model

not really a model

original approach to software developement done by individuals and meant for limited crowd where they themselves can develop software


Software tools


Famous example: CASE (Computer-Aided Software Engineering)

Tools integration in I-CASE:




















back to synopsis of SMES3103