Iterative Software Development
Iterative Software Development
-
-from Theory to Practice
from Theory to Practice
Amir
Amir Tomer, Tomer, Boaz
Boaz ShaniShani, , Ely Bonne
Ely Bonne
Implementing the Unified Software
Implementing the Unified Software
Development Process in RAFAEL
unclassified
unclassified
The Waterfall Model
Maintenance Retirement Verification Requirements Verification Specification Verification Design Testing Implementation Testing Integration Verification Req. Change Royce, 1970 Development Maintenance
unclassified
What’s wrong with the Waterfall model?
•• DocumentDocument--based verification until late stagesbased verification until late stages •
• Attempt to stipulate unstable requirements too earlyAttempt to stipulate unstable requirements too early •
• Risk mitigation postponedRisk mitigation postponed •
• Operational problems discovered too lateOperational problems discovered too late •
• Lengthy modification cycles and much reworkLengthy modification cycles and much rework
The The inevitable inevitable result... result...
unclassified
The Unified Software Development Process
aka RUP Business Modeling Requirements Analysis and Design Test Implementation Deployment
Config. & Change Management Project Management Environment
Inception
Inception ElaborationElaboration ConstructionConstruction TransitionTransition Phases Phases preliminary iteration iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m+1
Organization along Time
Or gan iz a ti o n alon g Content Core Workflows Core Workflows ProcessProcess Supporting Supporting
unclassified
Iterative Development Overview
Inception Inception Inception Elaboration Elaboration Elaboration Construction Construction Construction Transition Transition Transition
• System scope & concept • Solution alternatives • SW/HW breakdown • System architecture • Operational skeletal system • Operational system builds
unclassified SDP + STP SDP + STP S/W Development Plan S/W Development Plan S/W Test Plan S/W Test Plan SSS SSS System / Subsystem System / Subsystem Specification Specification
System Level Stages & Products
1 1 System Boundary System Boundary 2 2 System Requirements System Requirements 3 3 System Design System Design 4 4 Software Planning Software Planning CSCI CSCI A A CSCI CSCI B B ... CSCI CSCI N N 9 9 System Integration System Integration System Charter / System Charter / Vision Document Vision Document SSDD SSDD System / Subsystem System / Subsystem Design Description Design Description
Operational system builds
Operational system builds
In cep tio n Ela bora tion Cons truc tion
unclassified
CSCI Level Stages
5
Software Requirements 6
Software Design 7
Coding & Unit Testing 8 CSCI Validation Ela bora tion Cons truc tion SAD/SDD SAD/SDD Software Architecture/ Software Architecture/ Design Description Design Description SRS SRS S/W
S/W Req'rmntsReq'rmnts Spec.Spec.
Source code
Source code
modules
modules
Operational
unclassified
Stage 1: System Boundary
•
•
Purpose
Purpose
– Provide a common understanding about the system • client • developers • other stakeholders
•
•
Activities
Activities
– Scope– Relationship with external systems – Main requirements
•
•
Products
Products
– System charter / Vision document
Level: System Phase: Inception
unclassified
Stage 2: System Requirements
•
•
Purpose
Purpose
– Define system requirements
• at the best level of knowledge
•
•
Activities
Activities
– Requirements elicitation from contract, proposal and other documents
– Requirements classification and prioritization – QFD may be utilized
•
•
Products
Products
– SSS = System/Subsystem Specification
• Use Case modeling recommended
– Requirements base
Level: System Phase: Inception
unclassified
Stage 3: System Design
•
•
Purpose
Purpose
– Provide a stable proposed solution and architecture
•
•
Activities
Activities
– System architectural design – Hardware/software breakdown
• including requirements allocation
– Feasibility tests to select alternatives
•
•
Products
Products
– SSDD = System/Subsystem Design Description – ICD = Interface Control Description
• External / internal interfaces
• Either separate or included in SSDD
Level: System Phase: Inception
unclassified
Stage 4: Software Planning
•
• PurposePurpose
– Generating a general plan for the software development
•
• ActivitiesActivities
– Risk Analysis
– Iteration planning
• Detailed plan for 1st iteration
• General plan for following iterations • Risk allocation to iterations
– Resource allocation
– Testing concept and general planning
•
• ProductsProducts
– SDP = Software Development Plan • Risk table and mitigation plan
• Appendix: 1st iteration detailed plan – STP = Software Test Plan
Level: System Phase: Inception
unclassified
Stage 5: Software Requirements
•
• PurposePurpose
– Provide a clear and detailed definition of the software requirements allocated to the appropriate CSCI
• At the current iteration level
•
• ActivitiesActivities
– Deriving software requirements from system requirements – Building/updating the Use Case model
•
• ProductsProducts
– Use Case model • Using CASE tools
– SRS = Software Requirements Specification • Functional requirements (Use Cases)
• Non-functional requirements – Software requirements base
• Preferably as part of the system requirements base
Level: CSCI Phase: Elab./Cons.
unclassified
Stage 6: Software Analysis & Design
•• PurposePurpose
– Provide an architecture and design, in various aspects, of the current iteration
• based on previous iterations + current requirements
•
• ActivitiesActivities
– Analysis and design modeling • Using UML models
• • ProductsProducts – UML models • Class model • State charts • Sequence diagrams
– SAD = Software Architecture Description – STD = Software Test Description
Level: CSCI Phase: Elab./Cons.
Top level design Detailed design
unclassified
Stage 7: Coding and Unit Testing
•
•
Purpose
Purpose
– Implementation of software modules
•
•
Activities
Activities
– Coding
• Programming, compilation, link
– Individual module testing
• Informal documentation
• Test coverage and completion approved by STL
•
•
Products
Products
– Approved code modules
Level: CSCI Phase: Elab./Cons.
unclassified
Stage 8: CSCI Validation and Approval
•
•
Purpose
Purpose
– Approve the CSCI’s readiness for system integration
•
•
Activities
Activities
– Integrating the modules comprising the CSCI – Performing the tests specified in the STD
•
•
Products
Products
– Approved CSCI version, ready for system integration
– STR = Software Test Report
• Detailed results of STD tests
Level: CSCI Phase: Elab./Cons.
unclassified
Stage 9: System Integration and Testing
•
•
Purpose
Purpose
– Accomplish the iteration with an operational approved version of the system
•
•
Activities
Activities
– Integration
– System testing, according to system test specifications
•
•
Products
Products
– Approved version of the system, ready for delivery
Level: System Phase: Elab./Cons.
unclassified 1 1 System Boundary System Boundary 2 2 System Requirements System Requirements In c e p tio n Elabo rat ion Constr u c ti on 3 3 System Design System Design 4 4 Software Planning Software Planning
System Requirements Review
System Requirements Review
System Design Review
System Design Review
CSCI CSCI A A CSCI CSCI B B ... CSCI CSCI N N
Test Readiness Review
Test Readiness Review
9 9 System Integration System Integration CSCI CSCI A A CSCI CSCI B B ... CSCI CSCI N N 9 9 System Integration System Integration external review external review peer review peer review
Critical Design Review (S/W)
Critical Design Review (S/W)
Test Readiness Review
Test Readiness Review
Iteration Completion Review Iteration Completion Review
unclassified
CSCI Level Review
external review external review peer review
peer review
Iteration Plan Review Iteration Plan Review 5 Software Requirements Elaborat ion Construc ti on
Software Specification Review Software Specification Review Software Design Review Software Design Review 6
Software Design 7
Coding & Unit Testing 8 CSCI Validation selected selected iterations iterations
unclassified
Conclusions
•
• USDPUSDP--based iterative software development has based iterative software development has many advantages over the waterfall model
many advantages over the waterfall model
•
• The process may be adapted and tailored to host The process may be adapted and tailored to host most of MIL
most of MIL--STDSTD--498 terminology498 terminology
– Tailoring requires modified templates
•
• The iterative process complies with RAFAEL The iterative process complies with RAFAEL software development procedures
software development procedures
•
• The tailored process is well accepted by engineers, The tailored process is well accepted by engineers, managers and clients
unclassified
Contacts
Dr. Amir Tomer
Director of Systems & Software Engineering Processes RAFAEL P.O.Box 2250/1P Haifa, 31021 ISRAEL (+972)-4-879-5989 [email protected]
