19 | SWPP 2020
20 |
21 |
23 |
30 |
31 |
24 | 
25 |
26 |
25 | 27 | SWPP Babyname Search Engine 28 |
29 |
33 |
41 |
34 |
35 |
36 |
37 |
38 | to Bottom
39 |
40 | | Rank | 45 |Male | 46 |swap_vert | 47 |Female | 48 |swap_vert | 49 |
|---|
72 | scroll up
73 |
74 |
2 |
3 | 
4 |
5 |
MaterializeCSS
8 | 9 |
10 | Materialize, a CSS Framework based on material design.
11 |
12 | -- Browse the docs --
13 |
14 |
15 |
16 | 
17 |
18 |
19 | 
20 |
21 |
22 | 
23 |
24 |
25 | 
26 |
27 |
28 | 
29 |
30 |
31 | 
32 |
33 |
7 |
9 | );
10 | }
11 |
12 | export default App;
13 |
--------------------------------------------------------------------------------
/hw3/src/App.test.js:
--------------------------------------------------------------------------------
1 | import React from 'react';
2 | import ReactDOM from 'react-dom';
3 | import App from './App';
4 |
5 | it('renders without crashing', () => {
6 | const div = document.createElement('div');
7 | ReactDOM.render(SWPP HW3!
8 |4 | Design and Planning Document
5 | ??/??/??,
6 | Version major.minor
7 | 8 | **Instructions**
9 | This is a design and planning document template for SWPP. Please fill out this template carefully. 10 | 11 | This will be a living document. For the first sprint you will fill in the document with the design details as you can see them before the first sprint. In subsequent sprints you will expand this document. 12 | 13 | You have to use Github wiki for this document. 14 | 15 | **Submission**
16 | You must send an email to swpp-staff@spl.snu.ac.kr with a PDF version of your document by the deadline. 17 | 18 | You must send the email by the deadline in the class calendar. This is a HARD deadline. 19 | 20 | **Document Revision History**
21 | Your first version of this document is version 1.0. After that minor changes increment the minor version number (e.g., 1.1, 1.2, …) and major changes increment the major version number and set the minor number to zero (e.g., 2.0, 3.0, …). We will follow this convention with other documents as well. 22 | 23 | Rev. 1.0 YYYY-MM-DD - initial version 24 | 25 | **System Architecture**
26 | Here you should describe the **high-level architecture** of your system: the major pieces and how they fit together. Use graphical notations as much as possible in preference to English sentences. For example, you could describe the architecture using UML, if your system lends itself to these descriptions. Try to use standard architectural elements (e.g., pipe-and-filter, client-server, event-based, model-view-controller). Make sure to describe the major interfaces between components, which you will describe in more detail in the "Design details" section below. 27 | 28 | **Design Details**
29 | In this section go those important facets that are not at the level of “architecture,” such as descriptions of critical algorithms, protocols, and key invariants. Also, wherever possible items should be linked back to your specification. Ideally, you can match up everything in the specification with where it is implemented in the design. 30 | 31 | We expect that once this document is completed you will split into subteams to implement the various major components. To be ready for such a split, you need to have a precise idea of how the components are interacting, and how you are going to start implementing them. A complete class-level design might not be always possible so early, but you need to specify at least the API among the major components. Use UML when appropriate. 32 | 33 | If there are messages sent between clients and servers, you should identify **what messages and what data they contain, and in what format, and in what order they should be sent.** 34 | 35 | We expect to see a more refined design for the features to be included in the current sprint, and perhaps a more rough design for the features to be implemented in future sprints. 36 | 37 | If you have considered alternative designs, please describe briefly your reasons for choosing the final design. 38 | 39 | **Implementation Plan**
40 | Break down each user story described in your requirements document into programming tasks. Determine the difficulty of each task, and try to estimate the number of developer-days that the tasks should take. Try to also determine dependencies among tasks. Then, you should list all of the tasks to be done in the current sprint, a preliminary assignment of tasks to people in the group, estimates of the time for each task, dependencies between tasks, and a preliminary division into sprints (e.g., which features are implemented in the first sprint, second sprint, and so on). The plan should be designed to get some prototype system running as quickly as possible and then growing towards to the full project over a sequence of sprints. Please pay extra attention to the dependency relationships between tasks; you will almost certainly run into the situation where one bit isn't done but everything else is waiting for it. In that case, you want to know exactly where resources need to go, and how urgent each bit is (hint: NOT proportional to its size or importance in the whole system). 41 | 42 | Try to identify the major risks for the project in general and the plan in particular. Explain what the risks are and discuss how you plan to mitigate them. 43 | 44 | **Testing Plan**
45 | In this section goes a brief description of how you plan to test the system. Thought should be given to how mostly automatic testing can be carried out, so as to maximize the limited number of human hours you will have for testing your system. The effort you put early on on automated testing will pay off when you have to ensure that you are not breaking existing functionality in future sprints. 46 | Consider the following kinds of testing: 47 | 48 | - **Unit testing**: explain for what modules you plan to write unit tests, and what framework you plan to use.
49 | - **Functional testing**: What APIs you plan to test? How will you test them? What tools you will use? Will you write mocks?
50 | - **Acceptance & integration testing**: how do you plan to test the user interface and scenarios?
51 | 52 | **Registering Issues**
53 | You have to register Github issues regarding tasks for design, implementation, and testing and mark them with milestones. 54 | 55 | **Design and planning document grading guidelines**
56 | These are the grading guidelines that staff will use to evaluate your document. 57 | 58 | | Max points | Design | 59 | |-------------|--------| 60 | | 8 | Are all parts of the document in agreement with the product requirements? | 61 | | 10 | Is the architecture of the system described, with the major components and their interfaces? | 62 | | 10 | Are all the external interfaces to the system specified in detail? | 63 | | 10 | Are the major internal interfaces (e.g., client-server) specified in detail? | 64 | | 8 | Is there sufficient detail in the design to start Iteration 1? | 65 | | 4 | Is there reasonable detail in the design for features in future iterations? | 66 | | | **Planning** | 67 | | 8 | Is the plan for Iteration 1 sufficiently complete to start the implementation ? | 68 | | 4 | Are the subteams identified and has enough thought been given to parallelization of effort and team dependencies? | 69 | | 4 | Is there a discussion of the risks associated with this plan? | 70 | | 4 | Are the testing activities scheduled at the appropriate times? | 71 | | | **Testing** | 72 | | 5 | Does the design take into account testability of the various units, components, and subsystems ? | 73 | | 4 | Is there a discussion of how unit testing will be done? | 74 | | 6 | Is there a discussion of how functional (API) testing will be done automatically? | 75 | | 4 | Is there a discussion of how acceptance/integration testing will be done? | 76 | | | **Clarity** | 77 | | 4 | Is the solution at a fairly consistent and appropriate level of detail? | 78 | | 4 | Is the solution clear enough to be turned over to an independent group for implementation and still be understood? | 79 | | 5 | Is the document making good use of semi-formal notation (UML, diagrams, etc) | 80 | | 4 | Is the document identifying common architectural or design patterns, where appropriate? | 81 | | 4 | Is the document carefully written, without typos and grammatical errors? | 82 | -------------------------------------------------------------------------------- /project/final-report-examples/team11_final_report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/final-report-examples/team11_final_report.pdf -------------------------------------------------------------------------------- /project/final-report-examples/team2_final_report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/final-report-examples/team2_final_report.pdf -------------------------------------------------------------------------------- /project/poster-examples/Team21_poster.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/poster-examples/Team21_poster.pdf -------------------------------------------------------------------------------- /project/poster-examples/Team3_poster.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/poster-examples/Team3_poster.pdf -------------------------------------------------------------------------------- /project/poster-examples/Team6_poster.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/poster-examples/Team6_poster.pdf -------------------------------------------------------------------------------- /project/poster-examples/Team7_poster.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/poster-examples/Team7_poster.pdf -------------------------------------------------------------------------------- /project/postersession.md: -------------------------------------------------------------------------------- 1 | ## Poster Session 2 | 3 | A check list for the poster. 4 | - Catchy name 5 | - Examples 6 | - LinkedIn: Connect, share ideas, and discover opportunities 7 | - Uber: Moving people 8 | - Facebook: Connect with friends and the world around you on Facebook 9 | - Github: Build software better, together 10 | 11 | - Descriptions (2-4 sentences, max 60 words) 12 | - Use the poster template 13 | - Prepare well for your demo 14 | 15 | -------------------------------------------------------------------------------- /project/project-requirements-and-specification.md: -------------------------------------------------------------------------------- 1 | ## Project Requirements and Specification 2 | 3 | **Project Requirements and Specification**
4 | (Borrowed and Adapted from UCB CS169) 5 | 6 | Your Project Name
7 | Requirements and Specification Document
8 | ??/??/????, version major.minor 9 | 10 | **Instructions**
11 | This is a requirements and specification document template for Software Development Principles and Practices. Please follow these directions for filling out this template. Items in italics are information that you are to fill in, beginning with the project name, date, and version number above. See below for an explanation of version numbers. 12 | 13 | There is no standard for requirements or specifications documents and in fact many organizations blend aspects of requirements, specification, and design in a single document. We will use a simple template for requirements and specification. Inevitably in preparing this document you will discuss design and planning, but limit this document to requirements, a description of how the system should interact with the outside world. 14 | 15 | This will be a living document. For the first sprint you will fill in the overview sections (Abstract, Customer, Competitive Landscape), and a few of the requirements that you plan to implement in the first sprint. In subsequent sprints you will expand the applicable sections. 16 | 17 | You have to use the Github wiki of your private team repo. 18 | 19 | **Submission**
20 | You must send an email to swpp-staff@spl.snu.ac.kr with a PDF version of your document. 21 | You must send the email by the deadline in the class calendar. This is a HARD deadline. 22 | 23 | 24 | **Project Abstract**
25 | A one paragraph summary (about 200 words) of what the software will do. (**Must include in the first version.**) 26 | 27 | **Document Revision History**
28 | Your first version of this document is version 1.0. When you evolve this document for future sprints of your project you will increment the minor version number (e.g., 1.1, 1.2, ...). We do not expect that you will have to increment the major version number in the course of this semester. For every version after the initial version, you should list a short bullet list with the main changes and extensions that you made to the document: 29 | 30 | Rev. 1.0 YYYY-MM-DD - initial version 31 | 32 | **Customer**
33 | A brief description of the customer for this software, both in general (the population who might eventually use such a system) and specifically for this document (the customer(s) who informed this document). (**Must include in the first version**) 34 | 35 | 36 | **Competitive Landscape**
37 | Briefly identify the competitors in this market, and list the main ways in which your project is going to be different. 38 | (**Must include in the first version**) 39 | 40 | **User Stories**
41 | This section will include the specification for your project in the form of user stories. For each user story, you should have at least a Feature and one or more Scenarios, each of which can have one or more Acceptance Tests. Acceptance Tests list one or more acceptance tests with concrete values for the parameters, and concrete assertions that you will make to verify the postconditions. Each user story should also have a field called "Sprint" where you specify in which sprint you implemented or plan to implement this feature. 42 | You should list only the user stories for the previous sprints and those for the current sprint. 43 | 44 | At the end of this section you should maintain a bullet list of user stories that you plan to get to in future sprints, with only minimal detail for each such story. We expect that in future sprints some of these items will be promoted to full fledged user stories. 45 | (**Must include in the first version, and must be expanded for future sprints**) 46 | 47 | **User Interface Requirements**
48 | Describes any customer user interface requirements including graphical user interface requirements. Here you should have sketches or mockups for the main parts of the interface. To save time you may want to use scanned drawings of interface mockups here, instead of Photoshop drawings. 49 | 50 | Just like for the User Stories section, you need to list here only the parts of the user interface that are applicable to the previous sprints and the current one. 51 | (**Must include in the first version, and must be expanded for future sprints**) 52 | 53 | 54 | **Requirements grading guidelines:**
55 | These are the grading guidelines that staff will use to evaluate your document. 56 | 57 | 58 | | Max Points | Content | 59 | |------------|---------| 60 | | 5 | Do the requirements state the customers needs? | 61 | | 5 | Competitive analysis | 62 | | 5 | Do the requirements avoid specifying a design (customer-specified design elements are allowed) ? | 63 | | 5 | Do you believe all parts are possible to implement? | 64 | | 5 | Is the project scope big enough? | 65 | | | **Completeness** | 66 | | 20| Are the user stories written in sufficient detail to allow for design and planning? | 67 | | 5 | Do the user stories have acceptance tests ? | 68 | | 5 | Do the user stories mention error conditions and required behavior ? | 69 | | 5 | Are there sufficient user stories for the first iteration? | 70 | | 5 | Is there a discussion of the stories for future iterations ? | 71 | | 20 | Are the User Interface Requirements given with some detail? Are there some sketches, mockups?| 72 | | | **Clarity** | 73 | | 5 | Is the document carefully written, without typos and grammatical errors? | 74 | | 5 | Is each part of the document in agreement with all other parts? | 75 | | 5 | Are all items clear and not ambiguous? (Minor document readability issues should be handled off-line, not in the review, e.g. spelling, grammar, and organization).| 76 | -------------------------------------------------------------------------------- /project/projectproposal.md: -------------------------------------------------------------------------------- 1 | ## Project proposal guideline 2 | 3 | Write a 2-page project proposal on a web service software system you would like to build this semester. Think ambitiously. Imagine that you create a new start-up. Who knows that you may actually start a new company with the service you build during this course! 4 | 5 | You can propose a new web service that innovates e-commerce, social network service, education, recommendation, multi-player gaming, location-based service, etc. In the proposal, you have to justify why the service is an interesting system to build and what new feature(s) it brings to market. 6 | 7 | In particular, your proposal should include: 8 | - the proposer names (team information) 9 | - a title (it can be changed later) 10 | - your target customers 11 | - what feature the system would add or what problem the system would solve and why the system is important and exciting (at least one of the features must make use of machine learning) 12 | - what the system would do 13 | - how you will test and demo the system 14 | 15 | Send your proposal in pdf or doc to swpp-staff at spl.snu.ac.kr via email. 16 | 17 | Please write your proposal in *English*! 18 | 19 | For your reference: [Proposal Examples](proposal-examples) 20 | -------------------------------------------------------------------------------- /project/proposal-examples/Team1 - BusyWrite.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/proposal-examples/Team1 - BusyWrite.pdf -------------------------------------------------------------------------------- /project/proposal-examples/Team8 - You&Meet - X.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/swsnu/swppfall2020/966043dcf33e7daefd17067de5c779c1889360fa/project/proposal-examples/Team8 - You&Meet - X.pdf -------------------------------------------------------------------------------- /project/sprint-instructions.md: -------------------------------------------------------------------------------- 1 | ## Sprint Instructions 2 | 3 | The main part of the project will be done in several sprints. In each sprint you will have to work on several tasks: 4 | - An update of your specification and design documents (Requirements and Design). In Sprint 1 and Sprint 2 you will have extra time to write the first version of the Design document. 5 | - A completion of a running version of your code with a partial set of features 6 | - Testing support and tests for the implemented features 7 | - A (short) progress report 8 | 9 | 10 | **Revised requirements/spec and design documents**
11 | Update the specification and design documents based on the progress you made so far. 12 | - Update the implementation and testing plans (in the design document) to reflect what you have already accomplished. 13 | - Identify the features you are going to implement in the current sprint. Add user stories (to the requirements document), task breakdowns (design doc), and assignments (design doc). You may need to update tasks that weren't completed in the last sprint. Reassess the task difficulties if necessary. 14 | - Flesh out your list of possible features for future sprints (requirements document). Ideally, you should have a rough outline in place for all sprints. You will change this as we do each sprint, but having a general plan in place will be helpful to everyone involved. 15 | - Identify any changes in the requirements, system architecture and design details. 16 | - Ensure the design document is current for the set of features you've implemented to date and will implement in the next sprint. 17 | - Discuss design decisions that affect testing and describe any test interfaces built into the system (in the testing plan section). 18 | 19 | You must mark clearly the parts of the document that were changed. Use the Changes section at the start of the document and use a different font color for the changed parts. 20 | 21 | 22 | **Sprint Progress Report**
23 | Write a short (1~2 pages) summary for sprint and submit it along with the revised documents. 24 | 25 | - What were the main difficulties so far? You should consider both technical and organization issues. 26 | - Were there any features you did not implement as planned, and why? Are you pushing some features to later sprints, and if so, why? 27 | - What tests did you prepare for this sprint, and what are they covering? Did the tests you wrote deviate from your plan? What features are you not testing yet? Did you use any test frameworks? 28 | - You must include in your progress report a test coverage report. The coverage metric must be over 80%. If it's below 80%, you will lose 10% of the overall score of that sprint. This number may change each sprint. 29 | You must specify what tool did you use, and you must include one or more screenshots showing: 30 | - The overall coverage metric 31 | - The list of classes with lowest coverage. Explain why is the coverage low, and what (if anything) you plan to do about it 32 | - Contribution of team members 33 | - Tag a branch or revision in your repository to identify the code you want to submit for sprintN (replace N with 1, 2, ...). The date and time of this revision should be before the deadline. This branch should include a README file with instructions on how to run the application and tests. 34 | 35 | **Submission**
36 | Each team must send an email to swpp-staff@spl.snu.ac.kr by the deadline. The subject line of the email message must start with the word “[SWPP] sprintN” (replace N with 1, 2, ...) followed by your project's name. The email should contain: 37 | Pointers to the (previously submitted) requirements document and design document. 38 | The sprint summary progress report, as described above. 39 | Instructions for your TA to be able to check out a tagged version of the code that constitutes your sprint release. 40 | A url and instructions for using the app in the current stage. 41 | 42 | Additionally, in the project progress presentation you will have to demonstrate a running version of your sprint release. 43 | --------------------------------------------------------------------------------