c


1. When and how did the term software engineering originate?

In late 1967 the NATO (North Atlantic Treaty Organisation) Science
Committee Study Group recommended the holding of a working conference on
software engineering. The term software engineering was deliberately chosen as
being provocative, in implying the need for software manufacture to be based on the
types of theoretical foundations and practical disciplines that are traditional in the
established branches of engineering.

2. What is meant by the term software crisis?

The term was used to describe the impact of rapid increases in computer
power and the complexity of the problems which could be tackled. In essence, it
refers to the difficulty of writing correct, understandable, and verifiable computer
programs.

3. Which professional institution represents UK software engineers?

British Computer Society(BCS)

4. Describe the general relationship between software engineering and computer

science.
Software engineering builds on computer science in the way that other
engineering disciplines build on traditional science (and mathematics).

5. What is meant by the term Software as a Service?

The concept of Software as a Service (SaaS) originated in ~2000; the idea is
that users must pay regular small amounts to use software via a subscription rather
than paying a much larger amount initially to own it. This is very appropriate for
software that is hosted remotely and used via the inte rnet.

6. How has the relative cost of software versus hardware changed over the last 30
years or so in engineered systems generally?
Over the past three decades engineered systems in general have come to rely
more and more on microprocessor technology, a nd consequently on software. As a
result, the cost of the software within engineered s ystems has increased
dramatically with respect to the cost of the hardware« This increase in the cost of
the software is due to an increase in the complexity of the softw are. Complexity
makes it hard«
1.p for users to know what they want,
2.p for developers to understand what users want,
3.p to know how long a project will take,
4.p not to make mistakes (in specification, design etc.),
5.p to understand how a given piece of software works ,
6.p to reuse existing complex software components,
7.p to test software,
8.p to debug software,
9.p to modify software.
7. Roughly speaking, how many lines of code does the average software developer
produce per working day, what does it depend on, and which of the following
typically requires the most/least effort:
(a) Coding:
(b) Testing:
(c) Analysis & design:
The average programmer produces ³only´ about 10 -20 lines of source code
per day on average, an d this figure is independent of the level of programming
language used. This is an average figure; it may be higher or lower depending on«
p the type of system being built (but not the programming language),
p individual ability ± which can vary greatly.

8. What is the relationship between errors, faults and failures in the context of
software engineering?
p errors: mistakes made by software developers,
p faults: the tangible results arising from errors,
p failures: unwanted behaviours resulting from faults.

9. What is the relationship between products, processes and resources?

In the context of software development, a process is an activity or a series of
activities. Most processes are geared towards generating some kind of product, such
as a statement of requirements, a design, or an executable program.
Resources Process Product(s).

10. What is meant by ad hoc software development?

³Ad hoc´ means ³one off´ ± i.e. potentially different every time. Ad hoc
processes are usually unplanned, left to personal preference, and difficult to
manage. This may be OK for an individual working on a small project, but it is
unsuitable for an organisation that has to develop complex products in a methodical
and manageable way.

11. Explain the waterfall model of software development.

The waterfall approach to software development is often spoken of as being
the traditional approach. It is a sequential model where the development process
goes through a number of phases in a certain order. Once a phase of
development is completed, the development proceeds to the next phase and
there is no turning back. The main problem with the waterfall approach is that (in
theory) the user doesn¶t get to see the end product until near the end of the project.

12. Explain the difference between throwaway and evolutionary prototyping.

A throwaway prototype is often constructed as an initial 



,
especially when undertaking a technically demanding project. 



 

looks just like the one for throwaway prototyping,
except that the output this time is a 
rather than just a specification.

13. Give two reasons why a software developer might decide to develop a prototype.

p a working prototype can be a good way of winning support from

management,
p a working prototype can be used for training purposes,
14. Describe four potential benefits and four potential problems associated with
prototyping.
Potential benefits, including«
p >misunderstandings between customer and supplier can be exposed early,
p >errors in the specification may be exposed early (actually there¶s less
emphasis on a written
p specification now, whereas it often formed a binding contract in traditional
waterfall-style projects),
p >missing functionality may be detected early,
p >difficult or confusing functions can be identified and refined early,
p >a working prototype can be a good way of winning support from
management,
p a working prototype can be used for training purposes,
p the customer will (hop efully) be more satisfied with the final product, since
they have seen it develop.

There are various potential pitfalls though, from the point of view of users, software
developers and managers.
The users may«
p be led to believe that the system will be rea dy soon,
p keep changing their minds, if they are given the opportunity to do so,
p get carried away with some aspects of the requirements but neglect other
aspects.
The developers may«
p neglect to undertake a thorough requirements analysis,
p get frustrated that the users keep changing their minds,
p neglect non-functional aspects of the design (e.g. reliability, performance,
ease of maintenance).
The managers may«
p find it hard to predict and control the number of design iterations that are
necessary,
p find it hard to enforce configuration management, leading to confusion about
which versions of which modules make up a given prototype.

15. It¶s important to manage expectations when showing a prototype to a customer;

explain why it is important, and what it entails.

16. What are 


?
Agile methods are based on evolutionary prototyping, and the concept of
 
 
 

(RAD). One of the key principles is 
, which is
the idea that the  

, rather than the  
, must be fixed« To
allow for this, individual requirements are often classified in some way.
17. Explain what 
is, and why the user requirements need to be prioritised
to cater for timeboxing.