Software Design

1.0 Software Characteristics

Software is a general term for the various kinds of programs used to operate computers and related devices.

Software can be thought of as the variable part of a computer and hardware the invariable part.

Software is a logical rather than a physically system element.

Therefore, software has characteristics that differ considerably from those of hardware:

 

1. Software is tangible  

  

2. Software is developed or engineered, it is not manufactured in the classical sense  

  

3. Software doesn’t “wear out”  

                       

 

4. Most software is custom-built, rather than being assembled from e

xisting components  

2.0 Software Myths

Myths are misleading attitudes that have caused

 serious problems for managers and technical people.

However, old attitudes and habits are difficult to modify, and remnants of software myths are still believed.

There are three category of software myths:

 

Management Myth

Managers with software responsibility, like man

agers in most discipline, are often under pressure to maintain budgets, keep schedules from slipping, and often improve quality.

Software manager often grasps at belief in a software myth, if that belief will lessen the pressure.  

  

Myth   

·We already have a book that’s full of standards an

d procedures for building software. Won’t that provide my people with everything they need to know?   

·My people do have state-of-the-art software development tools. After all, we buy them the newest computers   

·If we get behind schedule, we can add more programmers and catch up. This is sometimes called the ‘Mongolian horde concept.  

  

Customer Myth

A customer who requests computer software may be a person at the next desk, a technical group down the hall, the marketing/sales department, or an outside company that has requested software under contract.

In many cases, customer believes myths about software because software responsible managers and practitioners do little to correct misinformation. Myths lead to false expectations (by the customer) and ultimately dissatisfaction with the

 developers.  

  

Myth   

·A general statement of objectives is sufficient to begin writing programs – we can fill in the details later   

·Project requirements continually change, 

but change can be easily accommodated because software is flexible.  

  

Practitioner’s Myths

Myths that are still believed by software practitioners have been fostered by decades of programming culture.

During the early days of software, programming was viewed as an art.

Old ways and attitudes die hard.  

  

Myth   

·Once we write the program and get it to work, our job is done   

·Until I get the program running, I really have no way of assessing its quality   

·The only deliverable for a successful project is the working program  

3.0 Software Components

·Algorithms

·Programming languages : Low level, High-level and Very-high level

·Non-procedural languages

·Language translators : Interpreters, Compilers

·Data Structures

·Library routines : Functions & Subroutines

4.0 Attributes of good software

 

5.0 Software Applications

·Software may be applied in any situation for which a pre-specified set of procedural steps (eg; Algorithms) has been defined. Information content and determinancy are important factors in determining the nature of a software application. Content refers to the meaning and form of incoming and outgoing information. Information determinacy refers to the predictability of the order and timing of information. 

·The following software areas indicate the breadth of potential applications:

 

a)System Software   

b)Real-time software   

c)Business Software   

d)Engineering and scientific software   

e)Embedded software   

f)Personal computer software   

g)Web-based software   

h)Artificial Intelligence software  

6.0 Key Challenges Facing Software Engineering

·Software engineering in the 21st century faces three key challenges:

The legacy challenge: Challenge of maintaining and updating this software in such a way that excessive costs are avoided and essential business services continue to be delivered.

The heterogeneity challenge: Challenge of developing techniques to build dependable software which is flexible enough to cope with this heterogeneity

The delivery challenge: Challenge of shortening delivery times for large and complex systems without compromising system quality.

·Each of the above is not necessarily independent.

·For example, it may be necessary to make rapid changes to a legacy system to make it accessible across a network.

·To address these challenges, new tools and techniques are required as well as innovative ways of combining and using existing methods.

The problems with software

1.Poor quality systems 

2.Non-conformance to requirements 

3.High maintenance costs 

4.Schedule overruns 

5.Cost overruns 

The reasons for the problems

1.Poor user requirement capture 

2.The lifecycle forces the problems backwards 

3.Maintenance has a low priority 

4.Very little data collection 

5.Very little or no QA