End of chapter Questions and Answers



Download 151.43 Kb.
Page2/4
Date18.07.2017
Size151.43 Kb.
#23636
1   2   3   4
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.
The main dangers associated with RAD are to do with its very speed in that it leaves little time for reflection and, if not managed tightly, less still for documentation. Some critics have described RAD as a ‘licence to hack’. The real problems with poorly documented systems come later in their lifecycle, when maintenance becomes difficult and unpredictable, since the support engineers do not have adequate information on why and how the system has been created as it is. A further potential problem is that the part of the system chosen as a starting point – because of perceived business needs – may not, in fact, turn out to be quite so central and the finished system may be ‘skewed’ as a result.

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:


  • If the analysts have the skills to create software themselves, they may themselves work with the users to create and evaluate prototypes; this represents, in effect, a return of the old ‘analyst/programmer’ role.

  • Otherwise, analysts and developers will have to form small joint teams to work with the users.

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.
The Soft Systems Methodology takes a holistic view of ‘systems’, regarding a business system (‘human activity system’ in the SSM terminology) as something that takes place within a cultural and structural context. Similarly, the Socio-Technical approach recognises that systems cannot be simply regarded as inanimate things, and offers concepts for placing systems in their human and organisational context. Finally, Business Process Reengineering is concerned with the radical redevelopment of business systems so as to improve the effectiveness and efficiency with which inputs are transformed into outputs valued by the customer. Many BPR solutions involve the use of information and communications technology to promote and support these improvements.

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:


  • Project Start-Up: Project Initiation Document; Project Plan; Quality Plan; Risk Management Plan; Configuration Management Plan. Note that these various plans may be combined into one document, especially for smaller projects.

  • Analysis of Requirements: Requirements Specification (covering the requirements themselves plus definitions of the processing and data requirements for the system).

  • Design: Technical Design (include overall architecture of the proposed system, module specifications and database schema).

  • Integration: individual modules combined together to create a working system.

  • Testing: Test results (from integration, system and acceptance tests) and an Acceptance Certificate from the users confirming that it meets their requirements as defined in the Requirements Specification.

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:



  • Roles and responsibilities are not defined properly.

  • The parties involved do not have a clear and shared understanding of the activities and deliverables involved.

  • Dependencies, both between activities and on third parties outside of the project, are not explored and can lead to difficulties during project execution.

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:



  • High degree of innovation: Most IS projects involve some innovation and many involve a lot of it. In these circumstances, it is difficult for the estimators to find precedents on which to base their assessments. This is often coupled with undue optimism about what can be achieved by when. The answer to this is to divide the project up into its innovative and less innovative components; for the latter, experience and perhaps data from previous projects can be used and, for the former, ranges rather than single-point estimates can be offered.

  • Too early commitment: Firm estimates are often given in IS projects before a clear and agreed Requirements Specification – still less a full Technical Design – is available. Short of refusing the give firm estimates at this stage – which would be the logical course of action – project managers may again have to insist on quoting a range of estimates, shortest, most likely and worst-case.

  • Lack of metrics: For some reason, people in the IS community are not good at collecting and publishing metrics even when, as in the case of COBOL programming, there should be decades of experience to draw on. In the absence of industry- or organisation-wide metrics-collection initiatives, project managers need to collect data from their own projects for later use, by themselves and others.

  • Lack of specialist estimating skills: Unlike, say, civil engineering, where specialist estimators are used, in IS almost anyone is presumed to be capable of developing a set of estimates. Project managers should, ideally, insist on the involvement of technical people with extensive experience of the technologies involved. They should also get more than one opinion, and use more than one estimating method, and cross-check the results.

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.



  1. Project management

  2. Team leading/supervision

  3. Quality control

  4. Familiarisation.

  1. Project management effort is dependent on two things – whether a full-time project manager is to be used or not and the overall expected duration of the project. If a full-time manager is required, then one simply multiplies the duration of the project by four to get the number of days’ effort involved (see the main text for a discussion of why only four days a week is available for each person over the long run). If a half-time project manager is to be used, then the number of weeks is multiplied by two and so on.




  1. Team leading can be worked out using the ‘rule of thumb’ that a team leader can effectively supervise up to five programmers. So, one starts with the total programming effort and divides by five to get the amount of team leading. With some of the newer, high-productivity programming environments, a ratio of 1:4 for team leading may be more appropriate.




  1. Quality control can be added as a percentage on top of each ‘doing’ activity like creating programs. In working out what percentage to use, it must be remembered that quality control review often lead to rework which must also be included in the estimates.




  1. Familiarisation is best calculated as an allowance (a number of days) per team member, based on their prior understanding of the business and technical environment.

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:


1   2   3   4




The database is protected by copyright ©ininet.org 2024
send message

    Main page