What does project governance ensure?
- It ensures that all external and internal roles and responsibilities are documented; in other words ownership of projects and sub-roles is allocated.
- It provides a decision framework, e.g. the programme board can only make certain decisions but other, less material decisions can be delegated to sponsors, suppliers, project managers and so on. Therefore if decisions need to be made, then clear guidance is provided on who can make these decisions.
- It provides a framework for reporting and tracking, e.g. regular weekly reports, monthly programme board meetings, cost reports, etc.
- It allows organisations to assess the impact of various projects on other projects e.g. if Project X is delayed, how does that impact Projects Y and Z.
What is the order of the seven stages of testing ?
- Unit testing
- Integration testing
- Functional testing
- System testing
- Volume testing
- System integration testing
- UAT
What is an SRO?
The SRO is the individual responsible for ensuring that the project of programme of change meets its objectives and delivers the projected benefits. They should be the owner of the overall business change that is being supported by the project. They SRO should ensure that the change maintains its business focus and has clear authority and that the context, including risks is actively managed. This individual must be senior and must take personal responsibility for successful delivery of the project. They should be recognised as the owner throughout the organisation.
An individual’s responsibilities as an SRO should be explicitly included in their personal objectives and the individual should remain in place through the project or programme, or alter only when a distinct phase of benefit delivery has been completed.
The SRO should be prepared to make decisions, and should be proactive in providing leadership and direction throughout the life of the project of programme. They should be responsible for ensuring that the organisation can fully exploit the outcome of the change such that the benefits are delivered as a result of that outcome.
The SRO works with programme managers and project managers to develop and implement procedures and practises for project planning and control, and where applicable, for software development. Some of the common approaches to these issues are discussed below.
What is SDLC?
The Software Development Life Cycle (SDLC) is standardised process of developing information systems or applications through the completion of defined steps or phases. Synonyms include:
1. System Development Life Cycle
2. Systems Implementation Life Cycle, and
3. Software Implementation Life Cycle (SILC)
The SDLC recognises the following factors:
1. The further the project is from completion, the higher the risk and uncertainty. Risks and doubt decrease as the project moves closer to fulfilling the project vision.
2. Cost and resource requirements are lower at the beginning of a project, but grow as the project progresses. Once the project moves into the final closing process, cost and resource requirements again taper off dramatically. It is important for a project manager to be able to assess how much resource is actively working on their project (in terms of time or cost) so that this risk can be monitored.
3. Changes are easier and more likely at the early phases of the project life cycle than at the completion. Changes at the beginning of the project generally cost less and have lower risk than changes at the end of the project. Therefore, stakeholders need to be happy with the project deliverables from the early phases otherwise there is a risk that in the final phases of the project life cycle additional costs may need to be incurred.
What are the stages of the standard SDLC?
- Terms of Reference – the management decides what capabilities and objectives it wishes the new system to incorporate
- Feasibility Study – this asks whether the management’s concept of its desired new system is actually an achievable, realistic goal – in terms of money, time and end result. Often, it may be decided simply to update an existing system rather to replace on completely
- Fact-finding and recording – how is the current system used? Often questionnaires are used here, but also just monitoring (watching) the staff to see how they work is better, as people will often be reluctant to be entirely honest, through embarrassment, if merely asked about the parts of the existing system they have trouble with and find difficult
- Analysis – free from any cost or unrealistic constraints, this stage lets minds run wild as ‘wonder systems can be thought up’, though all must incorporate everything asked for by the management in the terms of reference stage
- Design – designers will produce one or more ‘models’ of what they see a system eventually looking like with ideas from the analysis section either used or discarded. A document will be produced with a description of the system but nothing is specific, e.g. they might say ‘touchscreen’ or ‘GUI operating system’ but not mention any specific brands
- System specification – having generically decided on which software package to use and which hardware to incorporate, the plan now has to be very specific, choosing exact models, brands and suppliers for each software application and hardware device
- Implementation and Review – set up and install the new system (including writing any bespoke code required), train staff to use it, then monitor how it operates for initialproblems and then regularly maintain thereafter. During this stage, any old system that was
in use will usually be discarded once the new one has proved it is reliable and usable - Use – obviously the system needs to be actually used by somebody, otherwise the above
process would be completely useless - Close – the last steps in a systems’ life cycle is its end, which is more often forgotten when
you design the system. The system can be closed, it can be migrated to another (more modern platform), or its data can be migrated into a replacing system
What are some of the other names for the basic waterfall model?
The classic life cycle model or the linear sequence model.
Step 1: Requirements Step 2: Design
Step 3: Implementation Step 4: Test
What is the implied waterfall model and what is another name for it?
Where there is a problem with the previous phase of delivery the solution is returned to the previous phase and rework occurs before the waterfall continues. This is sometimes known as the ‘implied waterfall model’ or ‘waterfall model with backflow’.
What is the fountain model?
The fountain model recognises that there are opportunities for some phases of the life cycle to occur at the same time or to overlap. Overlap occurs between adjacent phases, and change control processes need to be effective to ensure that work is not undertaken on incorrect assumptions.
1. Analysis
2. Requirement Specification
3. Design
4. Coding
5. Testing and Integration
6. Operation
7. Maintenance / Evolution
What is the difference between an increment and a iteration?
A typical difference is that the output from an increment is released to users whereas the output from an iteration is examined for further modification before release.
What two methodologies does the spiral model build on?
This model of development combines the features of the prototyping model and the waterfall model.
Describe the spiral model?
- The new system requirements are defined in as much detail as possible. This usually involves interviewing a user or users representing all the external or internal users and other aspects of the existing system.
- A preliminary design is created for the new system
- A first prototype of the new system is constructed from the preliminary design, this is
usually scaled - down system, and represents an approximation of the characteristics of the
final product. - A second prototype is evolved by a fourfold procedure:
a. Evaluating the first prototype in terms of its strengths, weaknesses and risks;
b. Defining the requirements of the second prototype;
c. Planning and designing the second prototype;
d. Constructing and testing the second prototype - At the customer’s option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development costs overruns, operating cost miscalculations, or any other factor that could, in the customer’s judgement, result in a less-than satisfactory final product.
- The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
- The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
- The final system is constructed based on the refined prototype
- The final system is thoroughly evaluation and tested. Routine maintenance is carried out on
a continuing basis to prevent large-scale failures and to minimise downtime.
What does good PRINCE 2 practice encourage?
- A controlled and organised start, middle and end
- Regular reviews of progress against plan and of the business case
- Built-in decision points
- Management control of deviations from plan
- The involvement of management and stakeholders at the right time and place of the
project life cycle - Good communication channels between stakeholders
Describe the PRINCE 2 process stages.
- Starting up a project (SU) – in this process the project team is appointed and a project brief (describing in outline, what the project is attempting to achieve and the business justification for doing it) is prepared. In addition, the overall approach to be taken is decided and the next stage of the project is planned. As part of this phase, the project board, project sponsor and project manager are appointed. The project board is usually chaired by the project sponsor. This is normally the senior executive who instigated the change and is responsible to the business for the success of the project. Other members of the project board will include executives from the various sections of the firm that will either benefit from the project or have a role in delivering it. The project manager is also a member of the project board. The project manager is the individual responsible for delivering the project. Once this work is done the project board is asked to authorise the next stage, i.e. that of initiating the project.
- Planning (PL) – PRINCE2 advocates product-based planning, which means that one of the first tasks when planning is to identify and analyse products. Once the activities required to create these products are identified, it is possible to estimate the effort required for each and then schedule activities into a plan.
- Initiating a Project (IP) – this process builds on the work of the start-up (SU) activity and the project brief is augmented to form a business case, i.e. the non-technical reason for the project. The logic of the business case is that whenever resources, such as money or effort, are consumed they should be in support of the business. An example could be that a software upgrade might improve system performance, but the business case is that better performance would improve customer satisfaction.
- Directing a Project (DP) – these sub-processes dictate how the project board should control the overall project. It also specifies the way in which the board can give ad hoc direction to a project and the way in which a project should be closed down.
- Controlling a Stage (CS) - PRINCE2 suggests that projects should be broken down into stages and these sub-processes dictate how each individual stage should be controlled. Most fundamentally, this includes the way in which work packages (subset of a project that can be assigned to a specific party for execution) are authorised. It also specifies the way in which progress should be monitored and how the highlights of the progress should be reported to the project board.
- Managing product delivery (MP) – this process specifies the way in which a work package should be accepted, executed and delivered.
- Managing stage boundaries (SB) – this process dictates what should be done towards the end of a stage. The fundamental principle of this stage is to ensure that, at the end of each stage the project stays focused on delivering business benefit. Most obviously, the next stage should be planned and the overall project plan risk log and business case amended as necessary. The process also covers that should be done for a stage that has gone outside its tolerance levels. Finally, the process dictates how the end of the stage should
be reported. - Closing a project (CP) – this process covers the things that should be done at the end of a
project. The project should be formally de-commissioned (and resources freed up for allocation to other activities), follow-on actions should be identified and the project itself should be formally evaluated.
What are the two major parts of PMBOK?
PMBOK is divided in two major parts; project initiation and exam essentials. The project initiation part focuses on developing and executing a project plan and creating, protecting and fulfilling a project scope.
What is the structure of PMBOK?
The guide recognises 44 processes that fall into five basic process groups and nine knowledge areas that are typical of most projects.
What are the 5 process groups of PMBOK?
The five process groups are:
1. Initiating
2. Planning
3. Executing
4. Controlling and monitoring, and
5. Closing
What are the 9 knowledge areas of PMBOK?
The nine knowledge areas are:
1. Project integration management
2. Project scope management
3. Project time management
4. Project cost management
5. Project quality management
6. Project human resource management
7. Project communications management
8. Project risk management
9. Project procurement management
What is ISO?
The International Organisation for Standardization (ISO) was established in 1947 to develop common International standards in many areas. Its members come from over 120 national standards bodies which, through associated accreditation and certification bodies, act as audit organisations in recognising which companies have gained applicable ISO standards. ISO’s purpose is to facilitate international trade by providing a single set of standards that people everywhere can recognise and respect. Within the UK there are also some mature British standards that have been developed in parallel, and often adopted by the ISO.
How often should an ISO standards certificate be renewed?
An ISO certificate must be renewed at regular intervals following a review by an independent standards auditor, as recommended by the certification body, usually every three years.
What is the purpose of testing?
The purpose of testing is therefore, to gain a level of confidence in the software so that the organisation is confident that the software has an acceptable defect rate, where defects do exit they are documented and there are adequate workarounds available to the users
What are the software testing axioms?
- It is impossible to test a program completely
- Software testing is a risk based exercise
- Testing cannot show that bugs don’t exist
- The more bugs you find, the more bugs there are
- Not all the bugs you find will be fixed
- Product specifications are never final
- If you find a problem that occurs once and you can’t repeat it then you can’t fix it
Name the test stages
- Unit testing – tests the minimal software component or module, each unit of the software is tested to verify that the detailed design for the unit has been correctly implemented
- Integration testing – exposes defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system
- Functional testing – tests at any level for proper functionality as defined in the specification
- System testing –tests a completely integrated system to verify that it meets its
requirements - Volume testing or load testing – tests a software application for a certain data volume. this
may be expressed in a number of ways, such as the size of the database, the number of transactions to be processed for a given time period, the length of time that the user has to wait for the result of an enquiry, the length of time that an overnight process should take to compete. One form of volume testing that is becoming more common is breakpoint testing,
e. , piling more and more load onto the system to find out when it actually becomes
unusable. - System integration testing – verifies that a system is integrated to any external or third
party systems defined in the system requirements - User acceptance testing – conducted by the end user, customer or client to validate
whether or not to accept the product. Acceptance testing may be performed as part of the handoff process between any two phases of development
a. Alpha testing is simulated or actual operation testing by potential users or an independent test team to the developer’s site. Alpha testing is often employed for off the shelf software as a form of internal acceptance testing before the software goes to beta testing
b. Beta testing comes after alpha testing. Versions of the software, known as beta versions are released to a limited audience outside the company, the software is released to groups of people, so that further testing can ensure the product has few faults. - Penetration testing – testing the security elements of a system by simulating an data attack from a malicious source
What is regression testing and where can it be applied?
After modifying software, either for a change in functionality or to fix defects, a regression test re- runs previously successful tests on the modified software to ensure that the modifications haven’t unintentionally caused a regression of previous functionality. Regression testing can be performed at any or all of the above test levels.
Name the common test techniques
?
Software may be tested by using any or all of the following techniques:
1. Code walkthrough – a manual testing technique where program logic is traced manually using a small set of test cases to analyse the programmers logic and assumptions
2. White box testing – in white box testing the tester has access to the source code and can write tests specific to the area of change
3. Black box, concrete box or functional testing – in black box testing the tester only accesses the software through the same interfaces that the customer or user would, through automation or similar interfaces to confirm the functional specification of the program
4. Grey box testing – a technique that uses a combination of black box and white box testing. It isn’t black box testing, because the tester does know some of the internal workings of the software under test. In grey box testing, the tester applies a limited number of test cases to the internal working of the software under test. In the remaining part of the grey box testing, one takes a black box approach in applying inputs to the software under test and observing the outputs.
5. Smoke, sanity or skim testing – this is a cursory examination of all of the basic components of software system without reference to the internal workings to ensure that they hang together. Typically, smoke testing is used to verify a software build. The term originatesfrom the electronics industry wither the circuits are laid out and power is applied, if anything
start smoking, there is a problem
6. Agile testing - agile software development adheres to a test-driven software development
model where the unit tests are written first and fails initially until the code is written. The test harness is continuously updated as new failure conditions are discovered and they are integrated with any regression tests that have been developed. The stages of an agile development cycle are as follows:
a. Write the test
b. Write the code
c. Run the automated tests
d. Refactor
e. Repeat
7. Handshake or rattle test – this test aims to prove that it is possible to send and receive communications between two or more systems. Such a test does not prove that the two or more systems can understand one another just that messages do not get lost en route.
