Here are some common ways activities are organized in projects:
- By project phase (e.g. requirements, design, development, testing)
- By deliverable (e.g. requirements document, design specs, code)
- By work package (e.g. user interface design, database development)
- By component or subsystem (e.g. billing module, reporting features)
- By task type (e.g. coding, documentation, testing)
Organizing activities around milestones helps ensure the project stays on track to complete key checkpoints by certain dates. This provides regular opportunities for oversight and redirection if needed.
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
In systems engineering and software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications.
Objectives:
1. To understand the different processes in the realm of ‘Requirements Engineering’.
2. To see the challenges in requirements development and the importance of getting requirements right in an IT project.
3. To understand the different techniques used in different phases and processes of requirements development and management.
Software Process Models, The Linear Sequential Model, The Prototyping Model, The RAD Model, Evolutionary Process Models, Agile Process Model, Component-Based Development, Process, Product and Process.
Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user's needs and constraints for the system.
Requirements analysis is the process of refining the user's needs and constraints.
Requirements specification is the process of documenting the user's needs and constraints clearly and precisely.
Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification)
Software Process Models, The Linear Sequential Model, The Prototyping Model, The RAD Model, Evolutionary Process Models, Agile Process Model, Component-Based Development, Process, Product and Process.
Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user's needs and constraints for the system.
Requirements analysis is the process of refining the user's needs and constraints.
Requirements specification is the process of documenting the user's needs and constraints clearly and precisely.
Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification)
This presentation is about a lecture I gave within the "Software systems and services" immigration course at the Gran Sasso Science Institute, L'Aquila (Italy): http://cs.gssi.infn.it/.
http://www.ivanomalavolta.com
Software Engineering REQUIREMENTS ANALYSIS AND SPECIFICATIONDr Anuranjan Misra
Software Requirements: Functional and Non-Functional, User requirements, System requirements, Software Requirements Document – Requirement Engineering Process: Feasibility Studies, Requirements elicitation and analysis, requirements validation, requirements management-Classical analysis: Structured system Analysis, Petri Nets- Data Dictionary
Introduction to software engineering
Software products
Why Software is Important?
Software costs
Features of Software?
Software Applications
Software—New Categories
Software Engineering
Importance of Software Engineering
Essential attributes / Characteristics of good software
Software Components
Software Process
Five Activities of a Generic Process framework
Relative Costs of Fixing Software Faults
Software Qualities
Software crisis
Software Development Stages/SDLC
What is Software Verification
Advantages of Software Verification
Advantages of Validation
Operation “Blue Star” is the only event in the history of Independent India where the state went into war with its own people. Even after about 40 years it is not clear if it was culmination of states anger over people of the region, a political game of power or start of dictatorial chapter in the democratic setup.
The people of Punjab felt alienated from main stream due to denial of their just demands during a long democratic struggle since independence. As it happen all over the word, it led to militant struggle with great loss of lives of military, police and civilian personnel. Killing of Indira Gandhi and massacre of innocent Sikhs in Delhi and other India cities was also associated with this movement.
June 3, 2024 Anti-Semitism Letter Sent to MIT President Kornbluth and MIT Cor...Levi Shapiro
Letter from the Congress of the United States regarding Anti-Semitism sent June 3rd to MIT President Sally Kornbluth, MIT Corp Chair, Mark Gorenberg
Dear Dr. Kornbluth and Mr. Gorenberg,
The US House of Representatives is deeply concerned by ongoing and pervasive acts of antisemitic
harassment and intimidation at the Massachusetts Institute of Technology (MIT). Failing to act decisively to ensure a safe learning environment for all students would be a grave dereliction of your responsibilities as President of MIT and Chair of the MIT Corporation.
This Congress will not stand idly by and allow an environment hostile to Jewish students to persist. The House believes that your institution is in violation of Title VI of the Civil Rights Act, and the inability or
unwillingness to rectify this violation through action requires accountability.
Postsecondary education is a unique opportunity for students to learn and have their ideas and beliefs challenged. However, universities receiving hundreds of millions of federal funds annually have denied
students that opportunity and have been hijacked to become venues for the promotion of terrorism, antisemitic harassment and intimidation, unlawful encampments, and in some cases, assaults and riots.
The House of Representatives will not countenance the use of federal funds to indoctrinate students into hateful, antisemitic, anti-American supporters of terrorism. Investigations into campus antisemitism by the Committee on Education and the Workforce and the Committee on Ways and Means have been expanded into a Congress-wide probe across all relevant jurisdictions to address this national crisis. The undersigned Committees will conduct oversight into the use of federal funds at MIT and its learning environment under authorities granted to each Committee.
• The Committee on Education and the Workforce has been investigating your institution since December 7, 2023. The Committee has broad jurisdiction over postsecondary education, including its compliance with Title VI of the Civil Rights Act, campus safety concerns over disruptions to the learning environment, and the awarding of federal student aid under the Higher Education Act.
• The Committee on Oversight and Accountability is investigating the sources of funding and other support flowing to groups espousing pro-Hamas propaganda and engaged in antisemitic harassment and intimidation of students. The Committee on Oversight and Accountability is the principal oversight committee of the US House of Representatives and has broad authority to investigate “any matter” at “any time” under House Rule X.
• The Committee on Ways and Means has been investigating several universities since November 15, 2023, when the Committee held a hearing entitled From Ivory Towers to Dark Corners: Investigating the Nexus Between Antisemitism, Tax-Exempt Universities, and Terror Financing. The Committee followed the hearing with letters to those institutions on January 10, 202
Palestine last event orientationfvgnh .pptxRaedMohamed3
An EFL lesson about the current events in Palestine. It is intended to be for intermediate students who wish to increase their listening skills through a short lesson in power point.
The French Revolution, which began in 1789, was a period of radical social and political upheaval in France. It marked the decline of absolute monarchies, the rise of secular and democratic republics, and the eventual rise of Napoleon Bonaparte. This revolutionary period is crucial in understanding the transition from feudalism to modernity in Europe.
For more information, visit-www.vavaclasses.com
Francesca Gottschalk - How can education support child empowerment.pptxEduSkills OECD
Francesca Gottschalk from the OECD’s Centre for Educational Research and Innovation presents at the Ask an Expert Webinar: How can education support child empowerment?
Model Attribute Check Company Auto PropertyCeline George
In Odoo, the multi-company feature allows you to manage multiple companies within a single Odoo database instance. Each company can have its own configurations while still sharing common resources such as products, customers, and suppliers.
How to Make a Field invisible in Odoo 17Celine George
It is possible to hide or invisible some fields in odoo. Commonly using “invisible” attribute in the field definition to invisible the fields. This slide will show how to make a field invisible in odoo 17.
1. IEEE Std 830-1998 Characteristics of
a good SRS
1. Correct 6. Verifiable
2. Unambiguous 7. Modifiable
3. Complete 8. Traceable
4. Consistent
5. Ranked for
importance and/or
stability
2. IEEE Std 830-1998: Parts of an
SRS
• Introduction
– Purpose
• purpose of SRS
• intended audience for SRS
– Scope
• identify software to be produced by name
• explain what software will (not) do
• describe application of software (benefits,
objectives)
3. IEEE Std 830-1998: Parts of an
SRS
• Introduction (continued)
– Definitions/acronyms/abbreviations
– References
• list documents referenced by name and source
– Overview
• brief description of rest of SRS
• organization of SRS
4. IEEE Std 830-1998: Parts of an
SRS
• Overall description
– Product perspective (related products?)
• block diagram
• constraints
– system interfaces
» identify functionality that fulfills each system requirement
– user interfaces
– hardware interfaces
– software interfaces
» how software interacts with supporting software (purpose,
message content and format)
» required versions
5. IEEE Std 830-1998: Parts of an
SRS
• Overall description (continued)
– Product perspective
• constraints
– communications interfaces
» network protocols
– memory
» requirements/limits on primary and secondary memory
– operations
» modes of operation
» interactive vs. unattended operation
» backup & recovery
– site adaptation requirement
6. IEEE Std 830-1998: Parts of an
SRS
• Overall description (continued)
– Product functions
• summary of major functions sw will perform
– Intended user characteristics
• educational level
• experience
• technical expertise
7. IEEE Std 830-1998: Parts of an
SRS
• Overall description (continued)
– Constraints (limitations of developer options)
• regulatory policies
• hardware limitations (e.g. signal timing requirements)
• interfaces to other applications
• parallel operation
• audit functions
• control functions
• higher-order language requirements
• reliability requirements
• criticality of the application
• safety and security considertations
8. IEEE Std 830-1998: Parts of an
SRS
• Overall description (continued)
– Assumptions and dependencies
• e.g. specific OS available on HW
– Apportioning of requirements
• requirements that may be delayed to future versions
9. IEEE Std 830-1998: Parts of an
SRS
• Specific requirements
– External interfaces
– Functions
– Performance requirements
– Logical database requirements
– Design constraints
• Standards compliance
10. IEEE Std 830-1998: Parts of an
SRS
• Specific requirements (continued)
– Software system attributes
• Reliability
• Availability
• Security
• Maintainability
• Portability
11. IEEE Std 830-1998: Parts of an
SRS
• Specific requirements (continued)
– Organizing the specific requirements
• System mode
• User class
• Objects
• Feature
• Stimulus
• Response
• Functional hierarchy
– Additional comments
12. IEEE Std 830-1998: Parts of an
SRS
• Supporting Information
– Table of contents
– Index
– Appendixes
14. Feasibility Study
• A feasibility study is a study made before
committing to a project.
• A feasibility study leads to a decision:
• go ahead
• do not go ahead
• think again
• In production projects, the feasibility study often
leads to a budget request.
• A feasibility study may be in the form of a proposal.
15. Contents of Feasibility Study
Client: Who is this project for?
Scope: What are the boundaries of the project?
Benefits: What are the benefits? Can they be quantified?
Technical: Is the project possible. Is there at least one
technical way to carry out the project?
Resources: What are the estimates of staff, time,
equipment, etc?
Alternatives: What are the options if the project is not
begun?
16. Feasibility Report
A written document
• For a general audience: client, financial management,
technical management, etc.
• Short enough that everybody reads it.
• Long enough that no important topics are skipped.
• Details are often included in supporting documents.
It should be a well written, well presented document.
17. Types of Feasibility
• Economic feasibility
• Technical feasibility
• Operational feasibility
• Schedule feasibility
• Legal and contractual feasibility
• Political feasibility
18. Economic Feasibility
• Cost-benefit analysis – identify all the financial
benefits and costs associated with a project
– Tangible vs. intangible benefits
– Tangible vs. intangible costs
– One-time vs. recurring costs
19. Technical Feasibility
• Assessing the organization’s ability to construct
the proposed system
• Takes into account various project risk factors
20. Other Feasibility Concerns
• Operational
– Will the system achieve the objectives of the project?
• Schedule
– Can the project be accomplished in a reasonable time
frame?
– Project management critical path scheduling can help
answer this concern.
• Legal/Contractual
– Are there regulations or legal obligations that affect the
success of the project?
• Political
– Will the project have user and management support?
– Will there be resistance?
25. Issues to be handled under SPM
– People,
– Process,
– And Problem
– Software metrics
– Software project
– Software process
– Software team
– Risk
26. Issues to be handled under
SPM
• How must the
– people,
– process,
– and problem
be managed during a software project?
• What are software metrics and how can they
be used to manage a software project and
the software process?
27. Issues to be handled under
SPM
• How does a software team generate reliable
estimates of effort, cost, and project duration?
• What techniques can be used to formally assess
the risks that can have an impact on project
success?
28. Issues to be handled under SPM
• How does a software project manager select the
set of software engineering work tasks?
• How is a project schedule created?
• How is quality defined so that it can be
controlled?
• What is software quality assurance?
• Why are formal technical reviews so important?
• How is change managed during the
development of computer software and after
delivery to the customer?
30. Who does Software Project Management
• Everyone “manages” to some extent, but the
scope of management activities varies with the
person doing it.
• A software engineer manages his day-to-day
activities, planning, monitoring, and controlling
technical tasks.
• Project managers plan, monitor, and control the
work of a team of software engineers.
• Senior managers coordinate the interface
between the business and the software
professionals
32. Why Software Project Management is
important
• Building computer software is a
complex undertaking, particularly if it
involves many people working over a
relatively long time.
34. The 4 P’s
• People — the most important element of a
successful project
• Product — the software to be built
• Process — the set of framework activities
and software engineering tasks to get the
job done
• Project — all work required to make the
product a reality
34
35. The People
• The “people factor” is so important that the
Software Engineering Institute has developed
a people management capability maturity
model (PM-CMM), “to enhance the readiness
of software organizations to undertake
increasingly complex applications by helping
to attract, grow, motivate, deploy, and retain
the talent needed to improve their software
development capability”
36. People management capability
maturity model (PM-CMM)
• The people management maturity model
defines the following key practice areas for
software people: recruiting, selection,
performance management, training,
compensation, career development,
organization and work design, and
team/culture development.
37. The Product
• Before a project can be planned, product
objectives and scope should be established.
• Alternative solutions should be considered, and
technical and management constraints should
be identified.
• Without this information, it is impossible to
define reasonable (and accurate) estimates of
the cost, an effective assessment of risk, a
realistic breakdown of project tasks, or a
manageable project schedule that provides a
meaningful indication of progress.
38. The Process
• A software process provides the framework
from which a comprehensive plan for software
development can be established. A number
of different task sets—tasks, milestones,
work products, and quality assurance
points—enable the framework activities to
be adapted to the characteristics of the
software project and the requirements of
the project team.
39. The Project
• In 1998, industry data indicated that 26 percent of
software projects failed outright and 46 percent
experienced cost and schedule overruns.
• In order to avoid project failure, a software project
manager and the software engineers who build the
product must avoid a set of common warning signs,
understand the critical success factors that lead to good
project management, and develop a commonsense
approach for planning, monitoring and controlling the
project.
41. Who are the Stakeholders in SPM
• Senior managers who define the business issues
that often have significant influence on the project.
• Project (technical) managers who must plan,
motivate, organize, and control the practitioners
who do software work.
• Practitioners who deliver the technical skills that
are necessary to engineer a product or application.
• Customers who specify the requirements for the
software to be engineered and other stakeholders
who have a peripheral interest in the outcome.
• End-users who interact with the software once it is
41
released for production use.
43. What is MOI model of leadership
• Motivation. The ability to encourage (by
“push or pull”) technical people to produce to
their best ability.
• Organization. The ability to mold existing
processes (or invent new ones) that will
enable the initial concept to be translated into
a final product.
• Ideas or innovation. The ability to encourage
people to create and feel creative even when
they must work within bounds established for
a particular software product or application.
45. Types of Software Team
• Mantei [MAN81] suggests three generic team
organizations:
• Democratic decentralized (DD). This
software engineering team has no permanent
leader. Rather, "task coordinators are
appointed for short durations and then
replaced by others who may coordinate
different tasks.“
• Communication within the team is horizontal.
46. Types of Software Team
• Controlled decentralized (CD). This software
engineering team has a defined leader who
coordinates specific tasks and secondary
leaders that have responsibility for subtasks.
– Problem solving remains a group activity, but
implementation of solutions is partitioned among
subgroups by the team leader.
– Communication among subgroups and individuals
is horizontal. Vertical communication along the
control hierarchy also occurs.
47. Types of Software Team
• Controlled Centralized (CC). Top-level
problem solving and internal team
coordination are managed by a team leader.
Communication between the leader and team
members is vertical.
48. What are the Project coordination
techniques
• Formal, impersonal approaches include software
engineering documents and deliverables (including
source code), technical memos, project milestones,
schedules, and project control tools, change
requests and related documentation, error tracking
reports, and repository data.
• Formal, interpersonal procedures focus on
quality assurance activities applied to software
engineering work products. These include status
review meetings and design and code inspections.
49. What are the Project coordination
techniques
• Informal, interpersonal procedures include group
meetings for information dissemination and problem
solving sessions for development staff.
• Electronic communication encompasses
electronic mail, electronic bulletin boards, and by
extension, video-based conferencing systems.
• Interpersonal networking includes informal
discussions with team members and those outside
the project who may have experience or insight that
can assist team members.
51. Motivation behind the selection of
Software Teams
• The difficulty of the problem to be solved
• The size of the resultant program(s) in lines of code or
function points
• The time that the team will stay together (team lifetime)
• The degree to which the problem can be modularized
• The required quality and reliability of the system to be built
• The rigidity of the delivery date
• The degree of sociability (communication) required for the
project
51
53. What is the Product Scope….
• Scope
• Context. How does the software to be built fit into a
larger system, product, or business context and what
constraints are imposed as a result of the context?
• Information objectives. What customer-visible data
objects are produced as output from the software?
What data objects are required for input?
• Function and performance. What function does the
software perform to transform input data into output?
Are any special performance characteristics to be
addressed?
• Software project scope must be unambiguous
and understandable at the management and
53
technical levels.
54. What is Problem Decomposition
• Sometimes called partitioning or problem
elaboration
• Once scope is defined …
– It is decomposed into constituent functions
– It is decomposed into user-visible data objects
or
– It is decomposed into a set of problem classes
• Decomposition process continues until all
functions or problem classes have been defined
54
56. The Project get into trouble
when …
• Software people don’t understand their customer’s
needs.
• The product scope is poorly defined.
• Changes are managed poorly.
• The chosen technology changes.
• Business needs change [or are ill-defined].
• Deadlines are unrealistic.
• Users are resistant.
• Sponsorship is lost [or was never properly obtained].
• The project team lacks people with appropriate skills.
• Managers [and practitioners] avoid best practices and
56
lessons learned.
58. THE W5HH PRINCIPLE: A way of
analysis
It includes a series of questions that lead to a
definition of key project characteristics and the
resultant project plan:
• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be done technically and
managerially?
• How much of each resource (e.g., people, software,
58
tools, database) will be needed?
59. Why SPM is different...
• The product is intangible.
• The product is uniquely flexible.
• Software engineering is not recognized as an
engineering discipline with the sound status as
mechanical, electrical engineering, etc.
• The software development process is not
standardised.
• Many software projects are ‘never-to -be-
repeated' projects
61. Types of project plan
Plan Description
Quality plan Describes the quality procedures and
standards that will be used in a project.
Validation plan Describes the approach, resources and
schedule used for system validation.
Configuration Describes the configuration management
management plan procedures and structures to be used.
Maintenance plan Predicts the maintenance requirements of
the system, maintenance costs and effort
required.
Staff development plan. Describes how the skills and experience of
the project team members will be
developed.
62. Project plan structure
• Introduction
• Project organisation
• Risk analysis
• Hardware and software resource requirements
• Work breakdown
• Project schedule
• Monitoring and reporting mechanisms
64. Activity organization
• Activities in a project should be organised to
produce tangible outputs for management to
judge progress
• Milestones are the end-point of a process
activity
• Deliverables are project results delivered to
customers
• The waterfall process allows for the
straightforward definition of progress
milestones
66. Milestones in the SE process
ACTIVITIES
Feasibility Requir ements Prototype Design Requir ements
study analysis development study specification
Feasibility Requir ements Evaluation Architectural Requir ements
report definition report design specification
MILESTONES
68. Project scheduling
• Split project into tasks and estimate time and
resources required to complete each task
• Organize tasks concurrently to make optimal
use of workforce
• Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete
• Dependent on project managers intuition and
experience
69. The project scheduling process
Identify Identify activity Estimate resources Allocate people Create project
activities dependencies for activities to activities charts
Software Activity charts
requirements and bar charts
71. Scheduling problems; why it
occurs.
• Estimating the difficulty of problems and
hence the cost of developing a solution is hard
• Productivity is not proportional to the number
of people working on a task
• Adding people to a late project makes it later
because of communication overheads
• The unexpected always happens. Always
allow contingency in planning
72. Bar charts and activity networks
• Graphical notations used to illustrate the
project schedule
• Show project breakdown into tasks.
– Tasks should not be too small.
– They should take about a week or two
• Activity charts show task dependencies and
the critical path
• Bar charts show schedule against calendar
time
74. Activity network
14/7/99 15 days
15 days
M1 T3
8 days T9
T1 5 days 4/8/99 25/8/99
25/7/99
T6 M4 M6
4/7/99 M3
start 20 days 7 days
15 days
T7 T11
T2
25/7/99 10 days 11/8/99 5/9/99
10 days
M2 M7 M8
T4 T5 15 days
T10 10 days
18/7/99
T12
M5
25 days
T8 Finish
19/9/99
76. Staff allocation
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Fred T4
T8 T11
T12
Jane T1
T3
T9
Anne T2
T6 T10
Jim T7
Mary T5
77. Risk management
Risk management is concerned with identifying
risks and drawing up plans to minimise their
effect on a project.
A risk is a probability that some adverse
circumstance will occur.
Project risks affect schedule or resources
Product risks affect the quality or performance of the
software being developed
Business risks affect the organisation developing or
procuring the software
78. Software risks
Risk Risk type Description
Staff turnover Project Experienced staff will leave the
project before it is finished.
Management change Project There will be a change of
organisational management with
different priorities.
Hardware unavailability Project Hardware which is essential for the
project will not be delivered on
schedule.
Requirements change Project and There will be a larger number of
product changes to the requirements than
anticipated.
Specification delays Project and Specifications of essential interfaces
product are not available on schedule
Size underestimate Project and The size of the system has been
product underestimated.
CASE tool under- Product CASE tools which support the
performance project do not perform as anticipated
Technology change Business The underlying technology on which
the system is built is superseded by
new technology.
Product competition Business A competitive product is marketed
before the system is completed.
79. The Risk Management Process
• Risk identification
– Identify project, product and business risks
• Risk analysis
– Assess the likelihood and consequences of these
risks
• Risk planning
– Draw up plans to avoid or minimise the effects of
the risk
• Risk monitoring
– Monitor the risks throughout the project
80. The risk management process
Risk Risk analysis Risk planning Risk
identification monitoring
List of potential Risk avoidance Risk
Prioritised risk and contingency
risks list assessment
plans
82. Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many
transactions per second as expected.
Software components which should be reused contain defects
which limit their functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management
are responsible for the project.
Organisational financial problems force reductions in the project
budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements which require major design rework are
proposed.
Customers fail to understand the impact of requirements
changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
83. Risk analysis
• Assess probability and seriousness of each risk
• Probability may be
– very low
– low
– moderate
– high or very high
• Risk effects might be
– catastrophic
– serious
– Tolerable
– insignificant
84. Risk analysis
Risk Probability Effects
Organisational financial problems force reductions Low Catastrophic
in the project budget.
It is impossible to recruit staff with the skills High Catastrophic
required for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components which should be reused Moderate Serious
contain defects which limit their functionality.
Changes to requirements which require major Moderate Serious
design rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.
The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
85. Risk planning
Consider each risk and develop a strategy to
manage that risk
Avoidance strategies
The probability that the risk will arise is reduced
Minimisation strategies
The impact of the risk on the project or product will
be reduced
Contingency plans
If the risk arises, contingency plans are plans to
deal with that risk
86. Risk management strategies
Risk Strategy
Organisational Prepare a briefing document for senior management showing
financial problems how the project is making a very important contribution to the
goals of the business.
Recruitment Alert customer of potential difficulties and the possibility of
problems delays, investigate buying-in components.
Staff illness Reorganise team so that there is more overlap of work and
people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-in
components components of known reliability.
Requirements Derive traceability information to assess requirements change
changes impact, maximise information hiding in the design.
Organisational Prepare a briefing document for senior management showing
restructuring how the project is making a very important contribution to the
goals of the business.
Database Investigate the possibilit y of buying a higher-performance
performance database.
Underestimated Investigate buying in components, investigate use of a program
development time generator.
87. Risk monitoring
• Assess each identified risks regularly to
decide whether or not it is becoming less or
more probable
• Also assess whether the effects of the risk
have changed
• Each key risk should be discussed at
management progress meetings
88. Risk factors
Risk type Potential indicators
Technology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availability
Organisational organisational gossip, lack of action by senior
management
Tools reluctance by team members to use tools, complaints
about CASE tools, demands for higher-powered
workstations
Requirements many requirements change requests, customer
complaints
Estimation failure to meet agreed schedule, failure to clear
reported defects
89. Key points
Good project management is essential for project
success.
The intangible nature of software causes
problems for management.
Managers have diverse roles but their most
significant activities are planning, estimating and
scheduling.
Planning and estimating are iterative processes
which continue throughout the course of a
project.
90. Key points
• A project milestone is a predictable state
where
some formal report of progress is presented to
management.
• Risks may be project risks, product risks or
business risks
• Risk management is concerned with
identifying risks which may affect the project
and planning to ensure that these risks do not
develop into major threats