End of chapter Questions and Answers
Download 151.43 Kb.
|
| Structured methods are, nevertheless, open to the charge of bureaucracy. Because everything is documented very thoroughly, projects using structured methods can end up accumulating a vast amount of paperwork. This, in turn, can prove very difficult to control and lead to the project team spending a lot of time in document management instead of in actual analysis or development. The answer to this, of course, is to find – or perhaps create, using one of the readily-available database products – a suitable CASE (computer-aided software engineering) tool.
Q4 Increasing interest is being taken in the use of rapid application development. Why is this, and are there any dangers associated with the RAD approach? RAD has come to prominence because of the increasing pace of change within all organisations. The argument goes that, against such a background, the conventional, linear approaches – as represented by the waterfall lifecycle – do not produce results quickly enough. Often, it is more important to get some sort of solution quickly than the best solution in a couple of years. In addition, the advocates of RAD, for example the DSDM Consortium, contend that, because of the close working relationship between users and developers that is inherent in the RAD approach, the users are more likely to get a system that meets their real needs than with a more conventional approach. Indeed, in recent years, RAD’s proponents have been stressing fitness to purpose over speed of development.
Q5 Consider how you would organise your project team for a RAD-type project. What leadership practices would it require from the project leader and what would the team members have to do? How, and at which points, would you involve the users? RAD requires, for its success, a close and ongoing relationship between developers and users. The actual organisation may depend on the skills available on the development team, for example:
A major issue for project leaders in a RAD environment is what may be called ‘expectation management’. The users – and also the developers – must be kept focused on the (limited) objectives of the stage in hand and must also be encouraged to keep to the often-tight timescales for the stage. Users often also need convincing that they can forego some feature in the current stage but that they will get it in a later stage. There is often the additional difficulty that user management want something different – often less - from the ‘coal-face’ users of the system and the project leader must make sure that the views of both constituencies are considered and managed. Users must be involved at all stages of a RAD project, from initial definition of requirements – however generalised – through the development of prototypes to the testing of the finished system increments. Q6 What have RAD and extreme programming got in common? What are the claimed advantages of these approaches? Both RAD and XP have as their common aim, and as their primary claimed benefit, the speedy delivery of system features and functionality to meet users’ needs. The difference between the two approaches are mainly to do with scale and scope; whereas RAD is about the development of entire systems, XP seems more concerned with adding individual features. Both approaches involve developers working closely with users to define the need (by using ‘stories’ in the case of XP, by developing prototypes in RAD) and the advocates of both also stress the need for proper documentation of the results. Q7 Why are approaches such as the Soft Systems Methodology, the Socio-Technical Approach and Business Process Reengineering relevant to IS project managers? The development of information systems does not take place in a vacuum and is not solely a technical exercise. Information systems are created to meet business needs and they have to be developed and implemented within the structure, processes and culture of an organisation.
Chapter 7 The profile of a project Q1 What work goes on prior to project start-up? Before project start-up, work is needed to establish the objectives and scope of the project. It is necessary to establish the dimensions of the ‘triple constraint’ of time, cost and scope/product/quality. Where the development work is to be undertaken by an external supplier, there may also be a process of tendering and negotiating a suitable form of contract for the project. In addition, the project may be preceded by a feasibility study, which is designed to establish the business case for the project and perhaps to explore alternative methods of meeting the perceived business need. Q2 Describe the products that typically result from the following project stages: Project Start-up; Analysis of Requirements; Design Integration and Testing. Typical products include:
Q3 Explain the incremental approach to testing represented by the sequence: unit (module) test; integration test; system test; acceptance test. With the incremental approach to testing, each unit (module or program) of the system is first tested to ensure that it does what it supposed to do as defined in the module specifications. This testing is often carried out by the programmers who developed the modules, although sometimes a ‘peer review’ approach is used instead. The integration test seeks to find out whether the modules, when fitted together, operate as expected and interact without problems. The baseline here is provided by the Technical Design and by the Requirements Specification. Integration testing is often the responsibility of a specialist testing team. In system testing, the developers are checking that the system provides the functionality defined by the users in the Requirements Specification. As well as the developers and testers, the business or systems analysts may be involved here to look at the system from a user perspective. Finally, the users are invited to conduct an acceptance test to check that what they have asked for in the Requirements Specification has been provided. Often, the users require help from the business or systems analysts in performing these tests and the project manager may also become involved to manage the process; to ensure, for example, that the users do not introduce into the tests any criteria that were not mentioned in the Requirements Specification. Sometimes, because of overruns in earlier stages, it is necessary to combine the system and acceptance tests. Although unavoidable, this is not desirable since, by definition, all of the ‘bugs’ will not have been eliminated before the system testing (that, after all, is the point of it) and too many problems can undermine the users’ confidence in their new system. Q4 From what product should the acceptance criteria for a project be derived and why? The acceptance criteria should be derived from the Requirements Specification, which is where the users’ stated needs are documented. The actual acceptance criteria may not necessarily be defined in the Requirements Specification, which might thereby become too large and unwieldy, but it is important to make the requirements as specific and measurable as possible to avoid later arguments over acceptance; for example, ‘a response time of less than 2 seconds for 90% of transactions’ is a lot more precise than ‘a fast response time’. Since the acceptance criteria are based on the Requirements Specification, this emphasises the importance of that document. Q5 Why is it important that the project team and the users develop and agree a process model for a project? Any project is a cooperative venture between the clients/users and the suppliers/developers and it is important that both parties have a clear understanding of what will happen, when and what are their respective responsibilities. A process model provides a framework so that both parties can see where they will be involved and what their roles will be at each stage. It also highlights the important milestones in the project and enables the stakeholders to plan their time so as to be available when they are required. Chapter 8 Project planning: understanding the work Q1 Give three reasons why it is essential to plan an IS project in detail before starting work on it. Only the simplest projects – which probably means one developer working for one user – can get away without having a proper plan of work. Even then, both parties will probably have reached some informal agreement about the order in which things are to be done and this does constitute a basic plan. Most IS projects, however, are much more complicated than this and, as complexity and the number of stakeholders increases, it becomes more and more important to plan the project in detail. Without having a detailed plan:
It is probably true that, important though a good project plan is, a lot of the value in planning is that it requires the project manager to think through how they want to approach the project and thereby end up with a much clearer idea of the approach they are going to take. Q2 Ideally, the requirement for an IS project would be specified in some detail before planning begins. If the requirement is not detailed enough, what steps can the project manager take to improve the likelihood of the project’s success? If the requirements are not specified in enough detail, the project manager may need to make some assumptions in order to get started. If so, these assumptions needed to be clearly documented, preferably in the Project Initiation Document, and the assumptions should be drawn to the attention of the users and, in particular, of the sponsor. These assumptions then form part of the initial ‘baseline’ for the project and, should the work later prove more extensive or time-consuming than assumed, the project manager will have a good case for approaching the sponsor for more time, budget or resources to complete it. Q3 In essence there are two basic ways of breaking down a project into plannable chunks: the use of a work breakdown structure or a product breakdown structure. Contrast the advantages and disadvantages of these approaches. The work breakdown structure (WBS) concentrates on tasks and the product breakdown structure (PBS) on deliverables from tasks. Both methods are used and, in fact, they can be combined so that, at the top levels, the project is broken down by product and then, once individual products have been identified, a work breakdown is created. The WBS is the more traditional approach, and is the basis for most of the readily-available project planning software, which makes it easy to adopt and to represent on a computer. The advantage of the PBS is that it requires a concentration on ends rather than means and it can be somewhat easier to apply in the early stages of planning where the actual work is unclear but the required deliverables are better understood. In addition, once the individual products have been identified, it is possible to create for them product descriptions that provide, as it were, specifications of work for the individuals or teams tasked with their development. Q4 What do you understand by the term dependency? How can project dependencies be represented for planning purposes? Dependency occurs when, for example, task or deliverable ‘A’ must be completed before task or deliverable ‘B can be started. In a complex project, the analysis of dependencies helps to identify streams of work that can be performed in parallel, thus shortening the overall duration of the project. The normal way that dependencies are represented is on a dependency diagram, also known as a network diagram or a PERT chart. Microsoft® Project also shows dependencies on the bar/Gantt chart by vertical connections between task bars but this can get somewhat confusing on a large or complex project. Q5 Define the terms “product” and “work package” and explain how these are related to each other. A product is an individual deliverable from a project and it may also form a work package if it is assigned on its own to an individual or team. More commonly, though, a group of related products – perhaps products that need to be created together – may form a work package. Q6 Network diagrams and bar charts have different parts to play in planning a project. Where is each of these tools used and what does it show? The network diagram analyses and displays the dependencies between the tasks or deliverables on a project and it is used to identify the streams of work that can be undertaken in parallel. The bar chart shows all of the tasks placed against a timeline to show when they are to be done. The network diagram does not show this contrast with the timeline very well, whereas on the bar chart the dependencies between tasks is not necessarily self-evident. The network diagram has other uses, for example in analysing the potential effect of slippages and risks on the achievement of the project’s deadlines. Chapter 9 Project planning: estimating Q1 Explain three reasons why estimating for IS projects has a poor reputation and a bad track record. What can be done about these problems? There are a number of reasons which could be advanced, including:
Q2 The analogy method of estimating is often used to produce broad-brush estimates at the start of a project. Why is this method particularly suited to this application? Finding an analogous project on which to base estimates does not require the detailed analysis and work breakdowns required of other methods and so can be used to generate an estimate fairly quickly. This is particularly suitable at the start of a project when the decision-makers are probable more interested in knowing what ‘ballpark’ they are in, rather than having an exact calculation of costs and timescales. Q3 The analysis effort and programming methods both rest on the principle of extrapolating the total development effort from detailed estimates of one phase of the project. Describe the approach taken in each of these methods and show in what circumstances each might best be employed. With the analysis effort method, the stage of the project that forms the basis for the estimates is the analysis of requirements. Estimates for this can be arrived at by considering the stakeholders to be involved, the methods to be used (interviews or workshops for example) and by allocating sensible amounts of effort to these. The analysis effort method is probably the best choice where there is only a vague idea of the actual requirement but where the stakeholders to be involved in the analysis work can be identified. The programming method requires specialists well-versed in the technologies to be used to take a look at the requirements and then to assess the effort involved to create the required programs. This could be done by estimating lines of code or perhaps by categorising programs as large, medium or small or as complex, moderate or simple. Clearly, this method is most relevant where a Requirements Specification – perhaps received as part of an invitation to tender – is available that gives a good general idea of the programs likely to be needed. Q4 The Delphi technique aims to achieve a consensus estimate from the efforts of a number of estimators. How is this achieved and what is the advantage of the Delphi technique over, for example, a round-table discussion? The chief problem with a round-table discussion is that the personalities and egos of the estimators get caught up in what should be a rational, dispassionate process. People may feel forced to defend their estimates – high or low – because to do otherwise would be seen to involve a loss of ‘face’ with respected technical colleagues. The Delphi technique involves asking for estimates from a number of people and then circulating the results anonymously for all to see. Because the estimates are anonymous, estimators will not lose face by changing their minds and seeing other peoples’ estimates may well cause re-thinks. The problem with the Delphi technique is that people cannot ask questions about how others have arrived at their estimates and they may thereby miss some important issues that others have considered. Barry Boehm (see earlier) found that a combination of the Delphi technique with well-run workshops tended to produce good results. Q5 Describe how you would go about estimating for the following supporting project activities and why you would take your chosen approach to each.
Q6 State three factors that could influence the estimates for an IS project and how you would attempt to adjust the estimates for these factors. Relevant factors include:
|