Revision Notes

Revision lecture

Function point analysis

The vocabulary that comes from mainframe computing

Software processes

Software Assurance Definition

Software project management

Requirements engineering

Software process and software assurance

Software process models

Waterfall model

Separate and distinct phases of specification and development.

Problems with the waterfall model

Managers love water models as they have nice milestones, there is no need to look back as it is a linear system, and only one activity at a time is underway. It is also easy to check progress. However, most software development is iterative.

Systems development is a non-linear activity. It often requires revisiting and reworking previous tasks. Verification and validation testing come too late in the process in a waterfall model. This is very risky!

Evolutionary Strategies

The software is grown rather than built. Waterfall models are poor at managing risk. They assume that all requirements can be obtained upfront. Prototyping could provide the answer. They lower the risk since testing is done early in the process; the risk is spread out. There are two main types of prototyping:

Prototyping is particularly common in designing GUIs.

Disadvantages of this strategy include planning in advance what should be done. Managers don't like it for this reason. There is also no guarantee that the end product will be reached. The architecture could also get messy and need to be reworked later in the process.

Spiral model and incremental and iterative models

The specification and development are interleaved. There are various versions of the software and agile methods are used for the development of the software.

Spiral model

The spiral model is an iterative model with the following activities:

  1. Determine objective, alternatives, and constraints.
  2. Evaluate alternatives, identify and resolve risks. If a certain risk cannot be resolved satisfactorily, the project is terminated. A series of prototypes for the identified risks starting with the highest risk is developed. The aim here is to make sure that the highest risks are dealt with.
  3. Develop and verify next level product. This is done using a waterfall model (the incremental model may also be appropriate) for each next-level product development.
  4. Plan next phase of development. Evaluation of the current cycle is also done at this stage.

'Risk' is the possibility that some loss is incurred. Risk exposure = probability * loss. Risk analysis involves:

Iterative and incremental development (IID)

Advantages of IID include:

Other development methodologies

Formal transformation - A mathematical system model is formally transformed into an implementation.

Reuse-based developed - This is when the new system is assembled from existing components.

Software process maturity

A software development process is considered mature if the development activities are well defined and the management has some control over the quality, budget, and schedule of the project. Process maturity is described as a set of maturity levels and the associated measurements (metrics) to manage the process. There is an assumption that with increasing maturity, the risk of project failure decreases.

SEI capability maturity level

Defined by the Software Engineering Institute.


  1. Initial level - also called ad hoc or chaotic.
  2. Repeatable level - the process depends on individuals (or "champions").
  3. Defined level - the process is institutionalised (sanctioned by management).
  4. Managed level - activities are measured and provide feedback for resource allocation (the process itself does not change).
  5. Optimising level - the process allows feedback of information to change the process itself.


CMM level one - initial

This is an ad hoc approach to software development activities. There is no problem statement or requirement specification. Inputs and outputs are not defined in advanced. An output is expected, but nobody knows how to get there in a deterministic fashion. Similar projects may vary widely in productivity.

CMM level two - repeatable

Inputs and outputs are defined, where an input is a problem statement or requirements specification and an output is source code. The process itself, however, is a black box (activities within the process are not known).

CMM level three - defined

A defined software process on all projects. Personnel is assigned to improve the process, for example, a QA team. Activities of the software development process are well defined with clear entry and exit conditions. Intermediate products of development are well defined and visible. Peer reviews are undertaken at this level.

CMM level four - managed

This is a quantitative form of process management. Productivity and quality metrics are defined and constantly measured. There is quality management, and the organisation has quality goals and monitors these. Information from early project activities is used to set priorities for later project activities (this is called intra-project feedback). This feedback determines how and in what order resources are deployed. The effects of changes in one activity can be tracked in the others.

CMM level five - optimising

Measures from software development activities are used to change and improve the current process. This change can affect both the organisation and the project. The organisation might change its management scheme, and a project may changes its process model before completion of the project.

Software assurance

Software assurance is defined as a level of confidence that software is free from errors, vulnerabilities and functions as intended.

To achieve a high level of software assurance, activities and processes are built into the software development lifecycle (SDLC) that aim to build a level of trust into software and systems.

Properties of trustworthy software:

Measures to design, build and test for these properties should be incorporated into the entire SDLC.

Security objectives

The fundamental security objectives of any system are:

These objectives apply in the context of processing, storage, and communication of data and the provision of services. Other important security objectives include:

OWASP top 10 - 2017

  1. Injection.
  2. Broken authentication.
  3. Sensitive data exposure.
  4. XML external entities.
  5. Broken access control.
  6. Security misconfiguration.
  7. Cross site scripting.
  8. Insecure deserialisation.
  9. Using components with known vulnerabilities.
  10. Insufficient logging and monitoring.

Software project management

Function point analysis (FPA)

The number of the following system components are considered:

In each case, depending on the number of field types that are associated with each component, and the variety of file types that these elements refer to, these components are rated as simple, average or complex.

A weight is associated with each of the ratings for each component type. The number of external inputs is multiplied by the selected weighting for that system component - likewise for external outputs and the other system components. The weighted totals are added to give the Unadjusted Function Points (UFP) -

UFP = Σ Input(wi) + Σ Output(wo) + Σ Enquiry(we) + Σ Logical File(wl) + Σ Interface File(wif)

The UFP value is then adjusted to take account of the type of application. This adjustment is made by multiplying the UFP value by a Technical Complexity Factor (TCF). As preparation for calculating TCF, 14 general system characteristics (GSCs) are scored for degree of influence from zero (no influence) to five (strong influence):

TCF is then calculated as follows: TCF = 0.65 + 0.01 * DI where DI is the total degree of influence from the 14 scored characteristics.

The top score from the GSCs is 14 * 5 = 70. A normal or moderate score (where collectively the GSCs are midway between 'no influence' and 'strong influence') would be 14 * 2.5 = 35.

A case needs to be made where the GSCs total 35 and the technical complexity factor is one, and therefore has no effect as a multiplier on the UFP. One way to do this is to multiply 35 by 0.01 and then add 0.65. That is the basis of the Value adjusted formula (VAF).

Difficulties with function points

Function points, and particularly, the scores given to the GSCs are very subjective. They cannot be counted automatically and depend on the assessment of an analyst. There are only three complexity levels for weighting the functionality of the main system components. The approach has to be calibrated or adjusted for different programming tasks and environments. Ultimately, it will come down to experience that will determine how well the approach is working. 

COCOMO - algorithmic cost modelling

Cost is estimated as a mathematical function of project, product and process attributes. The function is derived from a study of historial costing data. The most commonly used product attribute for cost estimation is lines of code (LOC). One widely used costing model is the Constructive Cost Model (COCOMO).

COCOMO exists in three forms:

  1. Basic - this gives a rough estimate based on product attributes.
  2. Intermediate - modifies the basic estimate using project and process attributes.
  3. Advanced - estimates project phases and parts separately.

The class of project affects the multipliers and exponents used in basic COCOMO. There are three recognised classes of project:

  1. Simple (or organic) - small teams; familiar environment; well-understood applications; no difficult non-functional requirements.
  2. Moderate (or semi-detached) - project team may have a mix of experience; system may have more significant non-functional constraints; organisation may have less familiarity with the application.
  3. Embedded - hardware / software systems; tight constraints; unusual for team to have deep application experience.

Formulae for basic COCOMO
E = a * KDSIb
D = 2.5 * Ec
E - Effort in person-months.
Values for ab and c are based on project class and historical data.
D - Development time in months.
KDSI - Thousands of delivered source instructions.

The multipliers and exponents for basic COCOMO's formulae change according to the class of the project:

Project Class a b c
Organic 2.4 1.05 0.38
Semi-detached 3.0 1.12 0.35
Embedded 3.6 1.30


Intermediate COCOMO

Intermediate COCOMO takes the Basic COCOMO formula as its starting point. a is equal to 3.2, 3.0 and 2.8 for organic, semi-detached and embedded projects respectively. Additionally, intermediate COCOMO identifies personnel, product, computer and project attributes which affect cost. The basic cost is adjusted by attribute multipliers:

  1. Product attributes
    • Required software reliability - RELY
    • Database size - DATA
    • Product complexity - CPLX
  2. Computer attributes
    • Execution time constraints - TIME
    • Storage constraints - STOR
    • VM volatility - VIRT
    • Computer turnaround time - TURN
  3. Personnel attributes
    • Analyst capability - ACAP
    • Programmer capability - PCAP
    • Applications experience - AEXP
    • VM experience - VEXP
    • Programming language experience - LEXP
  4. Project attributes
    • Modern programming practices - MODP
    • Software tools - TOOL
    • Required development schedule - SCED

Some attributes may be more or less significant between different projects and organisations.

Reducing multipliers

A faster CPU can be used along with more memory to reduce the TIME and STOR attribute multipliers. Some software tools can be bought to reduce the TIME and TOOL multipliers (although more VM experience would be needed as a result).

Project scheduling

Work breakdown structure

The hierarchical representation of all the tasks in a project is called the work breakdown structure (WBS).

Creating WBSs

There are two major philosophies:

WBSs break the project down into tasks. Gantt charts.

Network analysis

Lines between blocks indicate dependence on the previous task. Don't forget to draw the critical path. The critical path is the path along the project where there is no spare time (ie. the float is zero throughout).


ES = Earliest start
D = Duration
EF = Earliest finish
LS = Latest start
F = Float
LF = Latest finish

Quality Metrics

Defect removal efficiency

DRE = E / (E + D) where E = number of errors before delivery; D = number of defects after delivery. This is a measure of how good the team is at quality assurance. The DRE should ideally be 1. (ie. all errors detected and resolved, and there are no reported defects after delivery).

Defects per kLOC

C = number defects / kLOC where defects are a lack of conformance to a requirement. This is a measure of correctness.


Integrity is a system's ability to withstand attacks on its security. I = Σ[1 - threat * (1 - security)] where threat is the probability than an attack of a particular type will occur at a given time and security is the probability that an attack of that same type will get repelled.

Design complexity

Represented with a fan-in and fan-out structural chart. A high fan-in (number of calling functions) means there is a high coupling. A high number of fan-out (number of calls) means there is a high coupling complexity. The length is any measure of programme size such as lines of code.

Complexity = Length * (fan-in * fan-out)2

Other metrics

Scrum project management

Scrum is an agile process that focuses on delivering the highest business value in the shortest amount of time. It allows for the rapid and repeated inspection of actual working software every two weeks to a month. The business sets the priorities and teams self-organise to determine the best way to deliver the highest priority features. Every two weeks to a month, anyone can see real working software and decide to release it as is, or continue to enhance it for another sprint.


Scrum projects make progress in a series of iterations called sprints. The typical duration of a sprint is two to four weeks, or a calendar month at most. A constant duration leads to a better rhythm. The project is designed, coded and tested during the sprint.

No changes are allowed during a sprint. The sprint duration should be planned around how long change can be kept out.

Scrum framework

A scrum team is made up of a number of roles who take part in a number of ceremonies using a number of artifacts.


Product owner

The product owner defines the features of the product. They decide the release date and the content released on that date. They are responsible for the profitability of the product by determining the potential return on investment (ROI) for each user story.

They prioritise features according to market value at the time, and adjust these features and their priorities every sprint as needed. They accept or reject work results, and ultimately decide if the iteration made during a sprint will be released or not.

The scrum master

The scrum master has authority over the entire process. They are responsible for enacting scrum values and practices. They remove hindrances.

They also ensure that the team is fully functional and productive. They enable close cooperation across all roles and functions within the team. They also shield the team from external interference when need be.

The scrum team

A team is made up of three to nine people. This does not include the product owner or the scrum master unless they are actively developing. Teams are cross functional. They include:

All skills are used in some form in the duration of a sprint. Members of the team should be working full time and working together all of the time. Exceptions can be made to this rule where specific skills are in short supply; in which case, they may be shared across a number of teams. (for example, a DB administrator).

Membership should change only between sprints according to the next sprint goal. This usually will have a slight impact on productivity as members get used to their new teams.


Ceremonies include the daily scrum, sprint planning meeting, sprint review, sprint retrospective, and others.

The daily scrum

A stand up meeting that happens daily at a set time, and for a set duration. These meetings are not for problem solving. Everyone is invited to a daily scrum, but only the scrum team must attend. Only the scrum team, scrum master and product owner can talk at the meetings.

Everyone answers three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. Is there anything in your way?

As well as informing the scrum master of your status, these are also commitments made in front of your peers in person. Social commitment is a very strong work motivation.


Product backlog and user stories

Backlog item naming convention
As a <actor> I can <action> so that <goal>.
As a <role> I can <feature> so that <reason>.
eg. As a guest I can make a reservation so that I stay at a hotel.
As a registered user I can log in so that I can see my profile page.

Product backlogs are given an estimate, which is usually given in story points.

A user story is a form of agile requirements specification.

A concise, written description of a piece of functionality that will be valuable to a user (or owner) of the software.

They define what will be built in the project, and are formulated in one or two sentences in everyday language. The language used should be understood by both developers and customers/product owners. They are typically written by the customers. The work required to implement the stories is estimated by the developers, and then priorities by the customer/product owners after the estimation is carried out.

Benefits of user stories include:

Software verification

Black-box testing

The programme test cases in black box testing are based on the system specification. Inputs from the test data may reveal anomalous outputs (ie. defects). Test planning can begin early in the software development process. The main problem with black box testing in the selection of inputs.

Equivalence partitioning

This when the system inputs and outputs are partitioned into equivalence sets. If an input should be between four and ten, then choose a number less than four, a numbr between four and ten and a number greater than ten.

Choose test cases at the boundaries of these sets.

Compared to white-box testing

White-box testing

Sometimes this is called structural testing or glass box testing. It is the derivatiion of test cases according to the programme structure. The objective is to exercise all programme statements (not all path combinations). There are four types of white-box testing:

  1. Statement testing - test single statements.
  2. Loop testing.
  3. Path testing - execute every path.
  4. Branch testing - every outcome from every condition is tested.

Compared to black-box testing

Static verification

This is verifying the conformance of a software system and its specification without executing the code. It involves analysis of source text by humans or software on any documents produced as part of the software process. It discovers errors early in the software process. There are two main techniques for static verification:

  1. Walkthroughs - four to six people examine the code and list perceived problems, then meet to discuss afterwards.
  2. Programme inspections - a more formal approach using checklists.

This is usually more cost effective than testing for defect detection at the unit and module level. Over 60% of programme errors can be detected in software inspections.

Requirements engineering

Requirement elicitation


Interviews tend to give the best information. However, they are more expensive than other means.


They are good if many people are inolved. Especially if they are dispersed across a company. These tend to have poor or false responses though.


These are accurate if they are done well. Like with interviews, it is expensive.

Join application design

These are typically workshops held with uses to get a consensus of the requiremets. Meeting may mean that clients are away from their workspaces.

Typical elicitation process

  1. Identify actors - types of users who interact with the system
  2. Identify scenarios - concrete examples of how the system will be used.
  3. Identify use cases - Description of all possible behaviour in the system.
  4. Refine use cases - description of all possible behaviour in the system. These are abstractions unlike scenarios which are specific examples.
  5. Identify relationships among use cases - factor out common functionality and find dependencies.
  6. Identify non-functional requirements.

Use cases

A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result of value to an actor.

Graphically, a use case is rendered as an ellipse. Typically an actor represents a role that a human, a hardware device, or even another software system plays within a system.

eg. In order to delete an element in a graphics package, it must always be selected.

eg. When an element is selected, the option to move it is there as well.

Read <<extend>> and <<include>> relationships in the direction of the arrow: move extends select, delete includes select.

The generalisation relationship between use cases is represented by a solid line with a white arrow head. The more general concept is placed at the head of white arrow head. Generalisation can apply to use cases, actors and classes. Actors connect to use cases by means of a simple line that crosses the system boundary.