List view
The release candidate 1 (RC1) will be out by March 31. This release has implemented all the features requested by the client and has no bugs. At least, no bugs that have been detected by your careful unit and behavior testing. Basically, you believe that this release is the final one: no more coding is required. You might, or might not, be proven correct by your customers. This release will also implement a bonus feature. This is a feature that your client did not specifically ask for but that you feel they will want or need. Because you know a lot more about software than your client, and now you know a lot about their domain, you should be able to detect one thing, one feature, that should not be too hard for you to implement but which will make the program 10 times more awesome. If you can't think of anything, just implement a feature that you think would be awesome to have. Client Review You will again give this release to your client. You will ask the client to email me directly their review of the app, by the last day of classes (cc: on the email you send them). As them to send me an email (they do not have to cc: you if they do not want to) telling me whether or not they are happy with the resulting app, what features they wish they had, and any problems or suggestions for future improvements. Quality Assurance You will also give it to the other team, for Milestone 15. You will need to coordinate with them so they can run your app and add issues to your github repo.
Overdue by 11 year(s)•Due by March 31, 2015This milestone should be finished two weeks after you get a copy of the other team's project. Each team will get a copy of another team's project and do extensive testing of it. You will be added to the other team's github project. Add all the bugs you find on the project as github issues (tagged: bug). A-teams will find at least a dozen bugs. The specific steps you need to do: 1. Add someone from the other group to your github account, so they can post bugs to your Issues list. 2. Make sure they can run your app, that they know what it is supposed to do, that they know how to use it. If your app is a desktop/phone/tablet make sure they can install it, if it is webapp then deploy it and give the URL to the other team. When testing the other group's project you need to: 1. Add every bug you find to their Issues list. Use screenshots whenever useful (google: how to take screenshot on iphone/android/whatever) 2. If it is not excatly a bug, but something that really should be added, you can add an issue about it with the feature label. 3. When you are done testing, tell the other group.
No due dateThe 1.0, or final release of your code is due on the last day of classes, April 28 @ midnight. It will have all the features implemented and have fixed all the bugs in your issues list.
Overdue by 10 year(s)•Due by April 28, 2015Initial due date: February 3 Final due date: April 28. For this milestone you will implement unit tests, using a third-party unit-testing framework, as well as some form of behavioral tests. You will also devise a method for automating some of this testing and making it part of your workflow. Background Yes. You do not need testing. It is a waste of time. If your goal is to write a program that is just good enough for me to approve it and which will be deleted the moment you get your grade then, yes, testing is just a waste of your time. Imagine, however, that this program you write is actually used by people: 1, 10, 100, 1000, then 10,000 by the end of the year. These are your paying customers. Your salary depends on their happiness with your app. When they ask for a new feature, or a bugfix, you want to make sure that the new code you just added does not break something else: erase their data, reveal their private information to others, crash your website, etc. You do not want to get 100 emails every day about some bug you have no idea how to fix. This is where testing comes in. The goal of testing is to make sure, super sure, that your code works the way it is supposed to before you hand it over to your customers. Unit Testing In unit testing you write tests which verify that your methods/functions do what you think they should do. If a function is meant to sort an array of integers, then you write a unit test that calls that functions with a few example arrays and then check the result to make sure they are sorted. You are a programmer, so you know that it is most likely that errors will appear in boundary conditions: when the array is empty, when it has 1 element, when all the elements are the same, when they are in inverse order, etc. So, your examples are informed, not just random. Unit testing has been around for decades and there are now many Unit testing frameworks for every programming language imaginable. The most popular of these tie in with your IDE to give you pretty output. For example, in eclipse you can run junit tests and get a special window with red marks for the tests that failed and green marks for those that passed. You will use a unit testing framework in your code. The unit tests are also part of your repo. Make sure to push them to github. You will also set it up so that running these tests is a simple matter of just a click, or one command. Everyone should run all tests, and make sure they pass, before they push their changes to github. Behavioral Testing In behavioral testing you make sure your app does what the user expects it to do, that is, what your Specifications say. This is functionality at a much higher level than the unit-testing functionality, so you are testing many parts of your code. Some of this testing is done by just having people use the app. Unfortunately, that does not scale well. You want to be able to perform some of these tests quickly and automatically for every major code change. Luckily there are tools that help us automate this type of testing. For example, if you are building a webapp then you will want to use Selenium which lets you automate web browsing, that is, write a program that emulates a user using a web browser to access your site, do some stuff, get results, and check that those results are what he should be getting. There are similar tools for mobile apps. Deliverables You are required to build and run Unit tests, these tests should be included in your repo. A-level projects run these tests automatically, as part of their git workflow. A-level projects use automated behavioral testing tool like Selenium.
Overdue by 11 year(s)•Due by February 3, 2015Due on Monday, April 21. You will use github pages (click on "Project Site" and follow the directions, your site's URL will look like http://sccapstone.github.io/demo/, for my 'demo' repo) to create a website for "selling" your app. The site must have: 1. A video showing a demonstration of how easy it is to use your app. Use screenflow (mac, I use it for my Java videos) or camtasia (windows). Upload the video to youtube (or similar) for easy viewing. 2. The audience for the video is your prospective users (not me, not your classmates). So, talk in a way they understand. Use their language. Explain how to use the app, not how it works. 3. Some other text explaining how and why to use the app. Some example users. etc. Use screenshots. Use free stock images of happy people and cute cats, maybe. 4. An about page, listing your names. Linking to your linkedin profile might help your personal marketing. 5. Link to your github repo, even if private. Make your github repo public if you want more exposure. Video Tips - On camtasia or screenflow, make sure you select the audio track and click on the "remove background noise" option and the "normalize audio levels". This will get rid of the annoying buzzzz and make your voice much more easier to understand. If you can, use a good microphone. - Make sure you crop the video so we only see your app. - Do not use music, just talk. - If possible, first set your app to one of the standard resolutions: 480p = 854x480; 720p = 1280x720; 1080p = 1920x1080. Then crop to exactly this window. There are free apps out there that will let you open a window to a specific size. I use windowtidy on the Mac. More screencast software options: - www.screencast-o-matic.com - Best Screen Recording and Capture Apps for the Mac - Best 3 Free Screencasting tools for Windows - Most popular screencasting tools Or, you can always just point your camera at the screen. This works especially well for mobile apps where you need to show how the user interacts with the app (tilting, swiping, yelling, etc). But, I built a webapp If you built a webapp then you do not need to use github pages (but you can, if it makes sense). Instead, your main page should become a splash page which sells your app and shows the video to the user, see for example trello.com, snapchat.com, or, pretty much every website for an app nowadays. Deliverables Email me the URL of your website by midnight April 21. The website should have the video embedded in it.
Overdue by 10 year(s)•Due by April 21, 2015•1/1 issues closedYou will have a beta release of your project by March 3. All, or almost all, of the main features will be implemented by this date. It should be usable: no show-stopper bugs, no major crashes. You will give this release to your client and ask them for feedback. You will be happy to implement any new critical features they want, and fix all the bugs they find, before the RC 1.
Overdue by 11 year(s)•Due by March 3, 2015•4/4 issues closedThe final demos are scheduled for Tuesday, April 29, 9am, in 300 Main St. Room B201. You don't have to prepare slides, but you can bring a couple if you want. Plan for 10 minutes, you will be cut off at 15. We have to do 14 demos in 3 hours! The points you have to cover: - Introduce your team - Explain the problem your client wanted you to solve - Demo: show the coolest features - Mention the technologies you used in building and deploying your app
Overdue by 10 year(s)•Due by April 29, 2015In some of our weekly meetings I will ask you interview questions. There will be fizzbuzz questions to help you practice answering these under pressure. I will also ask you (individually) deeper questions about the code you have written. These are the typical questions an interviewer might ask about why you did thing the way you did. Note that if I determine that you did not write the code on your commit log then I will have to report the incident to the Academic Integrity office. Both people, the one who did not write the code and the one who wrote it but gave it to the other and let him claim authorship, will be reported and will likely fail the class.
No due dateInitial Due Date: September 8 Final Due Date: End of Project Every week you must write a few sentences about what you (and, I mean you yourself, not other people in the team) did for the project. I expect that some weeks you will do nothing for the project, while other weeks you might do a lot of work. So, it is OK to write 'Nothing' for some weeks. The goals for this Personal Log are: 1. To allow me, the "manager" to keep track of what each one of you is doing. 2. To facilite coordination among your group. Since you can read all members' log files you can quickly check on who is doing/did what. Your personal log will be a single Wiki page on the wiki pages of your group project. Check out this example. All you need is the date, followed by a couple of sentences on what you worked on that week. Be specific. Say 'I looked at jQuery, prototype.js, and YUI.js' rather than 'I looked at javascript libraries.' And, write the most recent entry first, that way you and I don't have to scroll so much. Deliverables The wiki page must be updated every week.
No due date•13/13 issues closed