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 flow
0 / -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)