TT284 Web Technologies Tutorial 11 PDF

4/11/2015 TT284: Web Technologies 1 Arab Open University TT284 WEB TECHNOLOGIES Tutorial 11 By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies...

4/11/2015 TT284: Web Technologies 1 Arab Open University TT284 WEB TECHNOLOGIES Tutorial 11 By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 2 Block 4 Managing application development By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 3 introduce you to some of the important concepts and techniques associated with managing the development of a web application. The key question addressed in the block is how you ensure that a web application is always available to users. In this Block 4: Block 4, Part 1 ‘Maintaining service’ introduces some basic definitions and reviews the key factors that influence the availability of a web application and explores how performance can be maintained through the use of fault tolerance, load sharing, and virtualisation. Block 4, Part 2 ‘Managing projects’ explores the management of a web application through the development of a project plan. Building on the software development life-cycle, it describes how the plan is used to communicate the project’s requirements for quality, resources, and risks. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 4 Optional, self-study 1. Block 4, Part 3 ‘Managing assets’ 2. Block 4, Part 4 ‘Practical version control’ Block 4, Part 5 ‘System testing’ explores the part that testing plays in the ensuring the quality and reliability of an application. Building on the life cycle, it describes the activities to be undertaken as development proceeds through unit, integration, and system test phases, leading to the development of a test plan. Block 4, Part 6 ‘System Security’ examines why web applications become vulnerable to attack when poor coding goes undetected or servers are not configured correctly. It also looks at how web servers implement access controls through authentication and authorisation, and use encryption to safeguard data. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 5 Block 4, Part 2: Managing projects Contents 1 Introduction 2 Learning outcomes 3 A project perspective3.1 Opportunities and risks 3.2 The project plan 3.3 Lifecycle models 3.4 The agile alternative 3.5 The OURC case study 4 The project plan4.1 Monitoring performance 5 Requirements 6 Quality 7 Resources and time 8 Risk management By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 6 At this point in the module, a rich variety of applications made possible by web technologies. For example you can buy and sell goods, socialise and role play, shop and gamble, invest, or vote and pay your taxes. Every application represents an investment of skills and resources over a period of time, but with that investment comes the risk that things don’t work out as planned; therefore organisations must continually balance the benefits against the risks. Project management is a field of study that brings together a wide range of techniques and tools for managing any development activity. It can help to organise the tasks and manage the resources so that an application gets completed on time, on budget, and most importantly, fulfils its requirements. The goal is to pick out a few topics from project management that will help you when it comes to tackling your own projects. You will need to read the background material provided on the module website. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 7 3 A project perspective Many of the best known web applications have started small, perhaps the brainchild of a single developer. Google Inc. was set up in 1998 by Larry Page and Sergey Brin, postgraduate students at Stanford University, and the early development work was undertaken in a garage (Google, 2012a). Facebook LLC was formed in April 2004 by Mark Zuckerberg based on code he developed in his Harvard University dorm-room (Carlson, 2010). Parkrun, a website that organises free, weekly, 5-km timed runs throughout the world, was also the product of a single developer, Paul Sinton-Hewitt, and grew from a personal interest into something much larger (Parkrun, 2012). What these applications have in common is that as they grew in scale and functionality they needed better organisation and planning; sorting out the work to be completed, who would do it, and when it would be done. Any web application has a finite life during which a unique set of skills, techniques, tools and resources are brought together to achieve a specific set of goals; they are what we term projects. The Project Management Institute’s (PMI) defines a project as:… a temporary endeavour undertaken to create a unique product, service, or result. two other definitions: By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 8 A project in business and science is typically defined as a collaborative venture, frequently involving research or design that is carefully planned to achieve a particular aim. Projects can be further defined as temporary rather than permanent social systems that are constituted by teams within or across organizations to accomplish particular tasks under time constraints. project management, has its own set of tools and techniques such as Gantt charts, PERT (programme evaluation and review technique), and work breakdown structure. Today project management has gained recognition from many of the major standardisation bodies such as the American National Standards Institute (ANSI), International Organisation for Standardisation (ISO), and Institute of Electrical and Electronics Engineers (IEEE). 3.1 Opportunities and risks As a general rule all projects are a combination of opportunities and risks. The opportunities might be linked to launching a new product, building a factory, or creating a new web application. By undertaking the project the business hopes to increase revenue, become more efficient, and make a profit. At the same time the project presents the business with risks because it may not be completed on time, it may cost more than estimated, or it may not produce the desiredBy:result. Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 9 IT projects have gained a reputation for grand failures. studies Unfortunately have shown some common features: A lack of end-user involvement in specifying the goals and requirements can leave projects without a champion to drive the solution, or at worst outright hostility to what is seen as imposed change. End-users may regard the project as additional work outside their normal tasks. Commitment from senior management is essential to ensure resources are made available and work priorities established. Long or unrealistic timescales can lead to project outcomes that fail to meet business requirements. If the timescales are long the business requirements may change before the project can be completed. To counteract this short timescales may be imposed leaving insufficient time to complete the project. Vague or inadequate requirements can result from lack of user input, leaving developers to create their own interpretation of the solution. The inevitable result is a solution that fails to meet business needs or fulfil users’ expectations. Poor change management controls may permit users to request new features as the project proceeds thereby increasing the work that has to be completed. This growth in the scale of a project is commonly referred to as scope creep and is closely linked to vague or inadequate requirements. Changes in business needs are inevitable, but they must be carefully managed to ensure a project can complete on time and within budget. Inadequate testing throughout the project often occurs because testing activities are dropped in the belief that it will allow a project to complete on time. This is most prevalent toward the end of the project when all constituent elements must be in place before the final acceptance testing occurs. Acceptance tests must be carefully planned with specific objectives that link to the business requirements. Sufficient time must be allowed for testing and possibly the provision of training for those who will undertake the tests. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 10 3.2 The project plan Good project management strives to find a balance between a project’s requirements and quality on one side and the resources, time, and risks on the other. The proposed solution is typically expressed in the form of a project plan that documents what is to be done, who will do it, and when it will done. The requirements are what define the outcomes of the project, but at a level of detail sufficient to enable an estimate of the resources necessary to complete on time and to the appropriate quality. In some cases the requirements may specifically exclude features, perhaps reserving them for the future. The quality will define the standards or measures by which the project outcomes will be judged. At a high level this may mean passing specific functional tests, whilst at a low level it may dictate the use of coding or validation standards. The resources represent the people and equipment essential to deliver the project outcomes on time and to budget. People will need the appropriate skills and the equipment must be available when required. The time element captures both the sequence of the tasks to be undertaken and the total duration of the project. The risks define in advance what may happen to drive the project off course, and what will be done to recover the situation. Do Activity 1. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 11 3.3 Lifecycle models one of the most helpful to project management is the lifecycle of a project that is the sequence of major activities, or phases of work, from the start to the end of a project. The Waterfall lifecycle model also known as the ‘linear software development cycle’ as illustrated in Figure 1. A common interpretation of this model is that each phase must be completed before the next phase can commence in order to reduce the chance of mistakes later in the project. In practice there may be some feedback and corrective action at the very edges of adjacent phases. Figure 1. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 12 User requirements: the goal of this phase is to define what software should do, typically by gathering input from all the users. The primary outputs are the requirements document (detailing the function and performance of the software), the software requirements phase plan, and an outline of the acceptance tests. It is at this stage that details for the project management, change control, verification and testing, and quality assurance are prepared. Software requirements: this phase converts the user requirements into a logical model of functional components and their interfaces, together with specific performance targets for the components. The model is quite abstract and implementation details are excluded. The outputs include the software requirements document, a summary of the user’s support needs, an outline of the plan for testing the complete system, and the architectural design phase plan. Architectural design: this phase converts the logical model into a physical model that is implementation dependent. The abstract model of the previous phase is made concrete in the form of a hierarchy of partitioned components (e.g. classes of objects) and data models. Only the upper-level components are defined in detail at this stage, leaving the lower level components as black boxes to be resolved during the next phase. Integration test plans are defined to verify inter-operation of the components and a production phase plan is created to support progress monitoring. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 13 Detailed design and production: this phase expands on the design activity to encompass the low-level components and their inter-operation. The design is reviewed layer by layer, coding conventions are established, error handling mechanisms agreed, and unit tests for each component are defined. As components become available unit tests check individual components and integration tests check inter-operability of the components. The outline tests created in previous phases are finalised. Transfer: this phase covers the installation of software to an operational environment (perhaps a staging server) and completion of the acceptance tests. At the conclusion of testing the user agrees to provisional acceptance of the software or identifies problems that need to be resolved prior to acceptance. Maintenance: this phase provides the operational time required to ensure that the software satisfies the user requirements, something similar to a warranty period. Undetected bugs may emerge after the full system goes live, or enhancements may have been identified. Users will require continued support and training during this phase. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 14 Table 1: a summary of the claimed advantages and disadvantages of the model. Do Activity 2. Work breakdown One of the values of the Waterfall lifecycle model is that it offers some insights into the activities to be undertaken and the sequence in which those activities must be completed. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 15 For example when using the broad description of the ‘User requirements’ phase several discrete activities can be identified that must be completed, such as: interview users to gather requirements define functional and performance requirements outline acceptance tests (function and performance) plan the System requirements phase prepare the Requirements document. What started as a rather broad description of a phase of activity in the lifecycle has been broken down into a number of specific tasks. I can repeat the process for each of the tasks I have identified in the User requirements phase in order to get a better idea of the actual work that must be done. Taking the ‘interview users’ activity as an example, this might break down into the following steps: identify users to be interviewed arrange interview times and venues prepare interview documents (introduction, questions, forms, etc.) conduct interviews review and summarise results. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 16 The general idea is to create a hierarchical decomposition of the entire project into a set of small chunks, as illustrated in Figure 2. each chunk represents a package of work that can be assigned to an individual. By convention a reference number is assigned to each work package that is indicative of its level in the hierarchy, so that a single digit item indicates level 1, two digits level 2, three digits level 3, and so on. This number also provides a permanent reference to the package that can be used within other project documents. The resulting diagram is known as a work breakdown structure (WBS) and represents a map of all the work to be completed, including any planning and monitoring activity. As a general guideline the level of detail in the WBS should be sufficient to allow an estimate of the time and cost of each package. These estimates will be used to monitor progress By: Dr. Monif Jazzar. AOU-KW as the project proceeds. Do Activity 3 4/11/2015 TT284: Web Technologies 17 The V-model Criticism of the Waterfall model has resulted in various alternatives, such as the V-model illustrated in Figure 3. Figure 4 Figure 3 There are several new features to note. First, phases can overlap at the edges so it is not necessary for one phase to be entirely complete before the next can commence. Second, all testing activity has been pulled out into a separate sequence of phases. This appears to extend the lifecycle, but in fact all the testing activities are covered by the Waterfall model. Third, the phase ‘detailed design and production’ has been split into three phases: design, code, and test. Fourth, the phases after ‘production’ are bent upwards to create the V-shape; creating the separate lines of activity labelled ‘project definition’ and ‘project integration’. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 18 As in the Waterfall model, test plans form an important output of each of the definition phases, but in the V-model they also provide for explicit verification of the design. For example, one of the outputs of the User requirements phase is the outline acceptance tests document. A careful review of the proposed acceptance tests acts as verification of the interpretation of the user requirements. The goal is to ensure that no requirements are missed and that unnecessary requirements are excluded. The relationship between each of the definition phases, the creation of test plans, and the verification of those plans through feedback, is illustrated in Figure 4. Proponents of the V- model argue that verification can help identify design errors much earlier in the project, thereby improving quality, reducing costs, and instilling greater confidence in the solution. 3.4 The agile alternative another development model proposed by the ‘agile’ movement. As a minimum you should read the following web pages about the Agile Alliance: Agile Alliance (2001a), ‘Manifesto for agile software development’. Agile Alliance (2001b), ‘Twelve principles of agile software’. Google (2012b), ‘Agile software development’. If you have time you may also find the following articles helpful: Sutherland (2010) ‘Agile principles and values’. VersionOne (2012), ‘Agile development: a manager’s roadmap for success’ (requires registration) Gualtieri (2011) ‘Agile software is a cop-out; here’s what’s next’. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 19 3.5 The OURC case study Abstract and idealised models are all very well, but what about real life? Do Activity 4 (reading) 4 The project plan The software development lifecycle offers a useful insight into the sequence of activities involved in creating a web application, but says nothing about how that work is to be managed and monitored. For that we have to return to the topic of project management and the project plan. At first sight it might look as though the development lifecycle and the project plan are the same thing, as both describe the project in terms of goals and activities. They are not the same and it is important to understand the difference. A lifecycle model describes the work to be undertaken and the sequence in which it should be completed. The project plan aims to define the objectives of the project and the process by which the work will be managed and delivered on time and within budget. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 20 One cautionary note: don’t confuse project management with so-called project management tools, such as those used to schedule work and create visual representations of the project timeline, there is much more to it. The project plan typically starts life as a proposal to undertake a project based on a request from a client. Its primary function is to provide sufficient information for the management team to decide if it should undertake the work and for the client to decide to accept the developer’s bid. The primary purpose of any project plan is to communicate the following aspects of the project. The project objectives. Most project plans start with the business case, which describes the business opportunity, need or problem that the project aims to address. It provides the rationale for undertaking the project, the anticipated benefits and costs, the start and end dates, and the potential risks. The scope. The scope provides a broad statement of the overall approach to the project and describes how the project will satisfy the stakeholders’ requirements; not to be confused with the Requirements document output from the ‘User requirements’ phase of the lifecycle. It may be helpful to include a specific section on ‘out of scope’ activities. Partnerships. Partnerships are an important means by which project risks can be shared, so any partnerships should be identified together with any constraints and assumptions that could affect the outcome of the project. The risk assessment (see below) may indicate the impact of the constraints and assumptions. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 21 The outputs. The plan should detail the various deliverables created during each phase of activity, for example design documents, training manuals, code for components, or test results. Knowing what is to be delivered and when it should be delivered enables project progress to be monitored. The resources. In addition to the human resource requirements, various non-human resources will be required to complete the project. In the case of a web application this could include any servers necessary to host the application, computers for the code developers, and development tools for authoring and testing. Configuration management (version control) and testing tools may have to be purchased. The resource requirements may be satisfied using existing equipment or it may be necessary to purchase, configure, and deploy new equipment. The team. The plan should provide details of the project sponsor, the project manager, key stakeholders, and partners. Some plans may identify specific skill shortages to justify staff training or employment of new staff. At some point the project plan may be updated to include a work breakdown structure diagram or a list of the main work packages. Allocation of work packages to team members can be provided in an appendix or in a separate document. The estimate. The estimate combines the cost of all the resources, people, equipment, and tools with a schedule of when activities start and finish and when costs will be incurred. Estimating is rarely an exact science, but relies on people’s experience, historical data from similar projects, and in some cases statistical methods based on best and worst case scenarios. The risk assessment. All projects are subject to risk so the goal is to identify the risks that are most likely to have a severe impact on the project and to identify strategies for mitigating those risks. Risks that have been identified may be recorded in a separate risk register so that they are monitored and controlled as the project proceeds. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 22 Other elements The plan should include reference to the quality goals and how they will be achieved, for example the use of international standards, specific validation tools, and code reviews and inspections. Channels of communication should be defined to establish how client and team members are kept informed of project progress, both to retain commitment and to ensure decisions are disseminated. As the project proceeds, problems will emerge and changes will be requested so the plan should identify how these will be handled. Do Activity 5. 4.1 Monitoring performance The project management plan describes the best intent at the outset of a project, but it is not sufficient to set goals and targets, they must be monitored to ensure that the project gets completed on time and within budget. That raises the question as to which metrics can be used to monitor costs and progress. Most project plans include a combination of milestones and gates. A milestone is an important event in the schedule, perhaps the delivery of an item of equipment or completion of some tests, and provides the means to compare the actual performance to the planned performance. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 23 Often milestones are placed at the end of a phase or work package, but this leaves no opportunity to catch-up if progress has slipped. So instead of the milestone ‘document complete and reviewed’, it may be better to use ‘document ready for review’; thereby leaving some time to take corrective action. A project gate (or stage gate) represents a point in the project when all work stops to await a decision. In some cases the decision may relate to whether the project should continue or be terminated; for example a gate at the end of the user requirements phase provides the opportunity to terminate the project if the user requirements cannot be adequately defined. Another use of the project gate is at sign-off points, when the ‘client has to confirm their acceptance of some output. The three most common metrics employed are: Time: compares the estimated duration to the actual time taken to complete a work package. Cost: compares the estimated cost to the actual cost of completing a work package Deliverables: compares the estimated time and cost to create a deliverable with the actual time and costs. Do Activity 6. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 24 5 Requirements Understanding a project’s requirements is key to a successful outcome so it is important that sufficient time is allocated to gathering and prioritising requirements before any detailed design work commences. It is a challenging task because stakeholders may have unrealistic expectations of what can be achieved and staff may feel the project is diverting them from more important work. Gathering The gathering stage is intended to elucidate the raw ideas about what the ‘solution’ should provide in terms of important features and how it will interact with other parts of the business. interview the stakeholders , include actual end-users, understand how the current process operates and where it falls short of user’s needs Refining The refining stage converts the raw ideas into something more structured, such as a business process or a prototype website. It is important that stakeholders are given the opportunity to review the proposal to ensure it meets their needs. Ideally, stakeholders should ‘sign off’ on the requirements in order to lock down the set of features to be provided. key steps are: By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 25 preliminary design presented to stakeholders as online wireframe and site map stakeholders provide feedback on wireframes feedback incorporated as revisions to the wireframes wireframe model is signed off. MoSCoW One of the challenges of the user requirements phase is satisfying conflicting features or functions. Individual stakeholders will have different perspectives on what the project should achieve and hence what the priorities should be. The acronym ‘MoSCoW’ represents four levels of priority expressed by the words ‘Must’, ‘Should’, ‘Could’, and ‘Won’t’; the two lower case ‘o’ characters are there to make the acronym work. The interpretation of these words is: Must – the project must provide the feature or function; a ‘Must’ feature is non- negotiable and if not delivered then the project is a failure; therefore it is in everybody’s interest to agree what can be delivered and will be useful. Any features or functions tagged as ‘Must’ will feature in the acceptance tests. Should – the project should provide the feature or function if at all possible; a ‘Should’ feature is important, but if time is short, it could be postponed for a future delivery. The project still has value without these features. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 26 Could – the project could provide the feature or function if it does not affect anything else; a ‘Could’ feature would be useful to have if it does not cost too much or take too long to develop, but it is not central to the project. Won’t – the project won’t provide a feature or function this time; a ‘Won’t’ have feature is not needed now, but will be needed in the future, where it may be upgraded to a 'Must'. Knowing what the future features and functions are helps to ensure that a proposed solution does not preclude them. Do Activity 7 6 Quality One interpretation of the term ‘Quality’ is that of ‘functional quality’, meaning that a piece of software is ‘fit for purpose’ and delivers the functional requirements. The primary method of assessing functional, or external, quality is by testing that the software fulfils each of its requirements. Another interpretation of quality is of ‘structural quality’ or ‘internal quality’ that relates to how well the software was produced. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 27 The International Organisation for Standardisation (ISO) has published standards relating to software quality. ISO/IEC 25010:2011 describes software quality in terms of eight characteristics namely: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability. The Consortium for IT Software Quality (CISQ) has defined five structural quality attributes essential for a piece of software to have business value, they are: reliability: an attribute that addresses the risk of application failure and downtime and the potential impact on users efficiency: an attribute that addresses the performance and scalability of the code and the resources required to execute it security: an attribute that addresses the potential for security breaches arising from bad coding practices and poor system design maintainability: an attribute that addresses the ease with which updates or changes can be made to an application size: an attribute indicative of the amount of code produced, the work completed, the complexity of the solution, and hence the maintainability of the application. One of the stated goals of CISQ is to identify a corresponding set of metrics that can be assessed automatically by analysing the software’s architecture and code. Some tools already exist and can be found by searching the Web, but they will not be investigated further here. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 28 The challenge for any project is to get the right balance between these structural quality attributes because raising the standard of one may impact another. For example, the additional code required to improve the security of an application could reduce the efficiency and maintainability attributes. Another approach to improving structural quality relies on the ‘review’ whereby each stage of development is reviewed and critiqued by members of the development team. You may encounter alternative terms such as ‘peer review’, ‘walkthrough’, or ‘inspection’. According to McConnell (2004) the cost of detecting and correcting software defects is lower using review-based techniques than test-based techniques, but minimising defects requires a combination of testing and inspection: … software testing has limited effectiveness when used alone – the average defect detection rate is only 30 percent for unit testing, 35 percent for integration testing, and 35 percent for low-volume beta testing. In contrast, the average effectiveness of design and code inspections is 55 and 60 percent respectively. It is interesting to note that the highest rate of defect detection (75%) was achieved by high-volume ‘beta’ testing. The quality plan Quality is rarely achieved without a specific plan that sets out what the objectives are, how they will be applied and what will be monitored to ensure compliance. For small-scale projects a brief statement in the project plan may be sufficient, but larger or more complex projects may require a separate quality document. The PMBOK recommends that the quality plan address the following points: By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 29
identification of appropriate quality standards and the methods to satisfy them
procedures to ensure quality standards are followed and identification of those responsible for quality assurance activities
monitoring of project outputs to determine compliance with the quality plans and to provide opportunities for improvement. In the case of web applications there are numerous standards and tools that can contribute to quality. For example, the W3C standards for HTML and CSS and the WCAG guidelines can be combined with output from validation tests that acts as evidence of compliance. Code reviews provide the opportunity to verify standards of coding and documentation, and identify opportunities for improvement. Quality assurance activities, such as testing, validation and code reviews, take time and must therefore be included in the project workload, preferably as specific packages within the WBS assigned to individuals or a dedicated test team. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 30 7 Resources and time The resource and time sections of a project plan are intended to summarise the resources required to complete a project together with the project duration and the dates of important milestones and gates. A project plan for external consumption may omit a resources section completely unless partners are involved. The only people mentioned in an internal plan will be those that will have direct contact with the customer, such as the project manager. When greater detail about resources is required it is often provided in chart form. The example project plans illustrate several methods to convey this information. Optional items for inclusion are:
unusual patterns of high resource usage or extended periods of idle resources, as this may impact the cash-flow of the business.
specialist equipment and tools required for specific tasks, or phases.
milestones to highlight dates for access to client systems to facilitate testing and transfer. Estimating how one estimates the duration of a project? The starting point is to create a WBS to a level of detail sufficient to estimate the resources and duration of each package. The lifecycle-models provide a useful base from which to start, but the low-level package detail will be unique to each project. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 31 Once the packages have been identified the resource and duration estimates can be derived using the methods listed below: Use historic data: essentially this means that you look back at your previous work for similar tasks and use the time it took as the estimate for the current task. Many companies collect data about performance for just this purpose. Ask a friend: asking a co-worker, perhaps someone with greater experience, is a good option when the task is unfamiliar to you. Weighted average: extends the ‘ask a friend’ option to include three estimates labelled ‘best’ ‘worst’, and ‘most likely’. These three are combined as (best + 4 × most likely + worst) ÷ 6 to give the desired value. Management tax: once your estimate is obtained increase it by a fixed percentage to allow for non-productive activities such as meetings, phone calls, email, etc. No matter which method is employed it is common practice to add some extra time as contingency for unforeseen events such as sick-leave or late delivery of equipment. If the project duration is too long there are two options; add resources or find a quicker way to do the work. Do Activity 9. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 32 8 Risk management If projects are temporary endeavours to create a unique product or service, and they bring together a wide range of skills and resources in order to fulfil some specific requirements, then it follows that there will be some degree of uncertainty as to the outcome. Will it be completed on time and on budget and will it fulfil the requirements? Understanding and controlling this uncertainty is termed risk management and it involves putting in place procedures to help identify and assess project risks, along with strategies to minimise the impact of any risks that arise. So what sort of risks might arise within a project? A simple static web site may have very few risks, whereas an eCommerce website built around an n-tier architecture has many potential risks. Identifying risks is all about asking questions, the following list of categories is not exhaustive, but will give you some idea of the areas to be covered. Organisational (internal to the company) Does the company have the resources to undertake the project at this time? Has the project sufficient priority within the organisation? By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 33 External (customer, suppliers, regulatory authorties) Do we know the customer? Have we done work for them before? Is the customer committed to the project and will they work to help ensure that deadlines are met? Do we know the equipment supplier, are they reliable? Are there any special legal requirements, perhaps relating to data retention or accessibility? Scope (requirements) How likely are the requirements to change once the project has started? Have requirements been prioritised? Technical (software and hardware) How complex is the project, static content, dynamic eCommerce website, one-off international event? Are all the technical requirements understood? Has the technology been used before? Does the team have the necessary skills to make effective use of the technology? Are the server performance targets realistic? Does the application introduce any unusual security risks? Are the quality requirements especially onerous? By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 34 Project management Are the estimates realistic? Is the project manager known, are the team members known? Are the procedures for reporting and monitoring project progress realistic? Will any team members be assigned to multiple projects? The answers to these questions will help to establish the potential risks and hence the consequences for the project outcome. some interpretations encountered: Likelihood Low: practically never occurs [< 5% of projects] Medium: occurs in 1 project out of 5 [approx. 20% of projects] High: occurs in every project [ > 75% projects] By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 35 Impact Low: has negligible effect on the project outcomes Medium: has a significant effect on the project, but the project’s outcomes are not threatened High: the project’s outcomes (functionality, duration, or cost) are threatened The results are often presented in tabular form, as illustrated in Table 3. The risk rating matrix combines the likelihood and impact scores to provide an overall measure of risk, as illustrated in Table 4. This example is based on equal weighting of likelihood and impact, but other weightings are possible. Reading the values in the table you can see that the combinations of low and low or low and medium produce a low risk, the combinations of medium and medium or low and high produce a medium risk, and the combinations of high and medium or high and high produce a high risk. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 36 Risk strategies Once the risks have been identified and assessed the next step is to determine what actions should be taken to minimise the risks as the project proceeds. That means a mitigation strategy to reduce both the likelihood and impact of each risk. There are several generic strategies that could be employed such as: Eliminate or avoid the risk by not doing things or doing them a different way. The LOCOG technical team eliminated the risk of insufficient server capacity by distributing the web content out to partners' servers. Reduce the likelihood of the risk, perhaps by monitoring progress of a work package more closely or giving the customer advanced warning of a forthcoming sign-off gate. Reduce the impact of the risk, such as using contract staff to cover while a team member is off sick. Stop the project is an option used in extreme circumstances, perhaps if civil war broke out. Share the risk with a partner. For example, if the team doesn’t have the knowledge or skills for a part of the project, sub-contract the work to a partner. Taking out insurance is a common form of risk sharing. Accept the risk because it has a low impact and likelihood, but monitor closely in case circumstances change. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 37 The risk management plan The final stage of risk assessment is to combine all the information that has been gathered into a risk management plan that highlights the most significant risks, outlines the mitigation strategy, and assigns responsibility for monitoring the risks. the goal is to provide a summary of the important information to be shared by the stakeholders, possibly in tabular form as illustrated in Table 5. The risk management plan is typically a snapshot of the assessed risks at the start of the project, hence a separate document, known as the risk register, is used to track changes in the level of each risk and to record what (if any) actions are taken to manage the risks as the project progresses. Do Activity 10. By: Dr. Monif Jazzar. AOU-KW 4/11/2015 TT284: Web Technologies 38 End of Tutorial 11 Have a nice day By: Dr. Monif Jazzar. AOU-KW