seng 209 software engineering
DESCRIPTION
SENG 209 Software engineering. Software Development Process Timothy Korson [email protected]. Software development. A software development process is the set of activities needed to transform a user’s requirements into a software system. Software Development Process. Software system. - PowerPoint PPT PresentationTRANSCRIPT
2
Software development
A software development process is the set of activities needed to transform a user’s requirements into a software system
User’s Requirements Software DevelopmentProcess
Software DevelopmentProcess
Software system
3
Basic Goals of a Software Development Process
Correct, Robust, High Quality Software that is easy to use and meets real business needs
Modifiable Software Extensible Software Portable, Integrable Software Rapid Development Capability Maximize Productivity Minimize Costs
4
Modern Software Processes Promise to:
Support RAD through reuse of components, design patterns, architectural frameworks, and domain models
Improve product quality Facilitate business process reengineering Solve problems of greater complexity Improve maintainability and extensibility Improve communication with customers Improve communication between developers
5
Potential Benefits An optimal use of object-oriented technology requires a
new development process Any promised benefits from the use of OT are only
potential benefits. They do not magically happen. They require specific management practices to make them happen
Rarely however, do corporate policies and practices encourage managers to follow good, modern software engineering techniques
6
In Fact: Most corporate policies and practices actively discourage
managers from following good, modern software engineering techniques
Can you think of examples from your own experience?
7
Mind-Set
Traditional Mind-set Modern Mind-set
What does the system do? What are the fundamental business concepts in the domain?
How do I design a system to provide these functions?
How can I model the problem and distribute responsibilities to achieve the system's functionality?
Focus on version 1 of this system
Focus on extensibility and families of systems
8
Use Case Driven
9
Good Software Engineering is NOT Use Case Driven
10
History OOPSLA 1993 - Which Method is Best?
11
Unified ProcessUnified Process
Architect-Centric Use-Case Driven Component Based
12
Good Software Engineering is...
Domain Analysis Based Architecture-Centric Use-Case Configured Component Biased Quality Engineered
13
Domain Analysis Based First major activity in
software development is the identification of the fundamental business concepts and relationships
Design of the application server code is based on the classes and relationships in the domain model
14
Architecture-Centric Architecture definition and refinement is viewed as a
core development activity an appropriate percentage of the project schedule is
devoted to architecture Architecture is not ad hoc, but is based on industry
standards, patterns, commercial frameworks and components
All detail design and coding is done within a well defined architectural framework, often according to a specific pattern
Architecture team plays a key role throughout the
entire product lifecycle
15
From Domain Analysis to Architecture
The architecture for each separate domain describes the way the classes within the domain interact and is based on domain relationships
The architecture for the application describes the way the different domains interact
Grading Domain Model
Application Model
(Major Domain)
RegistrationSpreadsheet
DomainDomain
GradingReportingDomain
16
Use-Case Configured
Architecture
Application
Use Cases
Domain Relationships
Business Goals &Technical SystemRequirements
CommercialStandards &Frameworks
17
Uses cases STOP at the system interface boundary
18
Do not directly derive your design from your use cases
Use cases DO describe sequences of actions that actors follow in using the system
Use cases must NEVER specify what steps the system takes internally in responding to the stimulus from an actor
SystemInterface
19
Example Architectural Drivers
Finance Extensibility
Telecommunications 24X7 hot switchover
Aerospace COTS and GOTS contract mandate
20
Watch out for ShortcutsWatch out for Shortcuts RAD tools that tie screens directly to databases give you RAD
development, but not RAD modifiability Screens should be tied to the business model.
The business model should not directly embed SQL, or any other implementation technology, in it’s methods
ReportGUI
Business Model
Relational Database
Technology Interface
Writer
What are the trade-offs?
21
Component Biased The development process is biased towards using:
Robust libraries of domain-specific and domain-independent components
Frameworks that supply substantial portions of an application
Packaging techniques that requires loose coupling and well specified interfaces between modules
Supporting management techniques that enable us to integrate these components
22
Quality Engineered Formal QA process Testing across the life-cycle Iterative, incremental development
process Prototype supported process Continuous education for software
engineers Adherence to best current standards and
practice Adaptability over rigidity
23
A Software Development Process Meta-ModelA Software Development Process Meta-Model
1. EmphasisDomain Analysis Based
Architecture-Centric
Reuse-oriented
Use Case Configured
Quality Engineered
2. Activities (Workflows)Domain Analysis
Application Analysis
Application Design
Class Design / Development
Incremental Integration and System Testing
3. Notation UML
4. Scope Comprehensive
5. Process ModelIterative/Incremental Process
Phased Development
inception
elaboration
construction
transition
Prototype-supported
24
Incremental Model Build a system in increments that represent
increasing levels of functionality:
Analyze a little… Design a little… Code a little… Test a little… Learn a lot…
This is different from waterfall until implementation, then incremental development
25
Prototyping ModelPrototyping Model Some advocate a process with little formal analysis and design, evolving the
prototype into the product.
This is good for small, short lived, in-house projects that will forever be supported by the same person(s).
Today’s systems need a well documented solid architecture that is matched to the business needs of the product.
It is a temptation to skip Domain Analysis and Architecture when using a powerful IDE such as JBuilder from Borland
Note: We will use the term prototype to designate a disposable product.
26
Good Software Engineers Create Lots of Disposable Protypes:
Analysis Prototypes Answer questions about requirements
Design Prototypes Answer questions about the architecture. Design
prototyping is facilitated by simulation tools
Implementation prototypes Answer questions about feasibility, performance,
memory requirements, etc.
27
Inception Elaboration Construction Transition
Requirements
Analysis
Design
Implementation
Test
Preliminary iteration(s)
Itr. #1
Itr. #2
Itr. #n
Itr. #n+1
Itr. #n+2
Itr. #m
Itr. #m+1
Core Workflows Phases
Iterations
*Figure 11.2 page 296 “The United Software Development Process, Jacobson, Booch, Rumbaugh
RUP Effort Distribution
28
Vocabulary Phase Workflow Iteration Increment Cycle Build Release
29
An OO Development ProcessAn OO Development Process
Basic process is incremental Iterate within increments, with prototype support as necessary. Often this
will involve reworking one piece of the system several times before an increment is finished. Previous increments are only revisited to fix errors or serious flaws.
How does one incrementally build an architecture?
Do enough analysis and design to form a context, then concentrate on driving an increment through to completion (running, tested code).
30
Building Complex Systems is Fundamentally an Incremental Process
“A complex system that works is invariably found to have evolved from a simpler system that worked ... . A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”
Ramamoorthy, C., and Sheu, IEEE Expert, Vol. 3 (3), p. 14
31
Basic Development Process
light activity
heavy activity
In
Activity Increment
In+1 In+2 In+3
Domain Analysis
Application Assembly
Application Design
Class Development
Application Analysis
Integrated cradle to grave teams work best
32
Getting Started
light activity
heavy activity
I 0a
Activity Increment
I 0b I0c I01
Domain Analysis
Application Assembly
Application Design
Class Development
Application Analysis
Establishing a basic context
33
Stepping through the process Getting Started
DA
AA
Workflow
AD
CD
IT
34
Stepping through the process Increment 1
DA
AA
Workflow
AD
CD
IT
I1
35
Stepping through the process Increment 2
DA
AA
Workflow
AD
CD
IT
I1 I2
When performing the Ith increment, bring the entire analysis and design up to date.
36
Choosing Increments - “Use Case” versus Architectural
A use-case driven (external) increment implements some subset of the user requirements (e.g. traffic controller works for non-rush hour straight traffic. No turn traffic, pedestrians or emergency vehicles are yet considered).
An architecturally based (internal) increment implements some subset of system functionality (e.g. database access mechanism, inter-process communication).
How does one balance scheduling external increments with internal increments?
37
Testing Architectural Increments
Architectural increments imply architectural test cases
The specification of an architecture should include a set of “architectural use cases”
38
Design ReviewsDesign Reviews
Architecture review
Cluster design review
Detail design review
There should be at least three
types.
Why?
39
Incremental Process Implies Incremental Documentation
Other important documents, such as the user manual and test plan, are also developed, and verified incrementally.
RequirementsSpecifications
Analyze Analyze
Design Design
Implement
DomainModel
DesignDocument
Implement
40
Summary Need to plan on throwing away the
“right” amount of code Need to do enough architectural design
before first increment so that you have a roadmap
Plan on building some use case increments before all of the architectural mechanisms are in place
Use components, patterns, and frameworks to realize your architectures