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.
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: 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
♣ 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.
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:
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.
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.
♠ 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
♠ 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
Famous example: CASE (Computer-Aided Software Engineering)
Tools integration in I-CASE: