The course can be perceived as a survey and as a foundation course. Many people who find themselves participating in the development of significantly sized, software intensive systems will not have had any kind of formal education in computing. Many people will have undergone a course of computer education but may suspect that it is out of date or that it was incomplete.
Taking as its starting point, that the software crisis that has been going on so long it's become a deep-seated malaise rather than a crisis, the course introduces many of the techniques that can make a difference to the state of software engineering. It does not focus exclusively on programming, or analysis and design, or project management but aims to ensure that by the end of the course, everyone is aware of the many components that will be necessary to improve the state of software production techniques.
This course is appropriate for anyone who has some involvement in software engineering, is interested in raising the quality of software and who suspects that there are gaps in their knowledge. Those who have benefited from the course have included project managers, analysts, designers, programmers, testers and documentation authors.
The course normally lasts two days. We can discuss additional topics that can extend the course to three days if required.
It is based on a cycle of theory-language-practice-review, with approximately two cycles per day. One non-trivial, practical case-study is developed during the course. Each day will start at 09.30 and finish at 17.00, with an hour for lunch. Time is available at the end of the day for extended discussions or related issues.
We used to talk of a software crisis. It's been going on so long now that we must now speak of a software malaise. The symptoms of the malaise are introduced.
As software development becomes more disciplined, we seek to apply a key features of other engineering disciplines--the black box. We look at the evolution of the black box.
We look at three reasons for understanding why Dijkstra proposed that we should avoid the "goto" in programs.
One reason why software engineering is difficult, is that as soon as we have a reliable generic solution, it becomes a buyable tool and we look for something more difficult to program. One of the most important tools was and is the compiler. We look at why compilers are dependable and what we can learn from them.
We look at several important, best-practice themes for programming in general.
Clearly just about everyone needs to understand why there is such interest in objects, what they are and why they might be useful.
This chapter looks, very briefly, at the choices and compromises in choosing an object-oriented programming language.
Tim Berners-Lee propelled the Web into everyone's consciousness with the hypertext markup language HTML. HTML was based on SGML--the Standard Generalized Markup Language--but was fixed. SGML is large and overwhelming. In XML--the extensible markup language--we now have a manageable, extensible, HTML-sympathetic, descriptive vehicle that is being used for a wide variety of data communication tasks.
Databases are still one of the most successful applications of computers that there has ever been. We look at how they work and why they are one of the few success stories.
The relational data model is highly successful and quite old. We look at when it begins to break down and the alternatives. We look at the requirements that object technology has brought to long-term, bulk storage.
As software systems got larger and larger it became clear that a critical failure was occurring in the early planning stages. This chapter establishes the need to plan and structure our understanding of the problem--analysis--and to plan and structure the solution--design.
One of the most significant developments of the last ten years has been the near universal adoption of the UML as a standard software notation. We look at the nature of the UML and survey its contents.
How do human traits positively and negatively influence software engineering? This chapter puts managers, analysts, designers and programmers on the psychologist's couch.
In addition to the individual methods and techniques, it is vital to understand how they fit into the overall development process.
This chapter looks at one of the most notoriously difficult areas of project management: that of making realistic cost estimates. It looks at Boehm's COCOMO model as one of the few offerings in this area.
We look here at some of the aspects of controlling and supporting software projects.
Although often spoken about, testing and QA in general are still largely ignored or poorly done. Here, we look at informal reviews (walk-throughs), inspections and testing.
We recommend that there are no more than 12 participants, with the best results usually obtained when there are at least 8 participants. It is possible, by negotiation and mutual agreement, for more than 12 participants to be present.
Please contact John Deacon by telephone on +44 20 7498 3773; by fax on +44 20 7498 3747; by emailing jdeacon@jdl.co.uk; or by visiting http://www.jdl.co.uk
[ Home page | Courses List ]