Available online
Description
The two bands on this side of the cassette are both associated with Unit 13. Band 1: In the first band Helen Sharp of the course team asked Tim Hadden who is a project manager at SD Scicon to desc...ribe a typical week. Band 2: Professor Darrel Ince of the course team discusses software metrics with Martin Shepherd of Wolverhampton Polytechnic. Making metrics easier to apply. Side 2 (first part of Unit 14): Helen Sharpe of the course team talks with Tim Hadden of SD Scicon again, this time asking him about project planning, and in particular about a project to supply an electronic control system for an emergency escape gangway by support vessels working in oil fields in the North Sea (continued on AC4).
The two bands on this side of the cassette are both associated with Unit 13. Band 1: In the first band Helen Sharp of the course team asked Tim Hadden who is a project manager at SD Scicon to desc...ribe a typical week. Band 2: Professor Darrel Ince of the course team discusses software metrics with Martin Shepherd of Wolverhampton Polytechnic. Making metrics easier to apply. Side 2 (first part of Unit 14): Helen Sharpe of the course team talks with Tim Hadden of SD Scicon again, this time asking him about project planning, and in particular about a project to supply an electronic control system for an emergency escape gangway by support vessels working in oil fields in the North Sea (continued on AC4).
| Module code and title: | M355, Topics in software engineering | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Item code: | M355; AC3 | |||||||||
| Rights Statement: | Rights owned or controlled by The Open University | |||||||||
| Restrictions on use: | This material can be used in accordance with The Open University conditions of use. A link to the conditions can be found at the bottom of all OU Digital Archive web pages. | |||||||||
| Duration: | 01:04:04 | |||||||||
| Note: | There is a further band for Unit 14 on audiocassette 4 | |||||||||
| + Show more... | ||||||||||
| Track listing: |
|
|||||||||
| Publisher: | BBC Open University | |||||||||
| Footage description: | There are two bands on this side of the cassette, both associated with Unit 13. Band 1: In the first band Helen Sharp of the course team asked Tim Hadden who is a project manager at SD Scicon to describe a typical week. He explained that with responsibility for some five projects of varying sizes both here and abroad (many SD Scicon projects are in the Middle East), a typical Monday would begin by looking at faxes that had arrived over the weekend and by planning the week ahead in outline. This would be followed by discussions on the current state of play of each project with its project leaders; he holds weekly reviews of actual as against planned progress which identify problems and their possible solutions because ultimately he is responsible for any final or difficult decisions. During a typical week, too, there will be meetings to look at future projects and to put together bids; this can involve generating a lot of documentation! For the Project Manager there is always a balancing act between putting together new bids and managing current projects, so every week will include visits to clients, both to iron out problems on site and to boost the morale of those SD Scicon staff working away from home on the project. In addition such visits may bring in more business from the same clients. As well as being a troubleshooter, on call 24 hours a day, seven days a week, he has to go to meetings about quality control; from the outset every project plan includes a "quality" plan which is frequently checked and if necessary revised. Once a month there are formal meetings to review the status of projects, staffing issues and the like. In summing up his job Tim Hadden said he ensured other people did their jobs, dealt with problems as they arose and made decisions which helped SD Scicon to complete projects on time and within budget. Above all he kept the client happy. Band 2: In this band Professor Darrel Ince of the course team discusses software metrics with Martin Shepherd of Wolverhampton Polytechnic. They first discuss why software metrics are needed both to help people analyse engineering processes and the products that processors build and to enable them to make predictions about the engineering process itself. Early in the software lifecycle, at the time of project planning, metrics would be used to predict the cost of a project by measuring attributes of the specification. Later on, at the design stage, metrics might be used to assist the software engineer with his choice of a system architecture that maximised reliability and to pinpoint potential problems with the design prior to its implementation. Having described some of the advantages of using metrics for quality control over the traditional method of execution-based testing, Martin Shepherd went on to talk about two British projects that are using metrics. The first is the computerisation of the income tax system by the Inland Revenue at Telford which involves a technique called Function Point Analysis, and the second is at Lucas Aerospace where they are developing a system that will identify components that may cause maintenance problems and which involves the use of information flow-based metrics. Next Darrel Ince and Martin Shepherd talked about how to choose one metric in preference to another: essentially this means first knowing what is to be done with the metric, secondly taking a careful look at the theory, or model, on which the metric is based, to see if it contains any contradictions, for example, and finally doing some field work to check that the metric performs as expected. Finally in this band they take a look at ways of making metrics easier to apply; this is linked to the development of automation, in particular the development of software tools, of the browsing and retrieval facilities of modern databases, of more sophisticated statistical analysis tools and of graphical presentation techniques. Martin Shepherd felt that a lot of effort must go into ensuring that metrics used were appropriate for the job they were to do as there was a danger people would assume that a few metrics could apply to all cases; there is a need to customise and refine metrics. Nevertheless there is a long way to go before metrics can be used for anything more than very approximate predictions. The only band on this side of the cassette is part of Unit 14; there is a further band for Unit 14 on audiocassette 4. Helen Sharpe of the course team talks with Tim Hadden of SD Scicon again, this time asking him about project planning, and in particular about a project to supply an electronic control system for an emergency escape gangway by support vessels working in oil fields in the North Sea. This project involved diverse activities, from repackaging the actual microcomputers, to designing and building an interface board through to writing and implementing software. The first activity was to analyse the problem and to draw up a plan. Tim Hadden was responsible for drawing up the detailed plan; he explained that he had a lot of interaction with other people at this time as he had to rely heavily on their expertise; these people ranged from SD Scicon's own employees on the design and computing side to subcontractors who would cut the metal or make up the PCBs. On completion the detailed plan contained costings and a schedule for production; it also included an analysis of the possible risks of running over time or over budget, and contingency plans. Once the detailed plan had been produced the next stage was the appointment of a project leader, responsible for putting together both a "work" plan and a "quality" plan. At this point staff were briefed on their roles on the project and key dates and procedures agreed with the client. As well as involving many discussions with BP, the ten members of the SDScicon team visited the vessel in dry dock in Hamburg for the weekend, to see the problem for themselves. Later on the embers of the team also visited the oil rigs to see for themselves the environment in which the equipment would be used. Effectively the project had four phases, each lasting about three months. The first phase produced the specification, the second implemented that both in software and hardware, during the third phase these were integrated and tested on-shore, and then finally the system was tested and commissioned off-shore before being handed over and accepted by BP. During the project development there were, inevitably, a few crises to sort out; Tim Hadden mentioned a number of them, talking in particular about a problem with existing software which when it was ported across turned out to be a bad match, consequently the software had to be written and implemented from scratch in just six weeks! Although this work involved extra cost this was covered by the contingency fund built into the original costings. One of Tim Hadden's roles at this time was maintaining the morale not only of his hard-pressed staff but also of their family and friends. On reflection Tim Hadden would have liked a much more detailed analysis of the software that was to have been used, and to have tied the specification down much sooner and in more detail; as it is always easier to see how to avoid problems with hindsight it is essential to build contingency into any plan. The outcome of this project has been up and running since the mid 80's; SD SCicon is still involved in maintaining the equipment and in providing training for new BP personnel. | |||||||||
| Master spool number: | AC1180 | |||||||||
| Production number: | AC1180 | |||||||||
| Available to public: | no | |||||||||
