Scribd
Upload
6 views20 pages

Lecture 9 Project Managment Ss

Uploaded by

Mohamed elkholy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views20 pages

Lecture 9 Project Managment Ss

Uploaded by

Mohamed elkholy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

• 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.


• (Fast response, low rate of faliuer)
• Managing risk in code is one of the 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 (scalability)


• 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 test

• Defect test

• 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
• A defect is a system error that doesn’t allow the intended action to be
completed.

• Finding defects is the tester’s most important task.

Categories of defect

Priority Severity
When to fix Impact to error to the application

13
• First of all, we need to prioritize defects. This measure determines how urgent correction is.

• Immediate : should be urgently corrected in 24 hours


• High : Should be corrected before exit the testing.
• Medium : Corrected after all high priority are fixed
• Low : Must be fixed before the GA is done.

14
• Severity defines the extent of a particular defect on the application or system.

• It tells us what impact a given bug will have on the application.


• Critical severity
• Major severity
• Minor severity
• Low severity

• An example of a critical error is the inability to make a quick transfer in the banking system.
– (critical severity)

• A logo error, on the other hand, will have a negligible impact on the system.
– (low severity)

15
• Immediate : Critical severity
• when an entire functionality is blocked and no testing can proceed as a result of this. Or in certain
other cases if there are significant memory leaks

• High : Major severity


• Normally when a function is not usable as it’s supposed to be, due to a program defect.

• Medium : Minor severity


• When a function is not usable in a certain situation

• Low : low severity


• Spelling mistakes or clickable buttons or submenus

16
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.

17
Validation Verification

1. 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

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

20

You might also like