You are on page 1of 28

CHAPTER 1 INTRODUCTION 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. The approach towards the systematic development of large scale software systems using techniques and tools to increase quality and productivity.

Another definition of SE

Software-related Problems

Hardware advances continue to outpace ability to build software Ability to build new programs cant 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

Products dynamic behaviour The use made of the product E.g. efficiency, reliability, maintainability, robustness, portability The importance of characteristics varies from system to system

Software Products
-Software product attributes

Process Characteristic
Understandability

Description

To what extent is the process explicitly defined & how easy is it to understand the process definition
Do the process activities culminate in clear results so that the progress of the process is externally visible? To what extent can the process activities be supported by CASE tools? Is the defined process acceptable to and usable by the engineers responsible for producing the software product?

Visibility

Supportability Acceptability

Software Products
-Software product attributes

Process Characteristic

Description

Reliability Robustness Maintainability Rapidity

Is the process designed in such a way that process errors are avoided or trapped before they result in product errors? Can the process continue in spite of unexpected problems? Can the process evolve to reflect changing organizational requirements or identified process improvements? 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.

The Software Process

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?

The Software Process

2 basic software development models:

The waterfall approach.

Requirement analysis & definition

goals & constraints are defined partitions requirements to either hardware or software verify that each unit meets its specification integrate & test as a complete system system is installed & put into practical use

System & software design Implementation & unit testing Integration & system testing

Operation & maintenance

Evolutionary development

The Software Process

The Software Process

2 types of evolutionary development

Exploratory programming

to work with the customer to explore their requirements & deliver a final system to understand the customer's requirements & hence develop a better requirements definition of the system

Throw-away prototyping

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.

Software Misconceptions

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.

Software Misconceptions

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.

Software Misconceptions

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.

Software Misconceptions

Practitioners 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.

Software Misconceptions

Practitioners 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

What Causes the Need for SE

What Causes the Need for SE

What Causes the Need for SE

Afflicting Problems

Data has not been collected on the software development process

thus there cant 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 customers requirements often there no systematic, complete software testing software maintainability has not been emphasized as an important criteria

Software quality is not suspect

Existing software can be difficult to maintain