1. Unit III Software Design & Testing Methods
Prof. R.K. Samaiya

2. What Is Embedded Software?
Embedded software is a type of software that is built into hardware systems.
This software is typically designed to perform one specific function, although a single piece of hardware may contain multiple pieces of software embedded in it.
Any device that has circuit boards and computer chips have embedded software within it. Examples : Digital clocks, Cell phones, Calculators.

3. Types of Software Software System software Utility software
Application software

4. System software
It is the software used to manage and control the hardware components.
It allow interaction between the hardware and the other types of software.
Examples:
Operating system
Device drivers

5. Utility software
These software helps to maintain and protect the computer system but does not directly interface with the hardware.
Examples:
Anti-virus software
Firewalls
Disk defragmenters

6. Application software / apps
These are designed to allow the to perform a specific task or set of tasks.
Examples:
Web browsers
Office software
Games
Media Player

7. Algorithms Algorithms describes the general actions to be taken.
These are independent of programming language.
These are first step in the design of a program.

8. Steps in development of Algorithms
Problem definition
Development of a model
Specification of Algorithm
Designing an Algorithm
Checking the correctness of Algorithm
Analysis of Algorithm
Implementation of Algorithm
Program testing
Documentation Preparation

9. Software Development Models
Development models are the various processes or methodologies that are being selected for the development of the project depending on the project’s aims and goals.
There are many development life cycle models that have been developed in order to achieve different required objectives.
The models specify the various stages of the process and the order in which they are carried out.

10. The selection of model has very high impact on the testing that is carried out.
The selected model will define the what, where and when to perform testing.
Choosing right model for developing of the software product or application is very important.
Based on the model the development and testing processes are carried out.

11. Software Development Models
SDLC Models
Waterfall model
V model
Incremental model
Agile model
Iterative model
Prototype Model
Spiral model
SDLC: software development
life cycle

12. Waterfall model

13. Waterfall model phases
In "Waterfall" approach, the whole process of software development is divided into separate phases.
Requirements analysis and definition
System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

14. It is a Linear-sequential life cycle model
It is a Linear-sequential life cycle model. This means that any phase in the development process begins only if the previous phase is complete.
The outcome of one phase acts as the input for the next phase sequentially.

15. Waterfall model phases
Requirement Gathering and analysis:
Started with problem description in human language.
All possible requirements of the system to be developed are captured in this phase and documented in a requirement specification doc.
Concept is modelled in mathematical form or algorithms.
In embedded domain, software is associated with different hardware units. Interaction & interfaces between software and hardware must be included during analysis.

16. System Design:
The requirement specifications from first phase are studied in this phase and system design is prepared.
System Design helps in specifying hardware and system requirements and also helps in defining overall system architecture.

17. Waterfall model phases
Implementation:
With inputs from system design, the system is first developed in small programs called units, which are integrated in the next phase.
Unit Testing : Each unit is developed and tested for its functionality which is referred to as Unit Testing.
Integration and Testing:
All the units developed in the implementation phase are integrated into a system after testing of each unit.
Post integration the entire system is tested for any faults and failures.

18. Waterfall model phases
Deployment of system:
Once the functional and non functional testing is done, the product is deployed in the customer environment or released into the market.
Maintenance:
There are some issues which come up in the client environment. To fix those issues patches are released.
Also to enhance the product some better versions are released. Maintenance is done to deliver these changes in the customer environment.

19. Waterfall model phases
All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a waterfall) through the phases.
The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".

20. Waterfall Model Application
Some situations where the use of Waterfall model is most appropriate are:
Requirements are very well documented, clear and fixed.
Product definition is stable.
Technology is understood and is not dynamic.
There are no ambiguous requirements.
Ample resources with required expertise are available to support the product.
The project is short.

21. Advantage
The advantage of waterfall development is that it allows for departmentalization and control.
A schedule can be set with deadlines for each stage of development and a product can proceed through the development process model phases one by one.
Each phase of development proceeds in strict order.

22. Disadvantage
Inflexible partitioning of the project into distinct stages
It does not allow for much reflection or revision.
This makes it difficult to respond to changing customer requirements.
Once an application is in the testing stage, it is very difficult to go back and change something that was not well-documented or included in the concept stage.
Little opportunity for customer to preview the system.

23. V- model V- model means Verification and Validation model.
Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes.
Each phase must be completed before the next phase begins.  Testing of the product is planned in parallel with a corresponding phase of development.

24. V- model

25. The various phases of the V-model
Requirements like BRS and SRS begin the life cycle model just like the waterfall model. But, in this model before development is started, a system test plan is created.
The high-level design (HLD) phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.
The low-level design (LLD) phase is where the actual software components are designed. It defines the actual logic for each and every component of the system. Component tests are created in this phase as well.

26. The implementation (Coding) phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.
Code: This is at the bottom of the V-Shape model. Module design is converted into code by developers.

27. Advantages of V-model Simple and easy to use.
Testing activities like planning, test designing happens well before coding. This saves a lot of time.
Higher chance of success over the waterfall model.

28. Disadvantages of V-model
Very rigid and least flexible.
Software is developed during the implementation phase, so no early prototypes of the software are produced.
If any changes happen in midway, then the test documents along with requirement documents has to be updated.

29. When to use the V-model
The V-shaped model should be used for small to medium sized projects where requirements are clearly defined and fixed.
The V-Shaped model should be chosen when ample technical resources are available with needed technical expertise.
High confidence of customer is required for choosing the V-Shaped model approach. Since, no prototypes are produced, there is a very high risk involved in meeting customer expectations.

30. Incremental Life cycle model
In incremental model the whole requirement is divided into various builds.
Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. 
Cycles are divided up into smaller, more easily managed modules.  Each module passes through the requirements, design, implementation and testing phases.
A working version of software is produced during the first module, so we have working software early on during the software life cycle.
Each subsequent release of the module adds function to the previous release. The process continues till the complete system is achieved.

31. In the diagram above when we work incrementally we are adding piece by piece but expect that each piece is fully finished. Thus keep on adding the pieces until it’s complete.
As in the image above a person has thought of the application. Then he started building it and in the first iteration the first module of the application or product is totally ready and can be demoed to the customers. Likewise in the second iteration the other module is ready and integrated with the first module. Similarly, in the third iteration the whole product is ready and integrated. Hence, the product got ready step by step.

32. Incremental Life cycle model

33. Advantages of Incremental model
Generates working software quickly and early during the software life cycle.
This model is more flexible – less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
In this model customer can respond to each built.
Lower risk of overall project failure

34. Disadvantages of Incremental model
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.
Total cost is higher than waterfall.

35. When to use the Incremental model
This model can be used when the requirements of the complete system are clearly defined and understood.
Major requirements must be defined; however, some details can evolve with time.
There is a need to get a product to the market early.
A new technology is being used
Resources with needed skill set are not available

36. Prototyping Model
The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements.
This prototype is developed based on the currently known requirements.
By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system. 

37. Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements.
The prototype are usually not complete systems and many of the details are not built in the prototype. The goal is to provide a system with overall functionality.

38. Prototyping Model

39. Advantages of Prototype model
Users are actively involved in the development
Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.
Errors can be detected much earlier.
Quicker user feedback is available leading to better solutions.
Missing functionality can be identified easily

40. Disadvantages of Prototype model
Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.
Incomplete application may cause application not to be used as the full system was designed incomplete or adequate problem analysis.

41. When to use Prototype model
Prototype model should be used when the desired system needs to have a lot of interaction with the end users.
Typically, online systems, web interfaces have a very high amount of interaction with end users, are best suited for Prototype model.
They are excellent for designing good human computer interface systems.

42. Spiral model
The spiral model is similar to the incremental model, with more emphasis placed on risk analysis.
The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. 
A software project repeatedly passes through these phases in iterations (called Spirals in this model).
The baseline spiral starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

43. Planning Phase: Requirements are gathered during the planning phase
Planning Phase: Requirements are gathered during the planning phase. Requirements like ‘BRS’ (‘Business Requirement Specifications’) and ‘SRS’ (‘System Requirement specifications’).
Risk Analysis: In the risk analysis phase, a process is undertaken to identify risk and alternate solutions.  A prototype is produced at the end of the risk analysis phase. If any risk is found during the risk analysis then alternate solutions are suggested and implemented.
Engineering Phase: In this phase software is developed, along with testing at the end of the phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

44. Spiral Model

45. Advantages of Spiral model
High amount of risk analysis hence, avoidance of Risk is enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.
Software is produced early in the software life cycle.

46. Disadvantages of Spiral model
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.

47. When to use Spiral model
When costs and risk evaluation is important
For medium to high-risk projects
Users are not sure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

48. Measurement & Metrics

49. Need of Measurement Software is measured to:
Establish the quality of the current product or process.
To predict future qualities of the product or process.
To improve the quality of a product or process.
To determine the state of the project in relation to budget and schedule.

50. Measurement & Metrics
A measurement is an indication of the size, quantity, amount or dimension of a particular attribute of a product or process.
For example the number of errors in a system is a measurement
A Metric is a measurement of the degree that any attribute belongs to a system, product or process.

51. Metrics to quantify software development
Type & orientation of Metric
Technical
Quality
Productivity
Human Interface
Correctness Y N
Reliability
Efficiency
Maintainability
Flexibility
Testability
Portability
Reuse
Utility
Size
Y- Applicable
N- Not applicable

52. Software metric Product metric Process metric Project metric
Software measurement gives rise to software metrics.
Software metric
Product metric
Process metric
Project metric

53. Project metrics describe the project characteristics and execution.
Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level.
Process metrics can be used to improve software development and maintenance.
Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival, and the response time of the fix process.
Project metrics describe the project characteristics and execution.
Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule and productivity.
Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process metrics and project metrics.

54. Software quality metrics
Software quality metrics is “A measure of some property of a piece of software or its specifications”.
Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project.

55. Software quality is divided into 2 levels:
Intrinsic product quality metrics
customer satisfaction metrics

56. Intrinsic product quality
Intrinsic product quality is usually measured by the number of “bugs” (functional defects) in the software or by how long the software can run before encountering a “crash.”

57. Customer Satisfaction Metrics
Customer satisfaction is often measured by customer survey data via the five-point scale:
Very satisfied
Satisfied
Neutral
Dissatisfied
Very dissatisfied.
Satisfaction with the overall quality of the product and its specific dimensions is usually obtained through various methods of customer surveys.

58. Mars Climate Orbiter
The Mars Climate Orbiter / Mars Surveyor '98 Orbiter was a robotic space probe launched by NASA on December 11, 1998 to study the Martian climate, atmosphere, and surface changes.
On September 23, 1999, communication with the spacecraft was lost as the spacecraft went into orbital insertion, due to ground-based computer software which produced output in non-SI units of pound-seconds (lbf×s) instead of the metric units of newton-seconds (N×s) specified in the contract between NASA and Lockheed.
The spacecraft encountered Mars on a trajectory that brought it too close to the planet, causing it to pass through the upper atmosphere and disintegrate.

59. The primary cause of this discrepancy was that one piece of ground software supplied by Lockheed Martin produced results in a United States customary unit ("American"), contrary to its Software Interface Specification (SIS), while a second system, supplied by NASA, that used those results expected them to be in metric units, in accord with the SIS.
The discrepancy between calculated and measured position, resulting in the discrepancy between desired and actual orbit insertion altitude

60. Ariane 5 (1996 explosion)
Ariane 5’s Purpose: delivering satellite to space
Control system of Ariane 5 composed of:
An inertial reference system (SRI)
An On-Board Computer (OBC)
Rocket exploded around 40 seconds after lift-off.
Failure due to SRI software exception
Exception caused due to a data conversion

61. Issues
For developing a safe and reliable system, types of faults and failures must be identified and how they can occurs.
Software doesn’t conform to conventional or natural boundaries of stability, it can jump from zero to infinity in single step.
Failures may have multiple sources.
Safety and reliability are system concerns, not concern of software alone.

62. Development Plan
Software faults affect safety , fault tolerance and reliability of the system and product.
Careful plan reduces the risk from software failure.
A plan for software should specify how to handle requirements, design, development, reviews, tests and documentation.

63. A good development plan should:
Certain inputs shape the requirements like product goals, market constraints, prototype results hazard or risk analysis.
A good development plan should:
Identify the risk
Set priorities for criticality
Prepare management and resolution strategies
Monitor the risk during development

64. Guidelines for Development plan of software
Keep the program size as small as possible.
Keep the design of program as simple as possible.
Reduce the development time beyond the specified limits.
Keep team size as small as possible.
High efficiency software tools, methods & techniques should be used

65. Safety & Reliability
Efficient techniques & methods can produce safe & reliable software.
Develop a complete plan
Select safety and reliability requirements according to the application.
Identify bugs & errors
Identify the method to remove bugs & errors

66. 3 ways to improve reliability:
Describe in mathematical form or logical terms.
Systematic Management
Limiting software role
Guidelines for reliable software development
Make each module independent
Reduce the complexity of each task
Isolate task from external influence, both hardware and timing
Proper communication should be present between tasks

67. Fault tolerance
It defines how a system prevents or respond to bugs, errors, faults or failure.
Software are discrete, non linear systems. A single operation can drastically change output.
Failure of Safety-critical systems can lead to equipment damage, environmental harm, injury or death.
Safety-critical systems requires Fail-safe mechanism.

68. Fail-safe mechanism include:
Detection and correction of faults
Fallback modes that limits equipment function
Proper notification of faults
Examples:
Cyclic redundancy checks on data communication
Watchdog timer

69. Watchdog timer
Watchdog timer is a hardware that monitors a system characteristic to check the control flow.
If it detects any fault it generates a logic pulse and inform the processor.
Example: Suppose software is programmed to reset the count after a particular interval of time. Watchdog timer wait for a time interval and after this generate the logic pulse that indicates a fault, that software has hang up in a particular operation.

70. Faults in embedded software
Sensor may produce signal exceed the specified limits or too large.
Operator entered an Alphabetic character instead of number
Once a system detects fault it must respond appropriately.
Real time systems can use roll back recovery (reconstructing previous state) or roll forward recovery.
System having watchdog timers may use either roll back recovery, roll forward recovery or both to respond to a detected fault.

71. Software bug
It is an error, flaw, failure or fault in a computer program or system.
It produce an incorrect or unexpected result
Bugs arise from mistakes and errors made by people in either a program's source code or its design, or in frameworks and operating systems used by such programs and a few are caused by compilers producing incorrect code.
A program that contains a large number of bugs is called buggy.
Reports detailing bugs in a program are commonly known as bug reports, defect reports, fault reports.

72. Phases of Bug Introduction
Bugs can be generated because of
Incorrect conceptual design
Incorrect assumptions
Phases of Bug Introduction
Bug can enters in software in any of 4 stages:
Intent or (during requirement phase)
Translation
Execution
Operation

73. Intent S.N. Types Comments 1 Wrong Assumptions or misunderstanding
Insufficient grasp of the problem 2
Problem definition
Correctly solving the wrong problem 3
Sizing
Limits on operation too broadly or too narrowly

74. Translation S.N. Types 1 Incorrect algorithm 2 Incorrect Analysis 3
Misinterpretation

75. Execution S.N Types Comments 1 Semantic error
Failure to understand how command works 2
Syntax error
Failure to follow-
Rules of language
Terminate statement
Terminate procedure 3
Logic error
Wrong decision, branch to wrong label, improper initialization or termination of loop 4
Range error
Failure to predict the possible calculation, incorrect approximation

76. Execution S.N Types Comments 5 Truncation error
Incorrect rounding of calculation 6
Data error
Failure to predict the possible range of data or data types
Not initializing or setting size of array 7
Misuse of language
Coding operation inefficiently or incorrectly 8
Documentation
Wrong or mismatching comments

77. Operation S.N Types Comments 1 Changing paradigm
System operating in an unanticipated environment 2
Interface error
Incorrect type or range of input and output 3
Performance
Inadequate hardware resource or software timing 4
Hardware failure
Failure or incorrect functioning of subsystem 5
Human error

78. Debugging
Embedded devices must run for months without crashing, within strict memory and processing limits and can have real-world interactions.
Software debugging is one of the major tasks of programming.
When the results of a program are examined, errors may be found through the discovery of their effects.

79. Hardware for embedded software debugging Logic analyzer Oscilloscope
In-circuit emulator (ICE) :
It is a hardware interface that allows a programmer to change or debug the software in an embedded system.
The ICE is temporarily installed between the embedded system and an external terminal or personal

80. In-circuit emulator (ICE)

81. Debugger
“A software tool that is used to detect the source of program or script errors, by performing step-by-step execution of application code and viewing the content of code variables.”

82. Debugging is the activity of finding the causes that produced undesirable program effects.
Debugging technique
Tracer
Controlled
Execution

83. Tracing Technique Procedure for tracing technique: Run program
Save states of the program
Find cause of program's malfunction ( bug)

84. Controlled Execution Procedure for tracing technique-
Pause program execution at breakpoints.
At breakpoint, study the state of the program.
Faulty program is executed and debugged through many cycles until the fault is localized and fixed.

85. Once errors are identified in a software system, to debug the problem, steps are
Defect confirmation/identification: A problem is identified in a system and a defect report is created. A software engineer maintains and analyzes this error report and finds solutions to the following questions.
Does a defect exist in the system?
Can the defect be reproduced?
What is the expected/desired behavior of the system?
What is the actual behavior?

86. Guidelines for debugging
Individuals involved in debugging should understand all the causes of an error before starting with debugging.
No experimentation should be done while performing debugging. The experimental changes instead of removing errors often increase the problem by adding new errors in it.
When there is an error in one segment of a program, there is a high possibility that some other errors also exist in the program.
It should be ensured that the new code added in a program to fix errors is correct and is not introducing any new error in it.

87. Check list for
code inspection

88. Check list for
code inspection

89. Style
guidelines

90. The user interface
User interface is the front-end application view to which user interacts in order to use the software.
User can manipulate and control the software as well as hardware by means of user interface.
User interface is present at almost every place where digital technology exists.
Examples computers, mobile phones, cars, music players etc.

91. The user interface
System users often judge a system by its interface rather than its functionality
A poorly designed interface can cause a user to make errors and serious issues.
Poor user interface design is the reason why so many software systems are never used

92. UI design

93. The UI design process
UI design is an iterative process involving interaction between users and designers.
The 3 core activities in this process are:
User analysis: Understand what the users will do with the system
System prototyping: Develop a series of prototypes for experiment
Interface evaluation: Evaluate these prototypes with users.

94. UI design principles
UI design must take account of the needs, experience and capabilities of the system users.
Designers should be aware of people’s physical and mental limitations (e.g. limited short-term memory) and should recognise that people make mistakes.

95. User Interface Design Principles
Description
User familiarity
Use terms and concepts familiar to the user.
Consistency
Comparable operations should be activated in the same way. Commands and menus should have the same format, etc.
Minimal surprise
If a command operates in a known way, the user should be able to predict the operation of comparable commands.
Feedback
Provide the user with visual and auditory feedback, maintaining two-way communication.

96. Principle Description
Memory load
Reduce the amount of information that must be remembered between actions. Minimize the memory load.
Efficiency
Seek efficiency in dialogue, motion and thought. Minimize keystrokes and mouse movements.
Recoverability
Allow users to recover from their errors. Include undo facilities, confirmation of destructive actions, 'soft' deletes, etc.
User guidance
Incorporate some form of context-sensitive user guidance and assistance.

97. Advantages of UI Problems They are easy to learn and use.
Users without experience can learn to use the system quickly.
The user may switch attention between tasks and applications.
Fast, full-screen interaction is possible with immediate access to the entire screen
Problems
A GUI is not automatically a good interface
Many software systems are never used due to poor UI design
A poorly designed UI can cause a user to make catastrophic errors

98. RTOS

99. Kernel
Kernel is a computer program that manages I/O(input/output) requests from software and translates them into data processing instructions for the CPU.
A kernel connects the application software to the hardware of a computer.
Its main task are:
Executing processes
Handling interrupts

100. real-time task scheduling algorithms based on how the scheduling points are defined.
The three main types of schedulers according to this classification scheme are:
Clock-driven
Event-driven
Hybrid.

101. Real-time task scheduling
Real-time task scheduling algorithms based on how the scheduling points are defined.
1. Clock Driven
Table-driven
Cyclic
2. Event Driven
Simple priority-based
Rate Monotonic Analysis (RMA)
Earliest Deadline First (EDF)
3. Hybrid
Round-robin

102. The clock-driven schedulers are those in which the scheduling points are determined by the interrupts received from a clock.
In the event-driven ones, the scheduling points are defined by certain events which precludes clock interrupts.
The hybrid ones use both clock interrupts as well as event occurrences to define their scheduling points.

103. Clock-driven schedulers
The clock-driven schedulers are those in which the scheduling points are determined by the interrupts received from a clock.
Advantages:
Simple to write, debug & analyze.
Good for high speed data channels.
Disadvantages:
Fails to handle burst of events.
Require more CPU cycle

104. Table-driven schedulers
Table-driven schedulers usually pre-compute which task would run when, and store this schedule in a table at the time the system is designed or configured.
An Example of a Table-Driven Schedule

105. Cyclic schedulers
Cyclic schedulers are very popular and are being extensively used in the industry.
A large majority of all small embedded applications being manufactured presently are based on cyclic schedulers.
Cyclic schedulers are simple, efficient, and are easy to program.

106. Cyclic schedulers Example : Temperature controller.
A temperature controller periodically samples the temperature of a room and maintains it at a preset value. Such temperature controllers are embedded in typical computer-controlled air conditioners.

107. Event Driven Schedulers
In the event-driven schedulers, the scheduling points are defined by certain events which precludes clock interrupts.
It uses event interrupt to control program flow.
It services interrupts by context switching or saving CPU register states.
Context switching
Context switch is the process of storing and restoring the state of a process or thread so that execution can be resumed from the same point at a later time.

108. Types of Event Driven Schedulers
Simple priority-based
Earliest Deadline First (EDF)
Rate Monotonic Analysis (RMA)
Deadline Monotonic Algorithm (DMA)

109. Earliest Deadline First (EDF)
In Earliest Deadline First (EDF) scheduling, at every scheduling point the task having the shortest deadline is taken up for scheduling.

110. Rate Monotonic Algorithm(RMA)
This is a static priority algorithm and is extensively used in practical applications.
RMA assigns priorities to tasks based on their rates of occurrence. The lower the occurrence rate of a task, the lower is the priority assigned to it.
A task having the highest occurrence rate (lowest period) is accorded the highest priority.

111. Priority assignment to the task in RMA

112. Deadline Monotonic Algorithm (DMA)
DMA is essentially a variant of RMA.
It assigns priorities to tasks based on their deadlines, rather than assigning priorities based on task periods as done in RMA.
DMA assigns higher priorities to tasks with shorter deadlines.