UNIT 2 MODULE 1

Software and System

Development

Topic : Software
Development
Compiled by:
Careene McCallum-Rodney
INTRODUCTION TO SOFTWARE
DEVELOPMENT
__________________________________________________
Every field of study has its own name for the systematic
____
method used to solve problems by designing suitable
solutions. In the world of software, the procedure is called
the software development procedure.

Software Development ensures that the software produced

meet the specification required.

This aspect of the syllabus is really focusing on software

engineering. Software Engineering is concerned with
the theories, methods and tools which are needed to
develop the software for computers.
 SUB-TOPIC

The need for a

structured software
development process
Specific Objective
Students should be able to explain the reasons for a
structured approach to software development process
 The need for a
structured
software
development
Increased
process
Dependence of many
organizations on their Increasing cost of
Dissatisfaction of users
and management with computer system software development
the quality and
suitability of the
software Crises in Increasing length and
previous complexity of the
software
developments

Requirements for
standard interfaces

Need for tighter

control and
management of
process
Home Exit
1. Increased Dependence of many organizations

on their computer system

In all industrialized countries, and increasingly in developing
countries, computer systems are economically critical. More and
more products incorporate computers in some form. Educational,
administrative and health care systems are dependent on computer
systems. The software in these systems represents a large and
increasing proportion of the total system costs. The effective
functioning of modern economic and political systems therefore
depends on the ability to produce software in a cost effective way.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments
A "large" software system is a system that contains more than 50,000
lines of high-level language code. Its those large systems that bring
the software crisis to light. With large software development
projects, the work is done in teams consisting of project managers,
requirements analysts, software engineers, documentation experts,
and programmers. With so many professionals collaborating in an
organized manner on a project, whats the problem? Why is it that the
team produces fewer than 10 lines of code per day over the average
lifetime of the project? And why are sixty errors found per every
thousand lines of code? Why is one of every three large projects
scrapped before ever being completed? And why is only 1 in 8
finished software projects considered "successful?"

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments
Conflicting requirements have always hindered the software
development process. For example, while users demand a large
number of features, customers generally want to minimize the
amount they must pay for the software and the time required for
its development.
The causes of the software crisis were linked to the overall
complexity of the software process and the relative immaturity of
software engineering as a profession.

A structured software development process is mindful of the

Software Crisis, and there are methods being implemented by
this process to deal with the crisis.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments

Software Crisis can be categorized as follows:

Increasing cost of software development

Dissatisfaction of users and management

with the quality and suitability of the
software
Increasing length and complexity of the
software

Assignment 1

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments
INCREASING COST OF SOFTWARE DEVELOPMENT
The cost of owning and maintaining software in the 1980s was twice as
expensive as developing the software. During the 1990s, the cost of
ownership and maintenance increased by 30% over the 1980s.

Not only has software development become more costly (especially for
bespoke products), but additionally, many times the projects run over-budget.

Software can be difficult to maintain. Software maintenance accounts for the

majority of all software budgets. Many software programs consist of errors
that were not realized in the implementation process. When maintaining
existing software programs it is threatened by poor design (in terms of coding
and documentation) as well as inadequate resources. When this occurs, the
development process can be very costly and time consuming.

Changes during design, implementation and installation have a severe impact

on cost

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments

DISSATISFACTION OF USERS AND MANAGEMENT WITH

THE QUALITY AND SUITABILITY OF THE SOFTWARE

Early experience in building large software systems showed that existing

methods of software development were not good enough. Techniques
applicable to small systems could not be scaled up.

Major projects were sometimes years late.

They cost more than were originally predicted, were unreliable, difficult to
maintain and performed poorly.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments
DISSATISFACTION OF USERS AND MANAGEMENT WITH
THE QUALITY AND SUITABILITY OF THE SOFTWARE

Three quarters of all large software products delivered to the customer are
failures that are either not used at all, or do not meet the customers real
needs or requirements. This is so because software development is often
undertaken with only a vague notion of the customers requirements. Many
software efforts have failed because developers lack the essential formal
and detailed description on data, functionality, design constraint and
validation criteria, which can be accessed through frequent communication
between developers and customers.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments

INCREASING LENGTH AND COMPLEXITY OF THE

SOFTWARE

Projects were unmanageable and code difficult to maintain.

As long as there were no machines, programming was no problem at

all; when we had a few weak computers, programming became a mild
problem, and now we have gigantic computers, programming has
become an equally gigantic problem.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments
INCREASING LENGTH AND COMPLEXITY OF THE
SOFTWARE

Another problem that still exists in software development is the time taken
to develop software. Software developers regularly underestimate how
long it takes to design, write and test their software. Mostly, this problem
still exists because developers are trying to produce massive software
products with old tools, outdated methods and inadequate management
techniques. Sometimes, the assumptions made is that, if the software is
behind schedule, more programmers can be added and thus hasten the
process. Adding people to a late software project makes it later. Another
contributing factor to the time factor is that project requirements continually
changes. The impact of change will vary according to when it was
introduced.

NEXT PREVIOUS MAIN MENU

2. Crises in previous developments

ASSIGNMENT ONE (Due date: to be discussed)

Write a 800 word essay on Software Crisis. The essay must include:

1. Explanation of at least 2 major software crisis.

2. Recommended solution or minimization of the above crisis.

3. Use the MLA research style (you need to personally research this
method) of writing throughout the essay and also for the bibliography.

4. Must use at least 3 books and 2 websites. Special marks are allotted to
students who use computer journals or magazines and personally
interviewed a software developer or expert.

NEXT PREVIOUS MAIN MENU

3. Requirements for standard interfaces

When applied to computer software, User Interface Design is also known

as Human-Computer Interaction or HCI. While people often think of
Interface Design in terms of computers, it also refers to many products
where the user interacts with controls or displays. Military aircraft, vehicles,
airports, audio equipment, and computer peripherals, are a few products
that extensively apply User Interface Design.

The more intuitive the user interface the easier it is to use, and the easier it
is to use and the less expensive to use it. The better the user interface the
easier it is to train people to use it, reducing your training costs. The better
your user interface the less help people will need to use it, reducing your
support costs. The better your user interface the more your users will like
to use it, increasing their satisfaction with the work that you have done.

NEXT PREVIOUS MAIN MENU

3. Requirements for standard interfaces

A fundamental reality of application development is that the user interface

is the system to the users. What users want is for developers to build
applications that meet their needs and that are easy to use. Too many
developers think that they are artistic geniuses they do not bother to
follow user interface design standards or invest the effort to make their
applications usable, instead they mistakenly believe that the important
thing is to make the code clever or to use a really interesting color
scheme. A good user interface allows people who understand the problem
domain to work with the application without having to read the manuals or
receive training.

NEXT PREVIOUS MAIN MENU

3. Requirements for standard interfaces

The user interface is often the yardstick by which that system is judged.
An interface which is difficult to use will, at best, result in a high level of
user error. At worst it will cause the software system to be discarded,
irrespective of its functionality. If information is presented in a confusing
and misleading way, the user may misunderstand the meaning of an item
of information. They may initiate a sequence of actions which corrupt data
or cause catastrophic system failure.

NEXT PREVIOUS MAIN MENU

3. Requirements for standard interfaces
These principles govern the structure of user interface:

The structure principle. Your design should organize the user interface
purposefully, in meaningful and useful ways based on clear, consistent
models that are apparent and recognizable to users, putting related
things together and separating unrelated things, differentiating
dissimilar things and making similar things resemble one another. The
structure principle is concerned with your overall user interface
architecture.

The simplicity principle. Your design should make simple, common tasks
simple to do, communicating clearly and simply in the users own
language, and providing good shortcuts that are meaningfully related to
longer procedures.

The visibility principle. Your design should keep all needed options and
materials for a given task visible without distracting the user with
extraneous or redundant information. Good designs dont overwhelm
users with too many alternatives or confuse them with unneeded
NEXT PREVIOUS MAIN MENU
information.
3. Requirements for standard interfaces

The feedback principle. Your design should keep users informed of

actions or interpretations, changes of state or condition, and errors or
exceptions that are relevant and of interest to the user through clear,
concise, and unambiguous language familiar to users.

The tolerance principle. Your design should be flexible and tolerant,

reducing the cost of mistakes and misuse by allowing undoing and
redoing, while also preventing errors wherever possible by tolerating
varied inputs and sequences and by interpreting all reasonable actions
reasonable.

The reuse principle. Your design should reuse internal and external
components and behaviors, maintaining consistency with purpose
rather than merely arbitrary consistency, thus reducing the need for
users to rethink and remember.

NEXT PREVIOUS MAIN MENU

3. Requirements for standard interfaces

ASSIGNMENT TWO Due Date : To be discussed

This assignment is to be done in groups of two.

Requirements:

Seek out a customized or generic software which implements user

interfaces. Write an essay on the strong and weak areas of the
interfaces, based on facts. Pictures of the interfaces are to be
included. Additionally each group will get a total of 7 minutes to present
their analysis of the interface.

Additional marks will be allotted to proof of additional research,

presentation, grammar and consistent and correct use of the APA
format.
Oral presentation is expected to be organized and properly presented.

NEXT PREVIOUS MAIN MENU

4. Need for tighter Control and Management of Process

What is the Software Process?

This is the set of activities and associated results which produce a software
product. These activities are mainly carried out by software engineers.

There are 4 fundamental process activities which are common to all

software processes. These activities are:

1. Software specification

The functionality of the software and constraints on its operation

must be defined.

2. Software Development

The software to meet the specification must be produced.

NEXT PREVIOUS MAIN MENU

4. Need for tighter Control and Management of Process

3. Software validation
The software must be authenticated to ensure that it does what the
customer wants.
4. Software evolution
The software must develop to meet changing customer needs.

There are no such thing as a right or wrong process. Different software

processes decompose these activities in different ways. The timing of
the activities varies as does the results of each activity.

NEXT PREVIOUS MAIN MENU

4. Need for tighter Control and Management of Process

WHY IS THERE A NEED FOR THE ABOVE?

Different organizations use different processes to produce the same

type of product. Different types of product may be produced by an
organization using different processes. However, some processes are
more suitable than others for some types of application. If the wrong
process is used, this will probably reduce the quality of or the
usefulness of the software product to be developed.

Because there are a variety of different process models used, it is

impossible to produce reliable figures for cost distribution across these
activities. However, modifying software usually takes up more than 60%
of total software costs. This percentage is

NEXT PREVIOUS MAIN MENU

4. Need for tighter Control and Management of Process

increasing as more and more software is produced and has to be

maintained.

Software processes are complex and involves a very large number of

activities. These activities need to be managed appropriately and
efficiently.

Consider the :

1. process characteristics

2. need for process visibility

3. need for risk management

NEXT PREVIOUS MAIN MENU

PROCESS CHARACTERISTICS
Understandability To what extent is the process explicitly defined and how easy is it
to understand to process definition?

Visibility Do the process activities culminate in clear results so that the

progress of the process is externally visible?

Supportability To what extent can the process activities be supported by CASE

tools?

Acceptability Is the defined process acceptable to and usable by the engineers

responsible for producing the software product?

Reliability Is the process designed in such a way that process errors are
avoided or trapped before they result in product errors?

Robustness Can the process continue in spite of unexpected problems?

Maintainability Can the process evolve to reflect changing organizational

requirements or identified process improvements?

Rapidity How fast can the process of delivering a system form a given
specification be completed?

NEXT PREVIOUS MAIN MENU

NEED FOR PROCESS VISIBILITY
Because of the intangible nature of software systems, software process
managers need documents, reports and reviews to keep track of what
is going on. Each activity must end with the production of some
document. These document make the software process visible.

However, regular document production has some drawbacks:

1. Management needs regular deliverables to assess project progress

The timing of management requirements may not correspond with the

time needed to complete an activity. Extra documents may have to be
produced adding to the cost of the process.

NEXT PREVIOUS MAIN MENU

NEED FOR PROCESS VISIBILITY
2. The need to approve document constrains process iterations

The cost of going back and adapting a complete deliverable are high.
If the problems are discovered during the process, inelegant solutions
are sometimes adopted to avoid the need to change accepted project
deliverables.

3. The time required to review and approve a document is significant

There is rarely a smooth transition from one phase of the process to

the next. Development may continue before the previous phase
document has been completed.

NEXT PREVIOUS MAIN MENU

NEED FOR RISK MANAGEMENT
Risk is a concept that is difficult to define precisely. Informally, it is simply
something which can go wrong. For example, if the intention is to use
a new programming language, a risk is that the available compilers are
unreliable or do not produce sufficiently efficient object code.

Risks are a consequence of inadequate information. They are resolved

by initiating some actions which discover information that reduces
uncertainty. In the above example, the risk would be resolved by a
market survey to find out which compilers are available and how good
are they. If no suitable system was discovered, the decision to use a
new language must be changed.

NEXT PREVIOUS MAIN MENU

NEED FOR RISK MANAGEMENT
Risk Management is a method for dealing with project risks, by identifying
and handling them appropriately. This method is on-going and is used
throughout the life of the project.

BASIC APPROACH

Analysis of project, so that you can identify risks involved.

For each risk identified, the following steps are taken:

Impact and Probability Analysis (the nature of the risk),

Avoidance Plan ( How to minimize risks), and

Contingency Plan (What to do if it occurs).

NEXT PREVIOUS MAIN MENU

NEED FOR RISK MANAGEMENT
Risk Management
(Cost, Expectation and
R is k I d e n t if ic a t io n Technical)
(properly investigating the risk, also
R is k A n a ly s is looking at the likelihood of
occurrence and its impact)

R is k A s s e s s m e n t R is k E x p o s u r e (What we will lose if the risk

occur)

R is k P r io r itiz a tio n

R is k M a n a g e m e n t
R is k R e d u c tio n
C o n tin g e n c y P la n n in g
R is k C o n t r o l
R is k M o n it o r in g
C o n tin u o u s R e a s s e s s m e n t

NEXT PREVIOUS MAIN MENU

NEED FOR RISK MANAGEMENT
RISK REDUCTION CONTINGENCY PLANNING

Avoiding Risk Some risks cannot be

Modifying project reduced
requirements Plan for risk occurrence
Transferring the Risk Why?
By allocation to other Reduces Crisis
systems atmosphere
Buying Insurance to cover Reduces chance of
financial loses mistakes
Mitigating the Risk Reduces time to correct
Pre-Event Actions to:
Reduce Likelihood of
Occurrence and/or
Minimize Impact

NEXT PREVIOUS MAIN MENU

NEED FOR RISK MANAGEMENT
MONITORING AND CONTINUOUS REASSESSMENT

Periodic Review of Risk Status

Changes in Probabilities or Impacts
Changes in Avoidance/Mitigation/Contingency Plans

Periodic Review of Project to Identify New Risks

Implementation of Risk Avoidance or Mitigation Plans

Keep Management and Customers Informed!!!

Frequent Risk Reviews

NEXT PREVIOUS MAIN MENU

ASSIGNMENT 3 Due Date: To
be discussed.
Arrange yourself in groups of two. At most two groups will present
on one of the following Life Cycle Models:

1. Waterfall Approach
2. Evolutionary Development including rapid prototyping.
3. Fountain Approach
4. Formal Transformation
5. Re-use oriented approach

Use powerpoint presentation to assist in conveying information.

Each group has a maximum of 10 minutes to present.

Evidence of research (at least 2 books and 2 websites) is important.

Hence, a bibliography slide is to be included in the presentation.

NEXT PREVIOUS MAIN MENU