SENG 209 Software engineering

1. SENG 209 Software engineering Software Development Process Timothy Korson korson@southern.edu

2. 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 User’s Requirements

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 Better, Faster, Cheaper

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 are the fundamental business concepts in the domain? u u What does the system do? u u 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? u Focus on version 1 of this system u Focus on extensibility and families of systems

8. Use Case Driven

9. Good Software Engineering is NOT Use Case Driven Modifiability User Requirements Market Forces Schedule Pragmatics REUSE PERFORMANCE Technical Design Considerations Other Business Drivers Standardization Concerns Each project should be driven by a custom weighted vector of concerns

10. OOPSLA 1993 - Which Method is Best? History

11. Unified 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. Grading Domain Model (Major Domain) Registration Spreadsheet Domain Domain Grading Reporting Application Model Domain 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

16. Use-Case Configured Business Goals &Technical System Requirements Domain Relationships CommercialStandards & Frameworks Architecture Use Cases Application

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 Use Cases architecture Sequence Diagrams document the architecture Interface System

19. Example Architectural Drivers • Finance • Extensibility • Telecommunications • 24X7 hot switchover • Aerospace • COTS and GOTS contract mandate

20. Watch 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 Report GUI Writer Business Model Technology Interface Relational Database 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-Model 1. Emphasis Domain 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 Model Iterative/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 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. RUP Effort Distribution Phases Core Workflows 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 Iterations *Figure 11.2 page 296 “The United Software Development Process, Jacobson, Booch, Rumbaugh

28. Vocabulary • Phase • Workflow • Iteration • Increment • Cycle • Build • Release

29. An 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 Integrated cradle to grave teams work best Activity Increment I I I I n n+1 n+2 n+3 light activity Domain Analysis Application Analysis Application Design Class Development heavy activity Application Assembly

32. Getting Started Establishing a basic context Activity Increment I I I I 0a 0b 0c 01 light activity Domain Analysis Application Analysis Application Design Class Development heavy activity Application Assembly

33. Stepping through the process Getting Started DA AA AD CD Workflow IT

34. Stepping through the process Increment 1 DA I1 AA AD CD Workflow IT

35. Stepping through the process Increment 2 DA I1 I2 AA AD CD Workflow IT 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. Architecture review Cluster design review Detail design review Design Reviews There should be at least three types. Why?

39. Incremental Process Implies Incremental Documentation Analyze Analyze Design Design Implement Implement Requirements Specifications Domain Model Design Document Other important documents, such as the user manual and test plan, are also developed, and verified incrementally.

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