Overview of 219341: Software Specification and Design

1. Overview of 219341:Software Specification and Design

2. What We Want Need or Idea Software source: Bruegge, Object-oriented Software Engineering

3. Why can't we just write the program?

4. The Problem "Programming is fun, but developing quality software is hard. In between the nice ideas, the requirements or the "vision", and a working software product, there is much more than programming. Analysis and design, defining how to solve the problem, what to program, capturing this design [...], review, implement, and evolve is what lies in the core of this book." [Forward to textbook by Philippe Kruchten]

5. Intrinsic Complexity of Software About the future of software development... "There is no singledevelopment, in either technology or in management technique, that by itself promises even one orderofmagnitude improvement in productivity, in reliability, in simplicity." "No Silver Bullet" by Frederick Brooks. Computer, 1987 See also page 5-6 for Brooks comments about object-oriented approach.

6. Topics Covered in this Course • The Software Development Process and Life Cycle Models • Software Process for Requirements and Design • Iterative & Evolutionary Approach to Software • Emphasis on Analysis, Specification, and Design

7. Specific Topics (1) • Creating a Vision • Discovering and Documenting Requirements • Analysis and Modeling • Analyze Requirements • Domain Modeling • Implementation Modeling • UML as visual modeling tool • Documentation: project, process, and many others

8. Specific Topics (2) • Design a solution • Principles to guide design decisions • Design Patterns • Iteratively implementing and refining requirements • Validation: testing and reviews • Risk as key to avoiding project failure • Technology & Tools • issue tracking • version control • documenting change and rationale

9. Patterns and Standards • We use Patterns to... • apply knowledge learned by others, avoid mistakes • don't rediscover what is already known • "knowledge reuse" • We use Standards to... • apply software process knowledge learned by others • avoid omissions and mistakes • make projects more repeatable and predictable • recipes for "best practices"

10. Where Does This Course Fit In? • Software Specification & Design • Software Verification & Validation • Software Testing • Project Management • Software Processes & Quality Assurance • Economics of Software • OOP • Database, Networking • Algorithms & Data Structures

11. Workflows Core Process Workflows Supporting Workflows

12. Imagine You Have a Software Idea... Scenario: • You are part of a small to medium size software company. • You have an idea for a great software product. What Do You Do? • How do you turn your idea into a project? • What are the steps? How Will Your Idea Become A Software Project and a Software Product?

13. Imagine You Have a Software Idea...

14. Textbooks and Readings Required Textbook: Craig Larman, Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design, 3rd Edition, P-H Strengths: • Excellent for O-O Analysis and Design • Emphasizes iterative development • Author conveys real-world experience Weaknesses: • Fuzzy about documents and how docs fit together. • Bias towards Agile methods; fuzzy about what is a software process. • Some gaps you have to research for yourself.

15. Useful Books and Resources • Martin Fowler, UML Distilled, 3rd Ed. E-book available. • Booch, Jacboson, Rumbaugh, The Unified Modeling Language User Guide, 2nd Ed. (more material, but harder to read) • Blaha & Rumbaugh, Object-Oriented Modeling and Design with UML, 2nd Ed. Detailed, good insights, but very dense reading. • Bruegge & Detoit, Object-Oriented Software Engineering • Lethbridge & Laganiere, Object-Oriented Software Engineering, 2nd Ed. (easy to read, good intro to framework concept) • Other readings will be assigned from the literature.

16. Requirements • Read the assigned material before class each week. • Take notes: summarize important points. • Participate in discussions. • Group project • individual roles • everyone is developer. everyone is "programmer" • Evaluation: exams and quizzes

17. Project • Must have a real client • Must have a concrete, realistic objective • Approved by me

18. Tentative Projects • Program to count stock (inventory) for KU Bookstore. Client: KU Bookstore Requirements: I don't know • LDAP (directory service) web client for CPE. Client: me, Aj. Anan Requirements: user can view and edit his own profile, change password, search for other people • Journal article tracking for KU Engineering Journal. Client: Aj. Pirayut, Jim (as proxy) Requirements: submit articles online, track the progess of article

19. Observations from an SKE student... Object-Oriented Programming This is the most important part if we need to communicate with others in development team, more precisely diagram will ensure everybody agree on same goal, it decrease other problem and risk. The OOP isn't necessary in detailed, but should focus to unite the concept which everyone understand. I think drawing technique and communication skill is important here.  For design and analysis, OOP help real world developer, analysis, and system designer more precisely on their task. Many diagrams may be raised in discussion but finally, we got only few 'solid' diagram which team use to implement, or for next discussion.

20. Observation From SKE Students... From SKE students now working in companies... • The most important factor for software projects is communication. • Imprecise communication leads to many misunderstandings and errors. • Visual modeling is helpful for communication. • UML diagrams must be accurate to be useful. • Lack of documentation makes project more difficult.

21. Software Processes... why? • Imagine you are a seniorsoftware engineerat SiamSoft. • A person from the sales department comes to you with a custom software project they want to bid on...

22. Software Processes... why? Product Description: • A web-based system for buying and selling used electronics, books, cars, CDs, motorcycles, and other items. • Registered sellers can login and post item descriptions with digital photos, and price of the item. Items are placed in categories. • Anyone can browse available items, but must login in order to buy something. • All transactions are cleared through our system, which charges a commission of 4% of the sales price (commission may be changed and may use a sliding scale: lower for high-cost items and frequent sellers). • Buyers and sellers can "rate" each other, log complaints, track orders (very limited), and cancel orders (with restrictions). • The system must remove "sold" items, cancelled, or old items. • This system must be secure.

23. Software Processes... why? The sales person's questions for you are simple: How much will it cost to build this? How long will it take? What personnel (and how many) do you need? • Discussion Question: How would you go about answering these questions? Remember, you're a senior software engineering who has worked on other projects at this company.

24. Software Processes... why? Approaches to answering these questions: • look for similar projects your company has done. Use the project data from those. • do a rough, high-level architecture design.Then estimate the cost/manpower for each component. • apply a cost estimation method such as COCOMO. This may require some preliminary software design. • ask an expert......uh, I forgot. youare the expert.

25. Difficulties • Client's requirements are not fully known • may have non-functional requirements • example: require use of a particular database or hardware platform (that you're staff doesn't know) • can you identify a non-functional constraint in the description • Previous results may not be repeatable • if projects are managed ad hoc • if organization depends on a few skilled or charismatic individuals

26. Your Goals as Software Professionals • Work for Google. • Want to develop useful software that helps the client or user. • Want to write/design good quality software that lasts. • Make a living (profit) by doing this.

27. Realities of Software • Obstacles to writing good software. • Change. • Useful software is complex. • Communication - don't clearly understand what the user(s) want. They don't understand us.

28. Topics • Software process models • Process iteration • Software specification • Software design and implementation • Software validation • Software evolution • Automated process & project support

29. What We Want Need or Idea Software source: Bruegge, Object-oriented Software Engineering

30. Real World Software Lifecycle • a need or an idea • explore and understand what is needed • a vision and business case for the project • decision to implement or drop • initial prototype. • discover more requirements • reimplement in greater detail • software + architecture design • working but buggy software • software initial release for use • iterative fix bugs and add new features

31. What is a Life Cycle Model • A model of the phases that software goes through • Serves as a guide for management of software development • Model is an abstraction. • omits some real-life complexity and detail

32. Inception of idea vision business case Analysis Design Implementation Acceptance Deployment transition training & education Typical Lifecycle Model • Maintenance and Support • End of Support • Retirement • end of useful life • transition or archiving GREEN = part of the process, not life cycle

33. Is Testing Part of the Software Lifecycle? • Many people say it is. • Or,is testing an activity that is part of many steps in the lifecycle?

34. Requirements Analysis Design Implementation Testing Delivery and Installation How it should go: Our plan of attack source: Bruegge, Object-oriented Software Engineering

35. Why this Model Doesn't Work • Requirements aren't complete or accurate. • even the client doesn't know precisely • Analysis and design aren't accurate. • communication issues • model not precise • Difficult to manage change... • technology changes • new requirements emerge • resource limitations • Software consists of many systems

36. Code-and-Fix Client Requirements repeat as needed Code [fail] Test [pass] [fail] Client Acceptance [pass] This is the implicit process for software development without any formal process model. Delivery & Maintenance

37. Requirements Analysis Design Implementation Acceptance Test Linear Development • determine requirements for the product • analysis requirements to create a specification. • use the specification to construct a software design to satisfy it • build it • acceptance test by client, followed by delivery and maintenance Delivery and Maintenance

38. Requirements Analysis Design Implementation Acceptance Test Waterfall Model The waterfall model recognizes that an activity may uncover a problem from a previous phase. A previous phase must be reworked to make necessary modifications. This may in turn uncover a problem from its predecessor (i.e. going uphill again). Delivery and Maintenance

39. Requirements Analysis Design Implementation Acceptance Test Waterfall Loopback in Reality Royce (1970) found that backtracking multiple phases was usually necessary. The most common backtracking is as shown. Delivery and Maintenance

40. Requirements1 Analysis1 Design1 Requirements3 Analysis3 Design3 Evolutionary Development Episode 1 Episode 2 Episode 3 . . . . . . Implementation1 Implementation2 Implementation3 Each episode attempts to build a complete product, but the process recognizes the need to repeat the process (in all or part). See Schach, section 2.1.

41. Iterative and Incremental • A two-dimensional model: workflows of each increment can overlap.

42. Miller’s Law • At any one time, a person can concentrate on at most 7  2chunks (units of information) • To handle larger amounts of information, use stepwise refinement • Concentrate on the aspects that are currently the most important • Postpone aspects that are currently less critical • Every aspect is eventually handled, but in order of current importance • This is an incremental process

43. The Cost of Change The cost of detecting and correcting a fault at each phase Figure 1.5

44. The Cost of Change The previous figure redrawn on a linear scale Figure 1.6

45. Incremental development This slide is from Sommerville, Software Engineering. Do you agree with the activities and flow lines?

46. Incremental development advantages • System functionality is available earlier • Customer sees value added at each increment • Early increments act as a prototype to help elicit requirements for later increments • Discover design changes and problems early • Lower the risk of overall project failure • Highest priority system services tend to receive the most testing

47. Classical Phases versus Workflows • Sequential phases do not exist in the real world • Instead, the five core workflows (activities) are performed over the entire life cycle • Requirements workflow • Analysis workflow • Design workflow • Implementation workflow • Test workflow • Question: why there is a separate test workflow?

48. Workflows • All five core workflows are performed over the entire life cycle • However, at most times one workflow predominates • Examples: • At the beginning of the life cycle • The requirements workflow predominates • At the end of the life cycle • The implementation and test workflows predominate • Planning and documentation activities are performed throughout the life cycle

49. Iteration and Incrementation (contd) • For example increment A • Determine the requirements • After most the requirements have been determined, the first version of the analysis starts • Then design • Some coding is done • Proof-of-concept testing • Planning, testing, documentation start on day one

50. Iteration and Incrementation (cont'd) • Iteration is performed during each increment Schach, Figure 2.5