Chapter 1 ASE Slides ppt

Software can have a hugeimpact in any aspect of society.

Importance of software

Where can you find software?

Some popular ones…

Some popular ones…

And even in…

Conclusion

Software is Almost Everywhere.

Problems in software development

•The final Software doesn´t fulfill the needs of the customer.

•Hard to extend and improve: if you want to add a functionality later is mission impossible.

•Bad documentation.

•Bad quality: frequent errors, hard to use, ...

•More time and costs than expected

Common issues

Chaos Report

It is not enough to do your best: you must Know what to do, and THEN do your best.-- W. Edwards Deming

Conclusion

Programming is NOT enough!

Solution

Software Engineering

The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. -Wikipedia

What is it?

Software Engineering

The study and application of methodologies to develop quality software that fulfill customer needs.

What is it?

Software EngineeringObjetive

To produce software that is:

• On time: is deliver at the established date.

• Reliable: doesn´t crash.

• Complete: good documentation, fulfill customer needs.

(CS340 J. Knight & T. Horton 2008)17

Process means the events or tasks a development organization does, and their sequence› Again, think about construction

Organizations want a well-defined, well-understood, repeatable software development process. Why?

Find and repeat good practices Management: know what to do next; know when we’re done

with current task; know if we’re late; estimate time to completion, costs; Etc.

New team-members know what to do

Major Task Identification Sequencing General model to be tailored

(CS340 J. Knight & T. Horton 2008)19

There are general principles about:› What we do at various stages of SW development

› How to inject quality into SW

› How to avoid early problems that cause huge problems later

› Recognize that SE is not just writing code

No matter what process you end up doing,these general principles are the most important “take-away” from this material

Build FirstVersion

Retirement

Operations

Modify untilCustomer satisfied

Really Bad Really Common Advantages› No Overhead› No Expertise

Disadvantages› No means of assessing progress› Difficult to coordinate multiple programmers

Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works

Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

REQUIREMENTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Articulated by Win Royce, ~1970 Widely used today Advantages› Measurable progress› Experience applying steps in past projects can be used in

estimating duration of “similar” steps in future projects› Produces software artifacts that can be re-used in other projects

The original waterfall model (as interpreted by many) disallowed iteration› Inflexible› Monolithic› Requirements change over time› Maintenance not handled well

The “waterfall with feedback” model was, however, what Royce had in mind

REQUIREMENTSANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE

Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

Requirements Change

Rapid Prototype

Validate

Retirement

Operations

Test

ImplementationVerify

Design

Requirements Change

Initial Concept

Complete and Release

Prototype

Refine Prototype Until Acceptance

Design and Implement

Initial Prototype

Prototypes used to help develop requirements specification› Useful for rapidly changing requirements› Or when customer won’t commit to specification

Once requirements “known”, waterfall (or some other process model) is used

Prototypes discarded once design begins› Prototypes should not be used as a basis for implementation,

since prototyping tools do not create production quality code› Customer may need to be “educated” about prototypes, a

prototype is not 80-90% of the final product (not even 10%)

Detailed Design, Implement, Test, Deliver Feature Set

Requirements

Validate

Retirement

Operations

Verify

Architectural Design

Iterations are classified according to feature sets

› e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next

Series of increasingly “complete” releases

PLAN DEVELOP AND TEST

DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS

EVALUATE ALTERNATIVESAND RISKS

Requirements,life-cycle plan

Budget 1

Alternatives1

Constraints1

Risk analysis1

Risk analysis2

Risk analysis3

Risk analysis4

Constraints 2

Constraints 3

Constraints 4

Budget2

Budget3Budget

4

Alternativ

es 2Alte

rnativ

es 3Altern

atives 4

Prototype1

Proto -type

2

Proto -type

3

Proto -type

4

Concept ofoperation

Softw

are

requ

irem

ents

Validated

requirements

Developmentplan

Integrationand test plan

Softw

are

desig

n

Validated,

verified design

Detaileddesign

Code

Unit test

Systemtest

Acceptancetest

Implementationplan

start

Proposed by Barry Boehm, ~1986 Similar to Incremental Model, but each iteration

is driven by “risk management” and/or customer feedback

Determine objectives and current status Identify risks and priorities Next iteration addresses (current) highest risk and/

or highest priority items Repeat