Software process and software assurance
Software process models
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.
- During design, problems with requirements are identified.
- During coding, design and requirement problems are found.
- During testing, coding, design and requirement errors are found.
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!
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:
- Throwaway prototyping - building a prototype just to test a hypothesis. (In extreme programming, this is known as a spike). Then discard the prototype and build the real product.
- Evolutionary prototyping - building a prototype as a demonstration, then use it as a base to build the full functionality on top.
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.
The spiral model is an iterative model with the following activities:
- Determine objective, alternatives, and constraints.
- 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.
- 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.
- 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:
- Risk identification
- Risk assessment
- Risk prioritisation - ranking
- Risk resolution - accept it OR reduce it OR avoid it
- Risk monitoring - where a risk is accepted, watching out for possible triggers that might cause the risk.
Iterative and incremental development (IID)
Advantages of IID include:
- Early feedback can be received from the customer throughout the development process.
- A better time to market for high priority.
- It is easier to react to change.
- Better estimates can be made.
- There is a lower risk involved (than with waterfall for example).
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.
- Initial level - also called ad hoc or chaotic.
- Repeatable level - the process depends on individuals (or "champions").
- Defined level - the process is institutionalised (sanctioned by management).
- Managed level - activities are measured and provide feedback for resource allocation (the process itself does not change).
- 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).
- No intermediate products are visible.
- No intermediate deliverables.
- The project plan is used and tracked.
- All deliverable and processes reviewed (This is a role for QA).
- Configurations management exists.
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 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:
- Availability - deliver services when requested.
- Reliability - delivery services as specified.
- Resilience - ability to recover.
- Security - protected against accidental or deliberate attacks.
- Safety - operate without harmful states.
Measures to design, build and test for these properties should be incorporated into the entire SDLC.
The fundamental security objectives of any system are:
- Confidentiality - can only read if authorised to do so.
- Integrity - can only modify if authorised to do so.
- Availability - can only access if authorised to do so.
These objectives apply in the context of processing, storage, and communication of data and the provision of services. Other important security objectives include:
- Authorisation - what a user is allowed to do once they have authenticated with a system.
- Non-repudiation - ensuring a party cannot deny having taken an action.
- Privacy - ability to control personal information.
- Audit - enables a trace of activity allowing accountability.
OWASP top 10 - 2017
- Broken authentication.
- Sensitive data exposure.
- XML external entities.
- Broken access control.
- Security misconfiguration.
- Cross site scripting.
- Insecure deserialisation.
- Using components with known vulnerabilities.
- Insufficient logging and monitoring.