Software System Engineering - Chapter 1

CHAPTER 1INTRODUCTION TO

SOFTWARE ENGINEERING

SOFTWARE SYSTEM ENGINEERING

(260CT)

INTRODUCTION TO SOFTWARE ENGINEERING

Introduction to Software Engineering (SE)

Software Products Software Process Software Misconceptions What Causes the Needed of SE

Introduction to Software Engineering

IEEE definition of Software Engineering (SE)

• A systematic approach towards development, operation, maintenance and retirement of software where, software is defined as related programs, procedures and documentation.

Another definition of SE

• The approach towards the systematic development of large scale software systems using techniques and tools to increase quality and productivity.

Software-related Problems Hardware advances continue to outpace ability to

build software Ability to build new programs can’t keep pace with

demand Society dependent on reliable operation of software Struggle to build software that has high reliability &

quality Ability to support & enhance existing programs is

threatened by poor design & inadequate resources Product delivered late

Software Products Objective of SE: to produce software products. Software products are software systems delivered to

customer with the documentation which describe how to install and use the system.

2 classes of software products:• Generic products. Stand-alone systems which are

produced by a development organization and sold open market to any customer who is able to buy them.

• Bespoke (customized products). These are systems which are commissioned by a particular customer. The software is developed specially for that customer by some contractor.

Software Products-Software product attributes

The characteristics displayed by the product once it is installed and put into use

• Product’s dynamic behaviour

• The use made of the product

• E.g. efficiency, reliability, maintainability, robustness,

portability

• The importance of characteristics varies from system to system


Process Characteristic Description

Understandability To what extent is the process explicitly defined & how easy is it to understand the 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?


Process Characteristic Description

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 can the process of delivering a system from a given specification be completed?

The Software Process

The set of activities and associated results which produce a software product, which are carried by software engineers.

CASE (computer-aided software engineering) tools is used to help some process activities.


4 fundamental process activities common to all software processes:

• Software specification. The functionality of the software & constraints on its operation must be defined.

• Software development. The software to meet the specification must be produced.

• Software validation. The software must be validated to ensure that it does what the customer wants.

• Software evolution. The software must evolve to meet changing customer needs.

The Software Process-Process characteristics

Process characteristic Description

Understandability To what extent is the process explicitly defined & how easy is it to understand the 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 can the process of delivering a system from a given specification be completed?


2 basic software development models:

• The waterfall approach.

• Requirement analysis & definition

• goals & constraints are defined

• System & software design

• partitions requirements to either hardware or software

• Implementation & unit testing

• verify that each unit meets its specification

• Integration & system testing

• integrate & test as a complete system

• Operation & maintenance

• system is installed & put into practical use

• Evolutionary development



2 types of evolutionary development

• Exploratory programming

• to work with the customer to explore their requirements & deliver a final system

• Throw-away prototyping

• to understand the customer's requirements & hence develop a better requirements definition of the system

Software Misconceptions

Management Misconceptions• There are standards and procedure existed for producing

software.

In reality:

• Standards are rarely used & are often out-of-date and

incomplete.

• Developers rarely know about them.

• State-of-art hardware is the essential ingredient for successful software production.

In reality:

• Software, not hardware, tools are usually more

important for achieving quality and productivity.


Management Misconceptions• If we get behind schedule, we can always add more

programmers and thus catch up.

In reality:

• Software development is not a mechanistic process.

• Adding people to a late software project makes it later.

• Newcomers must be educated (usually by those working on the project) thereby reducing the amount time spent on productive effort.


Customer Misconceptions• A general statement of objectives is sufficient to begin

writing programs; details can be filled later.

In reality:

• Insufficient knowledge about requirements is the major cause of failed software efforts.

• Formal & detailed descriptions of data, functionality, design constraints & and validation criteria are essential.

• Communication between customer & developer is vital.


Customer Misconceptions• Project requirements continually change, but change

easily accommodated because software is flexible.

In reality:

• The impact of change varies with the time at which it is introduced.

• Early request for change can be accommodated easily and cheaply.

• Changes made during design, implementation & installation have a severe impact on cost.


Practitioner’s Misconceptions• Once the program is written and works, the job is done.

In reality:

• Between 50%-70% of all effort expended on a program will be expended after it is delivered to the customer.

• There is no way to access quality until the program is running.

In reality:

• Formal technical review is one of the most effective quality assurance tools & can be applied from the inception of the project.


Practitioner’s Misconceptions• The only deliverable is the working program(s).

In reality:

• It is only one part of a software configuration that includes requirements & specification documents, testing information & other developmental & maintenance information.

What Causes the Need for SE

Factors contribute to software failure• Badly design interface

• Creeping featurism

• Unrealistic goals

• Undefined responsibilities

• Missed user requirements

• Misunderstanding




What Causes the Need for SE Afflicting Problems

• Data has not been collected on the software development process

• thus there can’t be accurate evaluation of the efficiency of new tools, methods or standards

• Customer dissatisfaction with the completed system is frequently encountered

• software development is undertaken often with notation of the customer’s requirements

• Software quality is not suspect

• often there no systematic, complete software testing

• Existing software can be difficult to maintain

• software maintainability has not been emphasized as an important criteria