Section 2.6. Project Management Tasks


2.6. Project Management Tasks

After the compiler, build tools, and third-party products used by the application are ascertained to exist or have similar equivalents in Linux, the next step is to scope and identify deliverables and tasks of the project. As the application architecture is examined more closely in terms of lines of code, number of modules, third-party software, testing methodology, packaging, and others, the work required to port the application begins to emerge. The project manager identifies what is in and out of scope for the project at hand. Refer to Chapter 1 to learn why it is important to identify not only what is in scope but also what is out of scope. After the scope has been identified, deliverables, tasks, preliminary schedules, and other factors that are all part of overall project plan are filled in. Each one is briefly discussed in the following list:

  • Deliverables

    Each porting project has deliverables, and each deliverable has tasks associated with it. Use a form similar to Table 2-2 that associates tasks with each project deliverable. The table clearly states the task's start and due dates as well as its owner.

Table 2-2. How to Associate Tasks to Each Identified Deliverable

Activities/Tasks

Start Date

Due Date

Owner

Status

Comments[*]

Deliverable 1

     

Task 1

     

Task 2

     
      

Deliverable 2

     

Task 1

     

Task 2

     


[*] The Comments column can contain descriptions of issues and dependencies for each deliverable or task.

  • Success criteria

    The success criteria for each deliverable can be as simple as passing a unit test. Put in place success criteria for each deliverable that will be used to signal the completion of the tasks.

  • Project start and end dates

    Identify the project start and end dates based on the tasks associated with the deliverables. These start and end dates give the project stakeholders a sense of how long the project will take. Sometimes there may be hard requirements to start or end the project within a certain time frame. In this case, deliverables and tasks need to be revisited to see whether they need to be adjusted to fit the schedule.

  • Required resources

    After the tasks for each deliverable are identified, the specific skills needed to do these tasks become known. Identify skilled and experienced personnel as well as hardware requirements. In addition to identifying these resources, ascertain when and how long these resources are required.

  • Critical dependencies

    Identify critical dependencies, including when they are needed and from whom they are coming.

  • Risks

    Identify the risk factors that can affect the project schedule, cost, or scope. An example of a risk that may affect the schedule can come from a critical dependency where delivery of this dependency may be delayed because of certain unforeseen events. This delayed delivery can then in turn affect the overall schedule.

  • Status communication

    Last but not least, create a communication process that addresses who, when, and how frequently communication of project status needs to happen.

The collaboration between porting personnel who scope the application and the project manager is crucial. Information gathered from scoping the application affects the project's scope and sometimes even its viability. Identifying key elements such as compilers, build environment, and third-party product dependencies helps fill in the necessary elements that make up the porting project.




UNIX to Linux Porting. A Comprehensive Reference
UNIX to Linux Porting: A Comprehensive Reference
ISBN: 0131871099
EAN: 2147483647
Year: 2004
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net