Writing terminologies and definitions:
PMI defined project as: “A temporary endeavor undertaken to create a unique product or service”
Stakeholders: are people who have stake or interest in the project.
Project Management:Is a carefully planned and organized effort to accomplish a successful project
Program management :‘a group of projects that are managed in a co-ordinated way to gain benefits that would not be possible were the projects to be managed independently’ Ferns
The programme brief – equivalent of a feasibility study: emphasis on costs and benefits
The vision statement – explains the new capability that the organization will have
The blueprint – explains the changes to be made to obtain the new capability
The tangible products are those at the bottom of the PBS that are not further subdivided.
Milestones or key activities:Which represent the completion of important stages of the project
In-house: means that the developers and the users of the software are in the same organization.
Suppliers:means that the developers and the users of the software are in the different organization.
Prototype is a working model of one or more aspects of the projected system.
Parkinson’s Law: ‘Work expands to fill the time available’
Brook’s Law: putting more people on a late job makes it later
Zeroth law of reliability: if a system doesn't have to be reliable it
can meet any other objective
risk: ‘an uncertain event or condition that, if it occurs has a positive or negative effect on a project’s objectives’.
Project Risks: are risks that could prevent the achievement of the objectives given to the project manager and the project team.
Risk Mitigation: is the action taken to ensure that the impact of the risk is reduced when it occurs.
Contingency plan is a planned action to be carried out if a risk materializes (occurs).
Software reliability is defined as: The ability of a system or component to perform its required functions under stated conditions for a specified period of time.
Availability: the percentage of a particular time interval that a system is usable.
Multiple choice, answer questions and true-false :
Developing a new IT application in-house:
Time is needed to develop the software
Would often require the recruitment of new technical staff to do the job
Usually, the new staff won’t be needed after the project is completed
Sometimes due to the novelty of the project there may be lack of executives to lead the effort
Contracting the project out to an external IT development company (outsourcing):
Time is needed to develop the software
The conducting company will have technical and project expertise not readily available to the client
The client would still do management effort to establish and manage the contracts
Some advantages of off-the-shelf (OTS) software
Cheaper as supplier can spread development costs over a large number of customers
Software already exists
Can be trialled by potential customer
No delay while software being developed
Where there have been existing users, bugs are likely to have been found and eradicated
Some possible disadvantages of off-the-shelf
Customer will have same application as everyone else: no competitive advantage, but competitive advantage may come from the way application is used
Customer may need to change the way they work in order to fit in with OTS application
Customer does not own the code and cannot change it
Danger of over-reliance on a single supplier
Product uncertainty:
How well are the requirements understood.
The users themselves could be uncertain about what the system is to do.
Process uncertainty:
For the project under consideration, the organization will use an approach or an application building-tool that it never used before.
Resource uncertainty:
The main area of resource uncertainty is the availability of the staff with the right ability and experience.
Agile methods
Emphasis on speed of delivery rather than documentation
RAD Rapid application development emphasized use of quickly developed prototypes
JAD Joint application development. Requirements are identified and agreed in intensive workshops with users
Software Process Models
Waterfall Model.
V-process Model.
Spiral Model.
Software prototyping.
Phased Development Model.
incremental development model.
iterative development model.
Waterfall
Classical model of system development.
Called one-shot or once-through model.
limited scope of iteration. Is this a strength or a limitation??
This is a strength for the WF-model.
Because it is suitable for some projects especially for large projects, we want to avoid reworking tasks that are thought to be completed.
Reworking tasks could result in late delivery.
Suitable for systems with well defined requirements.
Not suitable for systems of high uncertainty
V-process Model
An extension of the waterfall model.
V-process model expands the activity box “testing” in the waterfall model.
Each step has a matching validation process.
Validation process can cause a Loop back to the corresponding stage and reworking the following steps in case of discrepancy.
Spiral Model
A greater level of detail is considered at each stage of the project.
Represented as a loop or a spiral where the system is considered in more detail.
This means greater confidence about the probability of success.
Each sweep is terminated by an evaluation before the next iteration is embarked upon.
Prototyping Model
Benefits of Prototyping
Learning by doing.
Improved communication.
Improved user involvement.
Clarification of partially-known requirements.
Demonstration of the consistency and completeness of a specification
Reduced need for documentation.
Reduced maintenance costs.
Feature constraint.
Incremental Model
Break the system into small components.
Implement and deliver small components in sequence.
Every delivered component provides extra functionality to the user.
Iterative Model
Deliver full system in the beginning.
Enhance existing functionality in new releases.
• Actors :refers to all people involved in the development of the application.
• Risk:
A high staff turnover, leads to expertise of value to the project being lost.
• Technology: encompasses both the technology:
– Used to implement the application and
– That embedded in the delivered products.
• Risk:
– Relating to the appropriateness of the technology and
– The possible faults in it.
• Structure: describes the management structures and systems, including those affecting planning and control.
• Risk:
Responsibility for managing the users involvement at the implementation stage might not be clearly allocated.
• Tasks: relates to the work planned.
• Risk:
The complexity of work might lead to delays because of the additional time require integrate the large number of components.
Planning for risk includes these steps:
1. Risk identification.
2. Risk analysis and prioritization.
3. Risk planning.
4. Risk monitoring.
The two main approaches to identify risk are:
– The use of checklists.
– Brainstorming.
The choices for dealing with risks are:
– Risk acceptance.
– Risk avoidance.
– Risk reduction and mitigation.
– Risk transfer.
Risk Acceptance:
– This is deciding to do nothing about the risk. This means you will accept its consequences. Why?
– In order to concentrate on the more likely or damaging risks.
– The damage that those risks could cause would be less than the costs needed to act towards reducing their probability of occurrence.
Risk Avoidance:
– Some activities are so prone to accident that it is best to avoid them altogether.
– Example to avoid all the problems associated with developing software solutions from scratch, a solution could be to:
Buy an off-the-shelf product.
Risk Reduction and Mitigation:
– Risk Reduction: attempts to reduce the likelihood of the risk occurring.
e.g. consider the following risk: developers leaving a company in the middle of a project for a better paid job.
In order to reduce the probability of such a risk occurring: the developers could be promised to be paid generous bonuses on successful completion of the project.
– Risk Mitigation: is the action taken to ensure that the impact of the risk is reduced when it occurs.
Taking regular backups of data storage, is it a risk mitigation measure or a risk reduction measure?
Since it would reduce the impact of data corruption not its likelihood of happening, in this sense it is a data mitigation measure.
Risk Transfer:
– In this case the risk is transferred to another person or organization.
– Example: a software development task is outsourced for a fixed fee.
– Another example is when you buy insurance( e.g. for a car).
Creating and maintaining the risk register:
• A risk register: it contains the findings of project planners of what appear to be the most threatening risks to the project.
• After work starts on a project more risks will appear and will be added to the register.
• Risk registers are reviewed and updated regularly.
Resource allocation may lead to:
– Revising a stage.
– Revising project comple2on dates.
– Narrowing activity time spans.
Resources can be:
– Item required for the execu2on of the project.
– Person required for the execu2on of the project.
Some resources will be required for a specific period and some will be required for the whole dura2on of the project.
Resources will fall into one of seven categories:
- Labour (the project manager, system analysts, software developers……).
- Equipment: used items (workstations, office equipment, desks, chairs…).
- Materials (Consumed items – floppy disks, paper, printer ink…..).
- Space : for additional staff recruited or contracted (Rooms, Cubicles).
- Services (Telecommunication services, Cleaning services………..).
- Time (The most rigid item of all).
•Extended if other resources are reduced and
•Reduced if other resources are increased.
- Money (Secondary resource).
•Used to buy other resources,
•Is consumed while other resources are being used.
Resource requirement list:
- A list of the resources that will be required.
- Along with the expected level of demand.
we need to map the resources to the activity plan to asses the distribution of the
resources over the duration of the project.
This mapping is best done by representing the
activity plan as a bar chart and using a resource histogram for each resource.
Prioritizing Activities
Total Float Priority
– Activities with the smallest total float are given highest priority.
– Thus Activities are allocated resources in ascending order of total float.
– It is desirable to recalculate floats as the scheduling proceeds.
Burman’s priority list :
1. Shortest critical activity.
2. Critical activities.
3. Shortest non‐critical activity.
4. Non‐critical activity with least float.
5. Non‐cri2cal activities.
Staff Allocation Issues
• Availability
– Whether a particular individual will be available when needed.
– Investigate the risks that can prevent that from happening.
• Criticality
– Allocating more experienced personnel to critical activities often:
• Shortens the project duration
• Or at least reduces the risk of overrun.
• Risk
– Allocating the most experienced staff to the highest‐risk activities is likely to have the greatest effect in reducing overall project uncertainties.
Training
Allocate junior staff to appropriate non
critical activities, so there will be enough slack
for them to train and develop skills.
Team Building
The selection of individuals in the project
team must take account of :
– the final shape of the project team,
– the way they will work together.
The foftware could be:
•a bespoke system - created specially for the customer
•off-the-shelf - bought ‘as is’
•customised off-the-shelf (COTS) - a core system is customised to meet needs of a particular customer
types of contracts
•fixed price contracts
•time and materials contracts
•fixed price per delivered unit
fixed price contracts
Advantages to customer
•known expenditure
•supplier motivated to be cost-effective
Disadvantages
•supplier will increase price to meet contingencies
•difficult to modify requirements
•cost of changes likely to be higher
•threat to system quality
time and materials contracts
Advantages to customer
•easy to change requirements
•lack of price pressure can assist product quality
Disadvantages
•Customer liability - the customer absorbs all the risk associated with poorly defined or changing requirements
•Lack of incentive for supplier to be cost-effective
fixed price per delivered unit
Advantages for customer
•customer understanding of how price is calculated
•comparability between different pricing schedules
•emerging functionality can be accounted for
•supplier incentive to be cost-effective
Disadvantages
•difficulties with software size measurement - may need independent FP counter
•changing (as opposed to new) requirements: how do you charge?
Requirements document: sections
•introduction
•description of existing system and current environment
•future strategy or plans
•system requirements -
– mandatory/desirable features
•deadlines
•additional information required from bidders
Requirements
–functions in software, with necessary inputs and outputs
–standards to be adhered to other applications with which software is to be compatible
–quality requirements e.g. response times
Evaluation plan
Methods could include:
–reading proposals
–interviews
–demonstrations
–site visits
–practical tests
Contract checklist
•Definitions – what words mean precisely e.g. ‘supplier’, ‘user’, ‘application’
•Form of agreement. For example, is this a contract for a sale or a lease, or a license to use a software application? Can the license be transferred?
•Goods and services to be supplied – this could include lengthy specifications
•Timetable of activities
•Payment arrangements – payments may be tied to completion of specific tasks
•Ownership of software
•Can client sell software to others?
•Can supplier sell software to others? Could specify that customer has ‘exclusive use’
•Does supplier retain the copyright?
•Where supplier retains source code, may be a problem if supplier goes out of business; to circumvent a copy of code could be deposited with an escrow service
•Environment – for example, where equipment is to be installed, who is responsible for various aspects of site preparation e.g. electricity supply?
•Customer commitments – for example providing access, supplying information
•Standards to be met
Contract management
Contracts should include agreement about how customer/supplier relationship is to be managed e.g.
–decision points - could be linked to payment
–quality reviews
–changes to requirements
The Place of Software Qualityin Project Planning “step wise framework”
•Step 1: Identify project scope and objectives: some objectivescould relate to the qualities of the application to be delivered.
•Step 2: Identify project infrastructure, within this step, activity 2.2 identifies installation standards and procedures. Some of those will be about quality.
•Step 3: Analyze project characteristics, within this step activity 3.2 Analyze other project characteristics including quality based ones.
•Step 4: identify the products and activities of the project.
•Step 8: Review and publicize plan, at this stage the overall quality aspects of the project plan are reviewed.
Every system has:
•Functional requirements: what is the system is to do.
•Resource requirements: allowable cost.
•Quality requirements: how well the system is to operate.
Example of quality requirements required by the users are:
- Usability.
- Reliability.
Measures can be:
– Direct measures: where we can measure the quality directly.
– Indirect measures: where the thing being measured is not the quality itself, but an indicator that the quality is present.
– e.g. the number of enquirers by users received by a help desk about how one operates a particular SW application might be an indirect measurement of its usability.
Quality Specifications
- Definition “description” of the quality characteristic.
- Scale: the unit of measurement.
- Test: the practical test of the extent to which the attribute quality exists.
- Minimally acceptable: the worst value which might be acceptable if other characteristics compensated for it, where the product would be rejected if had a lower value.
- Target range: the range of values within which it is planned the quality measurement should lie.
- Now: the value that applies currently.
ISO 9126 defines six major software quality characteristics:
•Functionality: covers the functions that a software product provides to satisfy user needs.
•Reliability: refers to the capability of the software to maintain its level of performance.
•Usability: which relates to the effort needed to use the software.
•Efficiency: which relates to the physical resources used when the software is executed.
•Maintainability: relates to the effort needed to make changes to the software.
•Portability: relates to the ability of the software to be transferred to a different environment.
Solving problems and multiple choice:
ROI = average annual profit / total investment * 100
Discount factor = 1/(1+r)t
r is the interest rate (e.g. 10% is 0.10)
t is the number of years
Year / Cash-flow / Discount factor / Discounted cash flow0 / -100,000 / 1.0000 / -100,000
1 / 10,000 / 0.9091 / 9,091
2 / 10,000 / 0.8264 / 8,264
3 / 10,000 / 0.7513 / 7,513
4 / 20,000 / 0.6830 / 13,660
5 / 100,000 / 0.6209 / 62,090
NPV / 618
The FP approach:
1.Identify each external user type in your application.
2.Determine the complexity of each user type (high, average or low)
3.FP score for of each external user type = Multiply the weight of each
complexity by the count of each external user type that has that complexity.
4. FP count = summation of all the FP scores.
FP count indicates the size of the information processing.
FP Mark II:
Wi = 0.58 , We= 1.66 , Wo = 0.26
FP = Wi* (number of input data element types) +We* (number of entity types referenced) +
Wo* (number of output data element types)
COCOMO II:
Effort= c(size)k
Activity Float:
Difference between the latest start and the earliest start or
Difference between the latest finish and the earliest finish.
Activity Span:
Difference between the latest finish and the earliest start.
It is a measure of the maximum time allowable for the activity.
Total float (without affecting the completion of the project) it is the float recorded in the precedence network
= Latest start date – Earliest start date
Free float (without affecting the next activity)
= Earliest start date of next activity – Earliest Finish date of activity(in question)