project

A project is defined as a planned activity, emphasizing the need for careful thinking and planning
before execution, even when dealing with uncertain or exploratory tasks. Projects are characterized
by several key factors:

• Non-routine tasks are involved.

• Planning is required.

• Specific objectives are to be met or a specified product is to be created.

• The project has a predetermined time span.

• Work is carried out for someone other than yourself.

• Work involves several specialisms.

• People are formed into a temporary work group to carry out the task.

• Work is carried out in several phases.

• The resources available for use on the project are constrained.

• The project is large or complex.

The more these factors apply to a task, the more difficult it becomes. Project size is particularly
important, as larger projects require more coordination and are disproportionately more difficult.

In contrast, a job or routine task is something that has been performed so many times that everyone
knows exactly what to do, making planning hardly necessary. Procedures might be documented to
ensure consistency and to help newcomers. The boundary between a non-routine project and a
routine job is hazy. The first time you do a routine task, it will be like a project. Conversely, a project
to develop a system similar to previous ones will have a large element of the routine.

Projects are often seen as temporary sub-organizations that cut across the authority of existing units
within an organization. This allows a group of specialists to focus on a single important task, but can
also be seen as disruptive to others. Expertise built up during the project may be lost when the team
is dispersed at the end of the project.
Activities covered by software project management:

Software project management encompasses a range of activities beyond just writing software. Even
when software is bought “off the shelf,” it remains a software project due to the various associated
activities. The key activities covered by software project management include:

1. Feasibility Study:

o Assessing whether a project is worth starting.

o Gathering information about the requirements of the proposed application.

o Estimating developmental and operational costs, and the value of the benefits.

o This study can be complex and difficult, especially with large systems, and may itself
be a project with its own plan.

2. Requirements Elicitation:

o Gathering requirements from stakeholders who may know their aims but not the
means of achievement.

o This process can be complex and difficult initially.

3. Project Planning:

o If the feasibility study indicates the project is viable, planning begins.

o For larger projects, detailed planning is not done at the beginning. Instead, an
outline plan for the whole project and a detailed plan for the first stage are created.

o Planning of later stages is done nearer their start, as more detailed and accurate
project information becomes available after earlier stages are completed.

4. Project Execution:

o The project is executed, often containing design and implementation sub-phases.

o Design involves making decisions about the form of the products to be created, such
as the user interface or internal architecture.
 o The plan details the activities to be carried out to create these products.

o Planning and design can be confused because planning decisions are influenced by
design decisions at the most detailed level.

These activities ensure that a software project is systematically managed from inception to
completion, addressing various aspects such as feasibility, requirements, planning, and execution.

traditional and modern approaches using the provided text:

1. Planning

o Traditional: Planning is extensive and done at the beginning of the project, with
detailed schedules and task assignments that are followed throughout the project.

o Modern: Planning is iterative and adaptive, with continuous updates based on

ongoing feedback and changing requirements.

2. Incremental Delivery

o Traditional: Delivery is done in a single, final phase at the end of the project after all
development work is completed.

o Modern: Delivery is incremental and iterative, with smaller, usable segments of the
product delivered regularly throughout the project lifecycle.

3. Quality Management

o Traditional: Quality assurance is typically conducted at the end of the development

cycle, focusing on final testing and validation.

o Modern: Quality is built into the process with continuous testing, integration, and
feedback loops throughout the development cycle.

4. Change Management

o Traditional: Changes are managed through a formal change control process, often
making it difficult to incorporate changes once the project plan is set.

o Modern: Changes are expected and welcomed, with flexible processes that allow for
easy adaptation to new requirements or unforeseen issues.

5. Requirement Management

o Traditional: Requirements are gathered and documented comprehensively at the

beginning of the project and are assumed to be stable and unchanging.

o Modern: Requirements are continuously gathered and refined throughout the

project, with ongoing stakeholder engagement to ensure alignment with business
needs.

6. Release Management

o Traditional: There is typically one major release at the end of the project after all
features have been developed and tested.
 o Modern: Frequent, smaller releases deliver value incrementally, allowing for faster
feedback and continuous improvement.

7. Risk Management

o Traditional: Risks are identified and planned for early in the project, with a static risk
management plan.

o Modern: Risk management is an ongoing activity, with continuous assessment and

adjustment of risk strategies as the project progresses.

8. Scope Management

o Traditional: The project scope is defined early and changes are discouraged; any
changes require formal change requests and approvals.

o Modern: Scope is flexible and can be adjusted based on feedback and changing
requirements, emphasizing delivering maximum value within time and budget
constraints.

This comparison highlights how modern approaches are more flexible, adaptive, and iterative,
allowing for continuous improvement and better alignment with changing requirements and
stakeholder needs.

Sure, let’s break down the differences between software products and software services using the
provided text:

Software Products:

• Definition: Pre-packaged solutions developed for a broad market.

• Design: Designed for general use with common features applicable to many users.
 • Distribution: Distributed widely and often sold through commercial channels.

• Examples: Office suites, graphic design tools, and operating systems.

Software Services:

• Definition: Custom solutions tailored to meet the specific needs of individual clients.

• Development: Developed based on unique client requirements.

• Interaction: Involves ongoing interaction with clients for customization and support.

• Examples: Custom-built enterprise applications and bespoke software for specific business
processes.

Key Differences:

• Target Audience: Products are designed for a broad audience, while services are aimed at
individual clients.

• Development and Delivery: Products follow a standardized development process, whereas

services are developed through a more flexible, client-driven approach.

• Customization: Products offer limited customization, whereas services are highly tailored to
client needs.

• Support and Maintenance: Products typically have standard support, while services include
ongoing, customized support.

This comparison highlights how software products are standardized and broadly applicable, while
software services are customized and tailored to specific client needs.

13.3 Importance of Software Quality

Quality is a concern for all producers of goods and services. However, the special characteristics of
software create special demands.

Increasing criticality of software: The final customer or user is naturally anxious about the general
quality of software, especially its reliability. This concern grows as organizations rely more on their
computer systems and software is used in more safety-critical applications, such as controlling
aircraft.

The intangibility of software: This characteristic can make it difficult to know that a project task was
completed satisfactorily. To address this, task outcomes can be made tangible by demanding that the
developer produce ‘deliverables’ that can be examined for quality.

Accumulating errors during software development: As computer system development comprises

steps where the output from one step is the input to the next, errors in the later deliverables will be
added to those in the earlier steps, leading to an accumulating detrimental effect. Generally, the later
in a project that an error is found, the more expensive it will be to fix. Additionally, because the
number of errors in the system is unknown, the debugging phases of a project are particularly
difficult to control.

For these reasons, quality management is an essential part of effective overall project management.
This text highlights the critical aspects of software quality, emphasizing the need for reliability,
tangible deliverables, and effective error management throughout the development process.

Certainly! Here is the text broken down point by point:

13.3 Importance of Software Quality

1. External Qualities:

o Some qualities of a software product reflect the external view of software held by
users, as in the case of usability.

o These external qualities have to be mapped to internal factors of which the

developers would be aware.

2. Well-Structured Code:

o It could be argued, for example, that well-structured code is likely to have fewer
errors and thus improve reliability.

3. Measuring Quality:

o Defining quality is not enough. If we are to judge whether a system meets our
requirements, we need to be able to measure its qualities.

o The BS ISO/IEC 15939:2007 standard codified many of the practices discussed in this
section.

o A good measure must relate the number of units to the maximum possible faults in a
program.

o For example, a measure of faults per thousand lines of code is more helpful than just
the total number of faults in a program.

o Trying to find measures for a particular quality helps to clarify and communicate
what that quality really is.

o What is being asked is, in effect, ‘how do we know when we have been successful?’

4. Direct and Indirect Measures:

o The measures may be direct, where we can measure the quality directly, or indirect,
where the thing being measured is not the quality itself but an indicator that the
quality is present.

o For example, the number of enquiries by users received by a help desk about how
one operates a particular software application might be an indirect measurement of
its usability.

5. Setting Targets:
 o When project managers identify quality measurements, they effectively set targets
for project team members.

o Care has to be taken that an improvement in the measured quality is always

meaningful.

o For example, the number of errors found in program inspections could be counted,
on the grounds that the more thorough the inspection process, the more errors will
be discovered.

o This count could, of course, be improved by allowing more errors to go through to

the inspection stage rather than eradicating them earlier - which is not quite the
point.

6. Quality Specification:

o When there is concern about the need for a specific quality characteristic in a
software product, then a quality specification with the following minimum details
should be drafted:

▪ Definition/description: Definition 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, and below which the product would have
to be rejected out of hand.

▪ Target range: The range of values within which it is planned the quality
measurement value should lie.

▪ Now: The value that applies currently.

7. Reliability Measurements:

o There could be several measurements applicable to a quality characteristic. For

example, in the case of reliability, this might be measured in terms of:

▪ Availability: The percentage of a particular time interval that a system is

usable.

▪ Mean time between failures: The total service time divided by the number
of failures.

▪ Failure on demand: The probability that a system will not be available at the
time required or the probability that a transaction will fail.

▪ Support activity: The number of fault reports that are generated and
processed.

This breakdown highlights the key points related to defining and measuring software quality,
ensuring that the system meets the required standards and expectations.