Scribd
Upload
3 views

Lecture 8 Project Managment

Uploaded by

Mohamed elkholy
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

Lecture 8 Project Managment

Uploaded by

Mohamed elkholy
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

• Risk is an expectation of loss, a potential problem that may occur in the

future.

• It is generally caused due to lack of information, control or time.

• Loss can be increase in production cost, development of poor quality


product, not being able to complete the project on time.

2
• A risk can be of two types

–(1) internal risks that are within the control of the project
manager.

–(2) external risks that are beyond the control of project manager.

3
• A software project can be concerned with a large variety of risks.

• In order to be adept to systematically identify the significant risks which might


affect a software project, it is essential to classify risks into different classes.

• Project risks

• Technical risks

• Business risks
• Project risk includes Time, budget, quality.

• Since the software is intangible, it is very tough to monitor and


control a software project.

• For example in the manufacturing of cars, the plan executive


can recognize the product taking shape.
• Technical risks concern potential method (functions), interfacing, testing, and
maintenance issue.

• It also consists of an ambiguous specification, incomplete requirements,


changing specification, technical uncertainty, and technical obsolescence.

• Most technical risks appear due to the development team's insufficient


knowledge about the project.
• This type of risks contain risks of building an excellent product that no
one needs it, losing budgetary or personnel commitments.

• Long development time leads to a potential risk of finding similar


software in the market.
• Reviewing requirements is an important part of risk management, in order to achieve a balance
between needed functionality and scope creep.

• Unclear requirements from stockholders.

• Low level of requirement presentations.

• Unverifiable Requirements : requirements that can not be verified or tested.


• Managing risk in code is one of the best and most efficient methods of risk

management.

• Low Readability of code defines a predicted risk.

• Low level of coherence of software components increases risk like hood.

• Increasing dependency between components increase risk probability.


• The business domain defines the shape and content of data.

• Modeling of data is an exercise in risk management that improves understanding of the

business domain.

• Code must complement the business rules applied to the data (access data, change values).

• Data size and its growth


• The most important step to define and predict test

• Testing is proof that code fulfills two main risk management criteria, firstly that it satisfies
requirements and secondly that it does so without errors.

• Insufficient test cases

• Preform validation test without defect test

• Perform Validation test without verification test


• Validation testing
– To demonstrate that the software meets its requirements (correct inputs)

• Defect testing
– To discover faults or defects in the software
– A successful test is a test that makes the system perform incorrectly and so exposes a defect in
the system.

Examples of defect test


1. Arithmetic Defects
2. Logical Defects
Validation vs Verification
• Validation:
"Are we building the right product”.
• The software should do what the user really requires.

• Verification:
"Are we building the right product right”.
• The software should conform to its specification.

15
Validation Verification

It always involves executing the code. .1 It does not involve executing the code. .1

2. It is computer based execution of program. 2. It is human based checking of documents and


files.

3. Validation uses methods like black box 3.Verification uses methods like inspections,
(functional) testing, gray box testing, and white reviews, walkthroughs.
box (structural) testing etc.

4. Validation is an external process done by the 4. Verification is done by project team to ensure
customer and identified stakeholders before that they are on the right track and working as per
accepting the deliverable. the agreed specification and process

16
Equivalence partitioning

17
Equivalence partitioning

Groups of valid input


System

outputs

invalid input

18
Equivalence partitions

A program that accepts 4 to 10 inputs that are five digits

19

You might also like