| dc.description.abstract | In this project, a software called the Scheduler Simulator was created to simulate
task executions given a specified real-time scheduler. Existing similar simulators
were examined and evaluated, reusable functionality best fitted to be adopted
by this projects simulator software was identified. Whereas all the existing solutions
have strengths and weaknesses, the following properties were extracted:
limit the end-users responsibilities, create thorough documentation, use Gantt
charts with clearly marked deadline misses, and provide relevant and readable
simulation results. Best practices related to software development, such as software
development methods, documentation development and software design, have been
researched. In addition, other relevant theory related to real-time systems and
schedulers was also examined. To develop the Scheduler Simulator, the best practices
were evaluated. For the Scheduler Simulator project, the development was
conducted using mainly iterative and incremental methods, influenced by sprints
from Scrum development, emphasizing the flexibility and simplicity described by
Agile development methodologies.
The Scheduler Simulator allows a user to implement new scheduling policies,
create and generate task sets and conduct simulations to generate relevant reports.
The resulting reports contain CPU idle time, the number of reached and missed
deadlines, the number of completed tasks, and a Gantt chart, visually presenting
the simulated task executions. Four schedulers were implemented in the software:
FIFO, RR, RM and EDF. A series of test runs of the Scheduler Simulator were
conducted and evaluated. The simulator behaved as expected. It was discovered
that when simulating more than 20 tasks, the Gantt chart overshot the page size of
the result report. As a reaction to this, the simulator was altered to not produce
Gantt charts for simulations where the task set exceeded 20 tasks. The documentation
created for the system consists of three main parts; one for requirements,
one describing the architectural design of the software, and one for the users. "The
users" here refers to both maintenance personnel and end-users.
As the project was conducted by one person, the social benefits from using
Scrum and other Agile development methodologies diminished greatly. Instead, the
development work converged towards a waterfall shaped structure, as a sequential
work model can be more appealing and natural when working alone than a parallel
and cyclic model. The iterative way of working still helped the developer to learn
from mistakes along the way and create a functional system. | |
