9
CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Embed Size (px)

Citation preview

Page 1: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

CSC 354 – Software Development Life Cycles & Processes, Spring 2013

April 9, 2013Dr. Dale Parson

Page 2: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Waterfall Model

• This classic model performs each phase of software construction sequentially and never goes back.

• Requirements gathering & specification (from customers), functional specification (architect to customers), high-level & low-level design specification (architect & developers), testing specs, user manuals.

• In the face of too-little-information at the start, and incremental acquisition of domain, requirements and design knowledge, the Waterfall Model is unresponsive to change and prone to failure.

Page 3: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Iterative Development, Prototyping

• Iterative development is a repetitive cycle of small waterfalls, where each major phase develops a subset of a big system, with its own requirement through deployment sub-phases.

• Rapid prototyping is construction of partial solutions, stubs and driver code that completes some parts, partially completes some, and skips others.

• It may use a high-level domain or prototyping language.• Spiral design combines iterative development

(prototyping & consolidation) with the Waterfall.• We are doing spiral design with each semester’s overall

project being a sub-phase.

Page 4: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Surgical Team Approach

• This is the process we are using this semester.• The Chief Surgeon is the Architect.

• The Architect is the team leader for the team leaders.• The Architect is responsible for Conceptual Integrity –

one or a few minds steer the central architectural concepts and structures.

• Individual project teams have leaders.• Creativity is manifest in design and implementation.• This approach is hierarchical.

Page 5: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Model-Driven Architecture

• Use a modeling approach such as Unified Modeling Language (UML) to drive the architecture & design.

• We are using UML for sketches (a.k.a. maps).• Strong proponents promote models for blueprints &

even as a substitute for code via CASE (Computer Aided Software Engineering) tools.

• Domain-specific tools (e.g. parser generators) and domain-specific modeling languages exist, but generally CASE tools generate only the boilerplate code.

• http://martinfowler.com/bliki/ModelDrivenSoftwareDevelopment.html

Page 6: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Model-Driven Tools

• Creation tool creates models.• Analysis tool analyzes models (e.g., for completeness.)• Transformation tool transforms models into other models,

documentation, or code.• Composition tool merges model hierarchies.• Simulation & test tools test models & code.• Metadata management tool controls mappings between

models and to code.• Reverse engineering tool transforms legacy code into models.

Page 7: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Agile & Extreme – Good Parts

• Agile Programming (including “Scrum”) and Extreme Programming are the fashion.

• There is minimal reliance on formal specs.• Everything lives in the code. (I like UML maps.)• Have a working copy of the code at the end of

every day. (I am underlining the good ideas.)• Integrate tests into the build & test repository

as you write code or even before.

Page 8: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Agile & Extreme – some OK Parts

• Sit together. (Max communication bandwidth.)• Tear down the cubicle walls?• I like some privacy.• The corporate drones like hive mentality.

• Keep the architect involved in coding.• Flatten development organization structure.• Pair programming: “Write all production programs with all

people sitting at one machine.” ???• There seems to be an over-emphasis on cosmetic details.

“Extreme” too easily becomes another religion.

Page 9: CSC 354 – Software Development Life Cycles & Processes, Spring 2013 April 9, 2013 Dr. Dale Parson

Become More Human

• Slavish adherence to any development methodology becomes too doctrinaire.

• Individuals need to be able to learn.• Organizations need to be able to learn.• Learning entails experimenting & adapting.• Processes are fundamentally machines.• Don’t let the machines do your thinking for

you.