Information system analysis and design Dr. Dina Tbaishat

Recap Last lecture we learnt how to write the requirements document, according to the IEEE standard Today we shall continue on discussing a new topic related to project management For projects and systems’ development to succeed, they must be well managed and supervised

Project management - Introduction Project management is needed since there are always budget and schedule constraints Project managers should plan and schedule the project, they should also make sure projects are carried out according to the required standards The project manager’s job description varies according to the product type and to the organization itself The main responsibilities of a project manager are:

Management activities According to Sommerville (2001) these are: Proposal writing: to describe the objectives, how it will be developed, usually includes costs / schedule estimates. This is a task acquired by experience Project planning and scheduling: identifying activities, milestones and deliverables. Critical Path Analysis is one way for planning and scheduling, which shall be discussed in detail next lecture

Project costing: determine how much of the budget is needed to complete the project. Costs include all required resources Project monitoring and reviews: keeping track of the project, is it going according to the schedule? Within the costs? During a project, reviews take place by “reviewing overall progress and technical development of the project and considering the project’s status against the aims of the organization commissioning the software” (Sommerville, 2001)  accommodating new changes emerging within the organization

Personnel selection and evaluation: choosing staff to work in the project, the selection should not be always ideal for the following reasons: Low budget Staff with appropriate experience may not be available Might want to work on developing employees’ skills Report writing and presentations: to the client. Should write concise and coherent document explaining details of the project

Project planning Planning well for a project avoids failure Project planning is an iterative process that ends only when the project ends The plan must be regularly reviewed There are different types of plans that managers can draw up, these are: Quality plan: the standards that will be used in the project Validation plan: the methods, resources and schedule for system validation (testing)

Configuration management plan: process for establishing and maintaining consistency of a product's performance, requirements, etc… used in large complex systems such as weapon systems Maintenance plan: predict maintenance costs and effort Staff development plan: how to develop staff skills and experience According to Sommerville (2001), most plans should include the following sections:

Introduction: objectives Project organization: organizing the team, their roles Risk analysis: possible risks, their probabilities and management (to be discussed in more detail next lecture) HW and SW resource requirements Work breakdown: breakdown of project into activities Project schedule: dependencies between activities Monitoring and reposting mechanisms: what reports to produce

Milestones and deliverables Milestone: an end point of a process activity, where there should be a formal output (such as a report) Reports do not need to be large, only to present the achievement of a project activity Deliverable: a project result to be delivered to the customer Usually delivered at the end of major stages such as design “Deliverables are usually milestones but milestones need not be deliverables” (Sommerville, 2001)

Work Breakdown Structure (WBS) This is a method that helps in identifying tasks within a project. This in turn helps later when using the network method, hence finding the critical path Decomposing big tasks into their component smaller tasks, when reaching an appropriate level of detail, stop decomposing Take into consideration:

The splitting of major tasks should be logical It should be possible to test objectively when the work is complete At the lowest level the work elements should be well defined tasks for one individual to perform within a reasonable period – say from a day to a week

This is an example that is taken from (Open University, 2012):

So the previous WBS shows the first step, trying to decompose the project objective “refurbish hospital ward” into major “packages’’ of work in logical way. The next step however is to decompose each work “package” into some components tasks as follows:

After the tasks were identified by the WBS, it is time to list them and put them in order according to “priorities” It is also important to determine which tasks need to finish before other tasks can begin (predecessor) So, some tasks must be done before others can start, for example, is it not possible to remove furnishings (beds, lockers, chairs, etc…) until there are no patients using them. Usually, early tasks don’t have predecessors The list created in the next table on the following slide may be sufficient, but it’s always better to proceed to graphical form

From here, how do we draw the network From here, how do we draw the network??? This is to be learnt next lecture !

References Open University. (2011). Team work in distributed environment: Project planning and scheduling, [Lecture notes] Sommerville, I. (2001). Software Engineering. UK: Addison Wesley