1 / 46

WARNING

This module recap covers topics such as stakeholders, requirements, design, implementation, quality assurance, and analysis. It includes 1500+ slides, 20 hours of lectures, tutorials, quizzes, demos, and resources. The lecture materials are not optimized for printing or exam preparation.

josedaniels
Download Presentation

WARNING

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. WARNING • These slides are not optimized for printing or exam preparation. These are for lecture delivery only. • These slides are made for PowerPoint 2010. They may not show up well on other PowerPoint versions. You can download PowerPoint 2010 viewer from here. • These slides contain a lot of animations. For optimal results, watch in slideshow mode.

  2. Module Recap March, 2018

  3. 1500+ slides, 20hours of lectures, 50+ top level LOs, Many tutorials, activities, quizzes, demos, discussions, resources, …

  4. We use OO to ‘align the view’. We use UML as the standard notation. DESIGN IMPLEMENTATION QUALITY ASSURANCE ANALYSIS Stakeholders (Complex)Problem domain RCS = Validation & Verification SystemSpecification • Establish requirements… • brainstorming • Focus groups • User surveys • Product surveys • Observations • Interviews • Prototyping A B D C Unit testing Can be top-down, bottom-up, sandwich, big-bang A C Architecture styles such as n-tier, client-server, peer-to-peer, broker, pipes-and-filters, service-oriented, transaction-processing, and MVC Architecture D Integration Combat complexity… Use abstraction, build models Developer testing • Other V&V techniques: • formal verification • static analyzers • code reviews • … B Can be late-one-time, or early-and-continuous Sequence diagrams A B Integration testing • Specify requirements… • Textual descriptions • Feature list • User stories • Use cases • OO domain models • Object diagrams • State machine diagrams • Activity diagrams • UI prototypes • Glossary • Supplementary requirements • … Top-down design D API (Application Programming interface) Testing After modifications… Regression testing B x y QA z System testing y Framework Class diagrams Bottom-up design System x z Library More agile -> less upfront detailed design Platform operations • Made up as you go → Exploratory testing • Predetermined → Scripted testing • Can be created in these ways: • Black-box, Glass-box, Grey-box User Acceptancetesting Alpha/beta testing Detailed design Detailed design Detailed design Detailed design Test cases Detailed design • Possible Improvements: • Refactor code • Coding standards and good coding practices • Protect code using assertions, exceptions, logging, and defensive coding. • Build automation • Possible Improvements: • Automate testing • Use Test-Driven Development • Increase efficiency and effectiveness of testing (Equivalence partitioning, Boundary Value analysis) • Increase test coverage (function/entry/exit/statement/branch/ condition/path coverage) • isolate SUT using drivers, stubs and dependency injection • Possible Improvements: • ↑Cohesion, ↓Coupling • Apply design patterns (Abstraction Occurrence, Singleton, Command, Observer) • Apply design principles (Open/close, Law of Demeter, Separation of concerns, …) • Use polymorphism (inheritance, interfaces, dynamic binding) • Good product design guidelines (e.g., usability, …) • Possible Improvements: • Apply OO paradigm • Apply analysis patterns • Categorize and prioritize requirements Requirements Specification Project plans Sequential Team structures Unified process CMMI Work-breakdown structures Agile processes PROJECT MANAGEMENT Chief-programmer Iterative Issue trackers Includes buffers and milestones Egoless Scrum XP Breadth-first Depth-first Strict hierarchy

  5. ANALYSIS • Possible Improvements: • Apply OO paradigm • Apply analysis patterns e.g. Abstraction occurrence • Categorize and prioritize requirements Who are typical stakeholders of a software project? Why asking the user is not enough? How do models help to combat complexity? Why use UML? When should we prefer use case descriptions over user stories? Comment on this step that appeared in a use case description: “user clicks the open button” What does an OODM captures? What does an object diagram capture? How to use object diagrams in analysis phase? What are non-functional requirements? What’s the difference between requirements and system specification? Stakeholders (Complex)Problem domain • Establish requirements • Focus groups • User surveys • Interviews • Brainstorming • Product surveys • Observations • Combat complexity… • Use abstraction, build models • Specify requirements… • Textual descriptions • Feature list • User stories • Use cases • Prototyping • OO domain models • Object diagrams • Activity diagrams • State machine diagrams • UI prototypes • Glossary • Supplementary requirements • … Requirements Specification

  6. DESIGN For what purpose do you use sequence diagrams? Complete this sentence: A is coupled to B if …. What is a pattern? What’s the difference between separation of concerns and single responsibility principle? SystemSpecification Architecture styles such as n-tier, client-server, peer-to-peer, broker, pipes-and-filters, service-oriented, transaction-processing, and MVC A C Architecture D B Sequence diagrams :A :B :D API (Application Programming interface) Top-down design Bottom-up design Is Unified process iterative or sequential? What’s the difference between buffers and padding? What’s the benefit of identifying the critical path of a project? • Possible Improvements: • Good product design guidelines (e.g., usability, …) • Use OOP concepts: abstraction, encapsulation, inheritance, polymorphism • ↑Cohesion, ↓Coupling • Apply design principles (SOLID, Law of Demeter, Separation of concerns, …) • Apply design patterns (Singleton, Façade, Command, Observer, …) B :x :y :z y Class diagrams x z operations design Detailed design PROJECT MGT More agile  less upfront design Issue trackers Project plans Sequential Includes buffers and milestones Unified process CMMI Work-breakdown structures Agile processes Iterative Scrum Breadth-first Depth-first XP

  7. IMPLEMENTATION TESTING How is refactoring different from bug fixing? How are assertions different from exceptions? Is Git centralized or distributed RCS? What distinguishes a platform from a framework or a library? Describe CI (Continuous Integration). Acceptance testing is validation or verification? Give one pro and one con of white box text case design. How is integration testing different from unit testing? How does equivalence partitioning help in increasing E&E of testing? Give an advantage of TDD. Which is stronger: statement coverage or path coverage? What is the purpose of dependency injection? QA = Validation + Verification RCS Unit testing A B D C • Other V&V techniques: • formal verification • static analyzers • code reviews • … Can be top-down, bottom-up, sandwich, big-bang Developer testing Integration Can be late-one-time, or early-and-continuous Integration testing Testing After modifications… Regression testing QA System testing design Test cases • Made up as you go → Exploratory testing • Predetermined → Scripted testing • Can be created in these ways: • Black-box, Glass-box, Grey-box User Acceptancetesting Alpha/beta testing Framework System • Possible Improvements: • Automate testing • Use Test-Driven Development • Increase efficiency and effectiveness of testing (Equivalence partitioning, Boundary Value analysis) • Increase test coverage (function/entry/exit/statement/ branch/ condition/path coverage) • isolate SUT using drivers, stubs and dependency injection • Possible Improvements: • Refactor code • Coding standards and good coding practices • Protect code using assertions, exceptions, logging, and defensive coding. • Build automation, Continuous Integration Library Platform

  8. We use OO to ‘align the view’. We use UML as the standard notation. DESIGN IMPLEMENTATION QUALITY ASSURANCE ANALYSIS Stakeholders (Complex)Problem domain RCS = Validation & Verification SystemSpecification • Establish requirements… • brainstorming • Focus groups • User surveys • Product surveys • Observations • Interviews • Prototyping A B D C Unit testing Can be top-down, bottom-up, sandwich, big-bang A C Architecture styles such as n-tier, client-server, peer-to-peer, broker, pipes-and-filters, service-oriented, transaction-processing, and MVC Architecture D Integration Combat complexity… Use abstraction, build models Developer testing • Other V&V techniques: • formal verification • static analyzers • code reviews • … B Can be late-one-time, or early-and-continuous Sequence diagrams A B Integration testing • Specify requirements… • Textual descriptions • Feature list • User stories • Use cases • OO domain models • Object diagrams • State machine diagrams • Activity diagrams • UI prototypes • Glossary • Supplementary requirements • … Top-down design D API (Application Programming interface) Testing After modifications… Regression testing B x y QA z System testing y Framework Class diagrams Bottom-up design System x z Library More agile -> less upfront detailed design Platform operations • Made up as you go → Exploratory testing • Predetermined → Scripted testing • Can be created in these ways: • Black-box, Glass-box, Grey-box User Acceptancetesting Alpha/beta testing Detailed design Detailed design Detailed design Detailed design Test cases Detailed design • Possible Improvements: • Refactor code • Coding standards and good coding practices • Protect code using assertions, exceptions, logging, and defensive coding. • Build automation • Possible Improvements: • Automate testing • Use Test-Driven Development • Increase efficiency and effectiveness of testing (Equivalence partitioning, Boundary Value analysis) • Increase test coverage (function/entry/exit/statement/branch/ condition/path coverage) • isolate SUT using drivers, stubs and dependency injection • Possible Improvements: • ↑Cohesion, ↓Coupling • Apply design patterns (Abstraction Occurrence, Singleton, Command, Observer) • Apply design principles (Open/close, Law of Demeter, Separation of concerns, …) • Use polymorphism (inheritance, interfaces, dynamic binding) • Good product design guidelines (e.g., usability, …) • Possible Improvements: • Apply OO paradigm • Apply analysis patterns • Categorize and prioritize requirements Requirements Specification Project plans Sequential Team structures Unified process CMMI Work-breakdown structures Agile processes PROJECT MANAGEMENT Chief-programmer Iterative Issue trackers Includes buffers and milestones Egoless Scrum XP Breadth-first Depth-first Strict hierarchy

  9. We use OO to ‘align the view’. We use UML as the standard notation. DESIGN IMPLEMENTATION QUALITY ASSURANCE ANALYSIS Stakeholders (Complex)Problem domain RCS = Validation & Verification SystemSpecification • Establish requirements… • brainstorming • Focus groups • User surveys • Product surveys • Observations • Interviews • Prototyping A B D C Unit testing Can be top-down, bottom-up, sandwich, big-bang A C Architecture styles such as n-tier, client-server, peer-to-peer, broker, pipes-and-filters, service-oriented, transaction-processing, and MVC Architecture D Integration Combat complexity… Use abstraction, build models Developer testing • Other V&V techniques: • formal verification • static analyzers • code reviews • … B Can be late-one-time, or early-and-continuous Sequence diagrams A B Integration testing • Specify requirements… • Textual descriptions • Feature list • User stories • Use cases • OO domain models • Object diagrams • State machine diagrams • Activity diagrams • UI prototypes • Glossary • Supplementary requirements • … Top-down design D API (Application Programming interface) Testing After modifications… Regression testing B x y QA z System testing y Framework Class diagrams Bottom-up design System x z Library More agile -> less upfront detailed design Platform operations • Made up as you go → Exploratory testing • Predetermined → Scripted testing • Can be created in these ways: • Black-box, Glass-box, Grey-box User Acceptancetesting Alpha/beta testing Detailed design Detailed design Detailed design Detailed design Test cases Detailed design • Possible Improvements: • Refactor code • Coding standards and good coding practices • Protect code using assertions, exceptions, logging, and defensive coding. • Build automation • Possible Improvements: • Automate testing • Use Test-Driven Development • Increase efficiency and effectiveness of testing (Equivalence partitioning, Boundary Value analysis) • Increase test coverage (function/entry/exit/statement/branch/ condition/path coverage) • isolate SUT using drivers, stubs and dependency injection • Possible Improvements: • ↑Cohesion, ↓Coupling • Apply design patterns (Abstraction Occurrence, Singleton, Command, Observer) • Apply design principles (Open/close, Law of Demeter, Separation of concerns, …) • Use polymorphism (inheritance, interfaces, dynamic binding) • Good product design guidelines (e.g., usability, …) • Possible Improvements: • Apply OO principles • Apply analysis patterns • Categorize and prioritize requirements Requirements Specification Project plans Sequential Team structures Unified process CMMI Work-breakdown structures Agile processes PROJECT MANAGEMENT Chief-programmer Iterative Issue trackers Includes buffers and milestones Egoless Scrum XP Breadth-first Depth-first Strict hierarchy

  10. We use OO to ‘align the view’. We use UML as the standard notation. DESIGN IMPLEMENTATION QUALITY ASSURANCE ANALYSIS Stakeholders (Complex)Problem domain RCS = Validation & Verification SystemSpecification • Establish requirements… • brainstorming • Focus groups • User surveys • Product surveys • Observations • Interviews • Prototyping A B D C Unit testing Can be top-down, bottom-up, sandwich, big-bang A C Architecture styles such as n-tier, client-server, peer-to-peer, broker, pipes-and-filters, service-oriented, transaction-processing, and MVC Architecture D Integration Combat complexity… Use abstraction, build models Developer testing • Other V&V techniques: • formal verification • static analyzers • code reviews • … B Can be late-one-time, or early-and-continuous Sequence diagrams A B Integration testing • Specify requirements… • Textual descriptions • Feature list • User stories • Use cases • OO domain models • Object diagrams • State machine diagrams • Activity diagrams • UI prototypes • Glossary • Supplementary requirements • … Top-down design D API (Application Programming interface) Testing After modifications… Regression testing B x y QA z System testing y Framework Class diagrams Bottom-up design System x z Library More agile -> less upfront detailed design Platform operations • Made up as you go → Exploratory testing • Predetermined → Scripted testing • Can be created in these ways: • Black-box, Glass-box, Grey-box User Acceptancetesting Alpha/beta testing Detailed design Detailed design Detailed design Detailed design Test cases Detailed design • Possible Improvements: • Refactor code • Coding standards and good coding practices • Protect code using assertions, exceptions, logging, and defensive coding. • Build automation • Possible Improvements: • Automate testing • Use Test-Driven Development • Increase efficiency and effectiveness of testing (Equivalence partitioning, Boundary Value analysis) • Increase test coverage (function/entry/exit/statement/branch/ condition/path coverage) • isolate SUT using drivers, stubs and dependency injection • Possible Improvements: • ↑Cohesion, ↓Coupling • Apply design patterns (Abstraction Occurrence, Singleton, Command, Observer) • Apply design principles (Open/close, Law of Demeter, Separation of concerns, …) • Use polymorphism (inheritance, interfaces, dynamic binding) • Good product design guidelines (e.g., usability, …) • Possible Improvements: • Apply OO principles • Apply analysis patterns • Categorize and prioritize requirements Requirements Specification Project plans Sequential Team structures Unified process CMMI Work-breakdown structures Agile processes PROJECT MANAGEMENT Chief-programmer Iterative Issue trackers Includes buffers and milestones Egoless Scrum XP Breadth-first Depth-first Strict hierarchy

  11. Module Recap • Tool vs Toolbox • Aim for higher level learning • Prepare for the future • portfolio + learning muscle > CAP • You have reasons to be confident

  12. Top-down design Revision control Automated testing …

  13. Product-focused project modules iPad module "Facebook" module Multimedia project Game project …. Engineering-focused project modules Software Engineering project I, II Thematic project Top-down design Revision control Automated testing …

  14. Module Recap • Tool vs Toolbox • Principles vs Practice • Prepare for the future • portfolio + learning muscle > CAP • You have reasons to be confident

  15. VS

  16. VS

  17. VS

  18. ~30% VS ~70%

  19. Module Recap • Tool vs Toolbox • Principles vs Practice • Prepare for the future • portfolio + learning muscle > CAP • You have reasons to be confident

  20. Module Recap • Tool vs Toolbox • Principles vs Practice • Low level vs High level • portfolio + learning muscle > CAP • You have reasons to be confident

  21. Expert Does the right thing intuitively. Gets the big picture. Needs the big picture. Appreciates process. • Proficient e.g. can apply patterns effectively Understands conceptual models. Can use them to solve problems. • Competent Dreyfus model of skill acquisition e.g. can apply a pattern • Advanced beginner Can learn technologies/tools quickly, can start coding stuff quickly. Don’t want to get bogged down with fundamentals. Not yet appreciative of the big picture. Novice Needs recipes e.g. can pick up Git from an online tutorial e.g. how to use Git in project Which level are you in now?

  22. Expert • Proficient • Competent • Advanced beginner Novice

  23. Expert • Proficient • Competent • Advanced beginner Novice

  24. Architect • Expert • Proficient Software engineer • Competent Programmer • Advanced beginner Novice

  25. Expert • Expert Proficient • Proficient Competent • Competent Advanced beginner • Advanced beginner CS2103/T Novice Year 1 programming modules

  26. Expert • Expert Does the right thing intuitively. Proficient • Proficient Gets the big picture. Needs the big picture. Appreciates process. Competent • Competent e.g. can apply patterns effectively Understands conceptual models. Can use them to solve problems. Advanced beginner e.g. can apply a pattern • Advanced beginner CS2103/T Novice Novice

  27. Expert • Expert Does the right thing intuitively. Proficient • Proficient Gets the big picture. Needs the big picture. Appreciates process. Competent • Competent e.g. can apply patterns effectively Understands conceptual models. Can use them to solve problems. Advanced beginner e.g. can apply a pattern • Advanced beginner CS2103/T Novice Novice

  28. Expert • Expert Proficient • Proficient Competent • Competent Advanced beginner • Advanced beginner CS2103/T Novice Novice

  29. Module Recap • Tool vs Toolbox • Principles vs Practice • Low level vs High level • portfolio + learning muscle > CAP • You have reasons to be confident

  30. Module Recap • Tool vs Toolbox • Principles vs Practice • Low level vs High level • CAP vs Capability • You have reasons to be confident

  31. VS

  32. Factor X Side Projects

  33. Factor X Have an "obsession"

  34. Module Recap • Tool vs Toolbox • Principles vs Practice • Low level vs High level • CAP vs Capability • You have reasons to be confident

  35. Module Recap • Tool vs Toolbox • Principles vs Practice • Low level vs High level • CAP vs Capability • Confused vs Confident

  36. Interest in SE

  37. Self-learning Confidence Individual feedback, weekly Help Feedback

  38. I have figured out SE

  39. Module Recap • Tool vs Toolbox • Principles vs Practice • Low level vs High level • CAP vs Capability • Confused vs Confident

  40. And this is NOT the end of CS2103  Don’t stop learning.

More Related