Question One

Part A

Project Evaluation and Review Technique, popularly known as PERT, is a strategy used to present project activities in a timely and organized manner. Usually, activities are organized chronologically and in order of their priority. Activities that should be carried out first, for example, understanding the business model and requirement gathering are prioritized. Activities that rely on others come after such activities or processes have been accomplished. For instance, system actualization comes after the conceptual design has been approved. With the help of this technique, software developers and project management experts can effectively prioritize activities, assign time and other essential resources effectively. At the end of the day, the project execution phase is streamlined lowering the cost of development of actualization, while minimizing overall resource utilization.

Usually, slack time denotes how much time an activity can be delayed beyond the planned date. For instance, if an activity, say, system design is scheduled to start on day 10 and should take 3 days, a consideration is made on the end date if the activity is started on day 12. In this case, the scheduled start and end days are 10 and 13 respectively. In case of a delay, the days change to 12 and 15 respectively. To get the slack time, we compute the difference between the schedule and delayed end dates, which is 2 in our case. The critical path is a complement to PERT and computes the longest possible path, time, or route that is possible when accomplishing the scheduled activities and tasks of a project. In other words, slack time is simply the additional time in which a given project or activity can be delayed for delivery if it is not started on the scheduled date or as agreed.

Part B

Developers use pull requests to notify other contributors that they have made a change to the code of an existing project in a collaborative environment. Usually, the changed code is not merged with the existing code and is subjected to review by other contributors. This helps ensure that the changed code solves a problem, adds a useful feature, and fixes an existing bug in the old code. Once the change has been reviewed and accepted, the changed code is then merged with the other code. If the change is not accepted, the pull request is discarded or ignored. File editing in a collaborative environment can be complicated, especially where multiple people have been granted the privilege to create and edit files. This is usually the case with GitHub organizations where different developers can work on the same project concurrently. However, not every change should be accepted to organizational files. As a result, once one has made a change to a file, they must notify the others and the changes are hence reviewed. The actions are taken thereafter depend on the acceptability of the changes proposed therein.