School of Information Technology and Engineering (SITE) SEG 4105: Software Project Management, Fall 2011 Assignment 1 Solution

Q1 Since the estimates are not drastically different (say, by an order of magnitude), and we are estimating the most important component of the software, the Project Managers choice becomes less of a technical one, and more a question of being on the safe side, as long as were not overprotecting. To reduce risks, you should go with the worst case scenario of 5000 LOC. An experienced PM would not squander efforts in technical analysis in this case. Q2 Assumption: a person works an average of 20 days a month (excluding weekends and holidays) Now, 250 staff-days = 250/20 staff-months = 12.5 staff-months = Effort (E) In COCOMO, for Basic Semiattached, we know: E = 3.0 Size1.12 TDEV = 2.5 E0.35 So, for the size of the software, we get: 12.5 = 3.0 Size1.12 Size = 3.576 KLOC = 3576 LOC For the development time of the software, we get: TDEV = 2.5 E0.35 = 2.5 12.5 0.35 = 6.1 months Q3 Usually military projects where both documentation and process are very formal and necessary. Also, in some cases, if you are developing software very similar (almost like a duplicate) to what you have developed before, a Waterfall approach might be suitable Q4 a) More resources can speed up things that are potentially doable in parallel. But not everything can be done in parallel. For example, if component A is dependent on component B, then these two components can not be developed in parallel, no matter how much resources are allocated to the development phase. In addition, a given component needs a minimum amount of time to be developed because a certain number of correct lines of code must be written. This takes a minimum amount of effort and time and it simply cannot be less than that.

b) The reasoning is two-fold: learning curve for newcomers, and increased communication overhead between a now larger number of people. Q5- The idea is to aim at the goal. While in reality the goal does become a moving target, it is important to always point towards it. If we have a good start, as opposed to an ad-hoc start, we will have to make fewer adjustments in terms of time, scope, budget and resources. Even if the requirements change drastically, the work on requirements gathering, WBS, estimation, planning will help us make risks evident early. By requirement change management, duties are clear to customers and project team, which prevents conflicts and disputations in the future. Q6- In SPM, the term Death March refers to a project that is destined to fail due to having unrealistic or exceedingly optimistic expectations in time, scope or cost. The ruleof-thumb for determining that a project is a death march is to calculate the required time, budget, and effort (lets call it the calculated reality), and then observe the project parameters and whether any one of them overrides the calculated reality by 50% or more. For example: the schedule imposed by marketing is 50% shorter than the required time; the amount of work (features) promised is 50% greater than doable; the size of the staff provided by the company is only half as large as necessary; the budget available is 50% less than needed

If any of the above applies, the project is considered a death march project as it is destined to fail. Q7 - Project Charter is a document that formally recognizes the existence of a project. It provides the PM with the authority to apply organizational resources to the project (Spend $$$). It defines the project scope and objectives (what the product is, what it is not) - not to be confused with Requirements. The Charter validates the business justification (ball-park estimates that provide reason for project existence). It contains the definition of the authority of the PM; what he can and cannot do (rights and obligations of the PM). For instance, right to reset plan, when requirements are changed. It also details the Level of Quality to be expected; and it highlights risk. Finally, it describes conflict resolution mechanism (i.e. using an arbiter).