1

SYNAPSEINDIA FEEDBACK ON SOFTWARE

ENGINEERING AND THE SOFTWARE LIFECYCLE

Software engineering: the profession, practiced by developers, concerned with creating and maintaining software applications by applying technologies and practices from computer science, project management, and other fields.

Software engineering has accepted as its charter, "How to program if you cannot." -- E. Dijkstra

The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today. -- F. Brooks

2

SOFTWARE ENGINEERING

people involved in software production customer / client: wants software built

often doesn't know what he/she wants managers / designers: plan software

difficult to foresee all problems and issues in advance developers: write code to implement software

it is hard to write complex code for large systems testers: perform quality assurance (QA)

it is impossible to test every combination of actions users: purchase and use software product

users can be fickle and can misunderstand the product

3

ROLES OF PEOPLE IN SOFTWARE

Example: Space shuttle software cost: $10 Billion, millions of dollars more than planned time: 3 years late quality: first launch of Columbia was cancelled

because of a synchronization problem with the Shuttle's 5 onboard computers error was traced back to a change made 2 years earlier

when a programmer changed a delay factor in an interrupt handler from 50 to 80 milliseconds

the likelihood of the error was small enough, that the error caused no harm during thousands of hours of testing

substantial errors still exist in the code astronauts are supplied with a book of known software problems

"Program Notes and Waivers" reusabilty: shuttle software cannot be reused

Have to develop each software product from scratch

4

PROBLEMS WITH SOFTWARE TODAY

ad-hoc development: creating software without any formal guidelines or process

what are some disadvantages of ad-hoc development?

5

AD-HOC SOFTWARE DEVELOPMENT

some important actions (testing, design) may go ignored

not clear when to start or stop doing each task

does not scale well to multiple peoplenot easy to review or evaluate one's work

software lifecycle: series of steps / phases, through which software is produced can take months or years to complete

goals of each phase: mark out a clear set of steps to perform produce a tangible document or item allow for review of work specify actions to perform in the next phase

common observation: The later a problem is found in software, the more costly it is to fix

6

THE SOFTWARE LIFECYCLE

standard phases1. Requirements Analysis & Specification2. Design3. Implementation, Integration4. Testing, Profiling, Quality Assurance5. Operation and Maintenance

other possible phases risk assessment: examining what actions are

critical and performing them first (part of Spiral model)

prototyping: making a quick version of the product and using it to guide design decisions

7

LIFECYCLE PHASES

8

ONE VIEW OF SW CYCLE PHASES

Subsystems

Structured By

class...class...class...

SourceCode

Implemented By

Solution Domain Objects

Realized By

SystemDesign

ObjectDesign

Implemen-tation

Testing

Application

Domain Objects

Expressed in Terms Of

Test Cases

?

Verified By

class....?

RequirementsElicitation

Use CaseModel

Analysis

Several models for developing software (besides ad-hoc) have been attempted: code-and-fix: write some code, debug it, repeat until finished evolutionary: build initial requirement spec, write it, then

"evolve" the spec and code as needed waterfall: perform the standard phases (requirements, design,

code, test) in sequence rapid prototyping: write an initial "throwaway" version of the

product, then design, code, test spiral: assess risks at each step, and do the most critical action

immediately

9

SOME SOFTWARE MODELS

10

CODE-AND-FIX MODEL

Code FirstVersion

Retirement

Operations Mode

Modify untilClient is satisfied

What are some reasons not to use the code-and-fix model?

11

PROBLEMS WITH CODE-AND-FIX

code becomes expensive to fix (bugs are not found until late in the process)

code didn't match user's needs (no requirements phase!)

code was not planned for modification, not flexible

12

EVOLUTIONARY MODEL

For each build:Perform detaileddesign, implement.Test. Deliver.

Requirements

Verify

Retirement

Operations

Verify

Arch. Design

The evolutionary model is similar to code-and-fix, but it assumes the repetitions are "evolutions" of the code, not necessarily bug fixes. Problems with this?

13

PROBLEMS WITH EVOLUTIONARY

difficult to distinguish from code-and-fix assumes user's initial spec will be flexible; fails

for: separate pieces that must then be integrated "information sclerosis": temporary fixes become

permanent constraits bridging; new software trying to gradually replace

old wrong order: makes lots of hard-to-change code

14

WATERFALL MODEL (ROYCE, 1970)

Requirements

Verify

Retirement

Operations

Test

ImplementationVerify

Design

Req. Change

15

RAPID PROTOTYPING MODEL

Rapid Prototype

Verify

Retirement

Operations

Test

Re-implementationVerify

Redesign

Req. Change

The waterfall models (with or without prototyping) are perhaps the most common model for software development we will use waterfall in this course!

What are some positives and negatives about this method?

16

WATERFALL / PROTOTYPING ISSUES

+ formal, standard, has specific phases with clear goals

+ good feedback loops between adjacent phases

- rigid, too linear; not very adaptable to change in the product

- requires a lot of planning up front (not always easy / possible)

- assumes that requirements will be clear and well-understood

17

SPIRAL MODEL (BOEHM)

Concept of Operation

Requirements Plan

Requirements OAC

Risk Assessment

Requirements

Risk Control

Requirements Validation

Abstract Specification Plan

Abstract Specifcation OAC

Risk Assessment

Risk Control

Abstract Specification

Abstract Specification Validation

Concrete Specification Plan

Concrete Specification OAC

Concrete Specification

Concrete Specification Validation and Verification

Software Development Plan

Risk Assessment

Risk Control

Progress through steps

Cumulative cost

Evaluate alternatives, identify, resolve risks

Develop, verify next-level product

Plan next phases

CommitReview

partition

Determine objectives, alternatives, constraints (OAC)

18

ANOTHER VIEW OF SPIRAL MODEL

Requirements

Verify

Retirement

Operations

Test

ImplementationVerify

Design

Req. Change

Adds a Risk Analysisstep to each phase

(phases may not be completed in this orderany more!)

Risk Assessment

Risk Assessment

Risk Assessment

What are some positives and negatives about this method?

19

SPIRAL MODEL PROBLEMS

+ focuses attention on reuse

+ accommodates changes, growth

+ eliminates errors and unattractive choices early

+ limits to how much is enough (not too much design, reqs, etc)

+ treats development, maintenance same way

- matching to contract software (doesn't work well when you're bound to a fixed inflexible contract)

- relying on developers to have risk-assessment expertise

- need for further elaboration of project steps (clearer milestones)

CASE (Computer-Aided Software Engineering) requirements / spec generation software design diagram (UML) software integrated development environments (IDEs) test suites (JUnit) and benchmarking / profiling software

20

TOOLS FOR SOFTWARE ENGINEERS