Software Development Process

Size: px

Start display at page:

Download "Software Development Process"

Thomas Watson
8 years ago
Views:

1 Software Development Process 台北科技大學資訊工程系鄭有進教授 2005 copyright Y C Cheng Software development process Software development process addresses requirements, expectations and realities simultaneously There are well-documented processes in the SE area copyright Y C Cheng 2

process addresses requirements, expectations and realities

2 Steps in a process Analysis Design Implementation Testing Spec-test the construction Construct the solution in a particular language Formulate a software solution Understand the problem Define the problem 2005 copyright Y C Cheng 3 Modeling tools in a process Requirement Requirement Analysis Design Implementation Testing Functional testing, black-box te Programming language, styles, idioms, unit testi Architectural patterns, design patterns Domain models, analysis patterns Use cases, scenarios 2005 copyright Y C Cheng 4 2

process Requirement Requirement Analysis Design Implementation Testing Functional testing, black-box te Programming language,

3 Artifacts created in a process Requirement Analysis Design Implementation Testing Spec conformance report, bug Program code and unit tests Architecture diagrams, class diagrams, interaction diagrams Domain models Functional and nonfunctional requirements 2005 copyright Y C Cheng 5 Process and Process weights Agile methods: XP Crystal JAD Scrum RUP OMT Fusion Light weight Few artifacts Hot communication Small team Heavy weight Many artifacts Cold communication Large team 2005 copyright Y C Cheng 6 3

requirements 2005 copyright Y C Cheng 5 Process and Process weights Agile methods: XP Crystal JAD Scrum RUP OMT Fusion Light

4 Proven process elements Use cases (requirement capture) Increments (staging strategy) Iterations (rework scheduling strategy) Patterns Unit tests Continuous integration Review 2005 copyright Y C Cheng 7 A process and its workflow. Write use cases 2. For each use case 3. Find domain model 4. Find design model 5. Implement and do unit tests 6. Integration 7. Test use case 8. Review 2005 copyright Y C Cheng 8 4

Cheng 7 A process and its workflow. Write use cases 2. For each use case 3. Find domain model 4.

5 . Use case modeling Use case: a sequence of steps describing an user-system interaction in which a well-defined service is tendered. Scenario : a set of use cases tied together in order to complete a user s task in the application domain copyright Y C Cheng 9 Use Case Example Use Case UC: Process Sale Main Success Scenario (or Basic Flow).Customer arrives at POS checkout with goods and/or services to purchase. 2.Cashier starts a new sale. 3.Cashier enters item identifier. 4.System records sale line item and presents item description, price, and running total. Price calculated from a set of price rules. Cashier repeats steps 3-4 until indicates done. 5.System presents total with taxes calculated. 6.Cashier tells Customer the total, and asks for payment. 7.Customer pays and System handles payment copyright Y C Cheng 0 5

2005 copyright Y C Cheng 9 Use Case Example Use Case UC: Process Sale Main Success Scenario (or Basic Flow).Customer arrives at POS checkout with goods and/or services to purchase. 2.

6 Use case functions (I) Use case captures functional requirement for a user Use cases are high-level, domainoriented descriptions written in a way understood by project stakeholders 2005 copyright Y C Cheng Use case functions (II) As a starting point in system modeling. All the other artifacts are derived from the use cases. As a guide to testing the system built. The system built must reflect the process presented in a use case. Useful in function/acceptance tests 2005 copyright Y C Cheng 2 6

starting point in system modeling. All the other artifacts are derived from the use cases.

7 Use case tips Write just enough detail to keep the use case interesting Too much detail reverts the development to a structured process You don t need to have all use cases in place to start building system. However, the first use case should not be a trivial use case 2005 copyright Y C Cheng 3 Iteration vs. waterfall (I) Effort/result requirement Analysis Design Implementation Testing time 2005 copyright Y C Cheng 4 7

8 Iteration vs. waterfall (II) Effort/result R A D I T R A D I T R A D I T Iteration Iteration 2 Iteration n 2005 copyright Y C Cheng 5 time Why is the Waterfall so Failure-Prone? A key false assumption underlying many failed software projects The specifications are predictable and stable and can be correctly defined at the start, with low change A typical software project experienced a 25% change in requirements with change rates that go even higher35% to 50% for large projects 2005 copyright Y C Cheng 6 Requirements change Project Size in Function Points 8

9 Increments and iterations (I) A use case is roughly an increment: it is not the whole thing, but it delivers functionality by coherent chunks. Several iterations may be executed on an increment To remove bugs, add functionality, and improve quality 2005 copyright Y C Cheng 7 Increments and iterations (II) Aim for a working system (at least covering the present use case) at the end of an increment. Early feedback to users can improve late development Iterations should be time-boxed: e.g., 2-4 weeks on small projects copyright Y C Cheng 8 9

Several iterations may be executed on an increment To remove bugs, add functionality, and improve quality 2005 copyright Y C Cheng 7

10 Increments and iterations (III) Incremental strategy ensures that transition from domain model to design model is feasible Increment delivers systems in coherent chunks First increment should shape the baseline architecture Later increments built on top on early increments 2005 copyright Y C Cheng 9 2. Domain Modeling Extract the static conceptual domain structure. Use whatever you feel most comfortable (CRC, semantic nets, conceptual diagram, header files, etc.). concentrate on the concepts 2. find out how concepts are related The concepts should have a consistent medium-to-coarse granularity level Fine grained concepts bug you down (too much detail) 2005 copyright Y C Cheng 20 0

Domain Modeling Extract the static conceptual domain structure. Use whatever you feel most comfortable (CRC, semantic nets, conceptual diagram, header files, etc.).

11 Domain Model Example concept or domain object Sales LineItem quantity..* 0.. Records-sale-of Item * association Contained-in Stocked-in Sale Store attributes POS partial domain model drawn with UML class diagram date time Paid-by amount Payment 0.. Captured-on address name Register Houses..* 2005 copyright Y C Cheng 2 3. Design modeling (I) Models the domain as a set of software classes. Therefore, a design model is also a valid domain model, but it may be not easy to obtain off-hand. Coarse-grained concepts are usually realized be a set of cooperating classes Each coarse-grained concept becomes a microcontroller delegating work to its internal classes Knowledge of design patterns and architecture styles are extremely helpful 2005 copyright Y C Cheng 22

. Captured-on address name Register Houses..* 2005 copyright Y C Cheng 2 3. Design modeling (I) Models the domain as a set of software classes.

12 Design modeling (II) Created by finding what a class must do to realize the function being required on the conceptual entities. Responsibilities that are implied in the conceptual model must be made explicit in the design model Discover the responsibilities in the order of their occurrence 2005 copyright Y C Cheng 23 Design Modeling Example POS UML design class diagram catalog... ProductCatalog getproductdesc(...) descriptions {Map}..* ProductDescription description : Text price : Money itemid: ItemID... description Sale... Register enteritem(...)... currentsale iscomplete : Boolean time : DateTime makelineitem(...)... lineitems {ordered}..* SalesLineItem quantity : Integer copyright Y C Cheng 24 2

Y C Cheng 23 Design Modeling Example POS UML design class diagram catalog... ProductCatalog getproductdesc(...) descriptions {Map}.

13 Design Modeling Example POS UML design sequence diagram by Creator and Controller makenewsale :Register Register creates a Sale by Creator by Creator, Sale creates an empty collection (such as a List) which will eventually hold SalesLineItem instances create :Sale create lineitems : List<SalesLineItem> this execution specification is implied to be within the constructor of the Sale instance 2005 copyright Y C Cheng Implementation and unit tests Can happens after the creation of design model design models are drawn and recorded Can happen in parallel with design model creation Write tests for every member function of a class (more detail on unit tests later) Tests should be accumulative and automatic 2005 copyright Y C Cheng 26 3

constructor of the Sale instance 2005 copyright Y C Cheng 25 4.

14 Implementation Example public class Sale { private List<SalesLineItem> lineitems = new ArrayList()<SalesLineItem> private Date date = new Date(); private boolean iscomplete = false; private Payment payment; public Money getbalance() { return payment.getamount().minus( gettotal() ); } public void becomecomplete() { iscomplete = true; } public boolean iscomplete() { return iscomplete; } 2005 copyright Y C Cheng 27 Unit Test Example Manual testing class Foo { }; void main() { Foo f(); f.setxxx(); f.doxxx(); cout << f.getxxx(); } Automatic Testing class Foo { }; void TestFooXXX() { Foo f(); f.setxxx(); f.doxxx(); AssertEqual(f.GetXXX(), ); } 2005 copyright Y C Cheng 28 4

minus( gettotal() ); } public void becomecomplete() { iscomplete = true; } public boolean iscomplete() { return iscomplete; } 2005 copyright Y C Cheng 27 Unit Test

15 5/6. Continuous integration and functional tests Function tests are written for each use case An increment is completed only if the functional tests pass Functional tests can be written by extending unit tests 2005 copyright Y C Cheng 29 Coverage by courses Soft engr, OOAD(S), PSP, PM, Web SE Soft Arch(F) Software testing(f) POSD(F) Analysis requirement Design Implementation Testing 2005 copyright Y C Cheng 30 5

unit tests 2005 copyright Y C Cheng 29 Coverage by courses Soft engr, OOAD(S), PSP, PM, Web SE Soft

16 Further reading Testing S. McConnel, Code complete, Chapter 25 Microsoft press E. Gamma and K. Beck, JUnit cookbook. Reactoring M. Fowler, Refactoring, Addison-Wesley Patterns E. Gamma et al., Design Patterns, Addison-Wesley F. Buschmann et al., Pattern-Oriented Software Architecture, John Wiley copyright Y C Cheng 3 Further reading M. Grand, Design Patterns in Java, 2 volumes, John Wiley, 998. Development process C. Larman, Applying UML and Patterns, Prentice Hall, 998. A. Cockburn, Agile Software Development, Addison-Wesley, 2002 Process management A. Cockburn, Surviving Object-Oriented Projects, Addison-Wesley, copyright Y C Cheng 32 6

, Pattern-Oriented Software Architecture, John Wiley. 996. 2005 copyright Y C Cheng 3 Further reading M. Grand, Design Patterns in Java, 2 volumes, John Wiley, 998.

17 Further reading C++/STL S. Lippman, C++ Primer 3 rd ed., Addison- Wesley, 998 U. Breymann, Designing Components with the C++ STL, Addison Wesley, 998. S. Meyers, Effective C++, 2 nd Ed. Addison-Wesley, 998. S. Meyers, More Effective C++, Addison- Wesley, copyright Y C Cheng 33 7

Principles of Software Construction: Objects, Design, and Concurrency. Domain Modeling and Specifying System Behavior. toad

Principles of Software Construction: Objects, Design, and Concurrency Domain Modeling and Specifying System Behavior toad Fall 2014 Jonathan Aldrich Charlie Garrod School of Computer Science Administrivia: