- Revision lecture
- Software process and software assurance
- Software project management
- Scrum project management
- Software verification
- Requirements engineering
Function point analysis
The vocabulary that comes from mainframe computing
- When it talks about input, output and logical files, it is talking about batch files that are run overnight that contain large amounts of data.
- File types
- index sequential
- random access
- It is a way of calculating the complexity of different computational processes.
- It is important to know the formulae for COCOMO and be able to insert values into the formulae given in a question
- the effort in person months
- development time in months
- abbreviations such as KDSI
- The three classes of project
- Won't be calculations - just verifying if given insertions are correct.
- Know the pros and cons of the processes
Software Assurance Definition
- Look at the allstate lecture slides.
- Be familiar at least with the names and broad nature of the types of security issues
Software project management
- Be able to complete a network analysis question. Refer to tutorial for more notes
- Look at metrics
- No calculations necessary in test. might be given figures to analyse. If given values are correct - if correct forumula is used.
- How a use case differs from a user story
- Use case diagrams, read in direction of the arrow - slide 79 - K extends N
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.
Software project management
Function point analysis (FPA)
The number of the following system components are considered:
- External inputs - eg. input files of transactions -
- External outputs - eg. output files of reports, messages -
- User interactions / enquiries - eg. menu selection, queries -
- Internal or logical files used by the system -
- External or interface files shared with other applications -
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):
- Data communications.
- Distributed functions.
- Heavily used configuration.
- Transaction rate.
- Online data entry.
- End-user efficiency.
- Online update.
- Complex processing.
- Installation ease.
- Operational ease.
- Multiple sites.
- Facilitate change.
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
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:
- Basic - this gives a rough estimate based on product attributes.
- Intermediate - modifies the basic estimate using project and process attributes.
- 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:
- Simple (or organic) - small teams; familiar environment; well-understood applications; no difficult non-functional requirements.
- 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.
- 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.
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:
Intermediate COCOMO takes the Basic COCOMO formula as its starting point.
a is equal to
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:
- Product attributes
- Required software reliability - RELY
- Database size - DATA
- Product complexity - CPLX
- Computer attributes
- Execution time constraints - TIME
- Storage constraints - STOR
- VM volatility - VIRT
- Computer turnaround time - TURN
- Personnel attributes
- Analyst capability - ACAP
- Programmer capability - PCAP
- Applications experience - AEXP
- VM experience - VEXP
- Programming language experience - LEXP
- 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.
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).
Work breakdown structure
The hierarchical representation of all the tasks in a project is called the work breakdown structure (WBS).
There are two major philosophies:
Activity-orientated decomposition ("Functional decomposition")
- Write the book, get it reviewed, do the suggested changes, get it published.
Result-orientated ("Object orientated decomposition")
- Chapter 1, chapter 2, chapter 3.
WBSs break the project down into tasks. Gantt charts.
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
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.
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
- Cyclomatic complexity - the complexity of program control
- Length of identifiers
- Depth of conditional nesting
- Supporting documentation - the Gunning Fog Index based on length of sentences and number of syllables.
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.
A scrum team is made up of a number of roles who take part in a number of ceremonies using a number of artifacts.
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:
- UI designers
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:
- What did you do yesterday?
- What will you do today?
- 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:
- They are quick to write compared to formalised requirements specifications.
- They are easier to modify and maintain when requirements change than more formal requirements specifications.
- They enable a quick response to changing requirements (between sprints)
- They encourage face to face communication.
- Minimal investment of time needed until really necessary.
- Allows projects to be broken up into sprintable chunks.
- They give a unit of work that developers can estimate.
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.
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
- Potential combinatorial explosion of test cases (valid and invalid data).
- Often not clear whether the selected test cases uncover a particular error.
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:
- Statement testing - test single statements.
- Loop testing.
- Path testing - execute every path.
- Branch testing - every outcome from every condition is tested.
Compared to black-box testing
- Potentially infinite number of paths to be tested.
- White-box testing often tests what is done, instead of what should be done.
- Cannot detect missing use cases.
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:
- Walkthroughs - four to six people examine the code and list perceived problems, then meet to discuss afterwards.
- 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.
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
- Identify actors - types of users who interact with the system
- Identify scenarios - concrete examples of how the system will be used.
- Identify use cases - Description of all possible behaviour in the system.
- Refine use cases - description of all possible behaviour in the system. These are abstractions unlike scenarios which are specific examples.
- Identify relationships among use cases - factor out common functionality and find dependencies.
- Identify non-functional requirements.
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.