CEN4020: Software Engineering I

Assignments

Homework

The homework assignments are intended to develop skills that will be needed later on the team project, and also tested in examinations. These assignments all build on one another. So, it is important to keep up, learn from your errors, and not make the same mistakes more than once. The homework problems are not weighted as heavily as other work, in the course grading scheme, but it is important to do your best on them. If you don't you will not have a firm grasp of the basics, and your entire team will suffer for it.

You are required to work out solutions to these homework solutions individually. Attempting to short-cut the process by referring to another person's solution or a solution posted another term will not just be a violation of the honor policy; it will prevent you from learning a skill that you will need in order to succeed later in the course.

Link to Full Description	Short Description
HW1	Use case diagram
HW2	Sections III & IV of Software Requirements Specification (SRS)
HW3	Sections I and II of SRS
HW4	Class diagrams, class descriptions, and class attribute descriptions

Team Project Deliverables

Every student will work as a member of a team on a cumulative project, which will span two semesters. This term you will produce a Software Requirements Specification (SRS) document, a Human-Computer Interface (HCI) design and prototype, and a testing plan. In the following course (CEN4021), you will produce a Software Design Specifics (SDS) document and a prototype implemenentation.

Each team will develop and maintain a project website, which will show the cumulative progress of the team on the project, using the Trac installation on https://sis.cs.fsu.edu/trac/teamname. Work posted there will go through two phases:

Embargo: An interval during which the work is visible to the customer and grader(s), but is not visible to the other students in the course. The work products are posted either (a) directly on the team's Trac site via the "Attach file" option or (b) on the team's private home page at https://sis.cs.fsu.edu/~teamname/private/. In the latter case, there should be a link from the team's Trac site to the private home page. See https://sis.cs.fsu.edu/trac/axolot/ for an example of such a link.
Publication: When the class is notified that the embargo is over, work products are moved to the team's home page at https://sis.cs.fsu.edu/~teamname, where members of other teams may view them.

There are milestones at which you are expected to deliver specific artifacts for grading, shown as D1-D10 on the course Calendar. These milestons and their "deliverables" are of two kinds:

Team deliverables : The entire team turns in one version of the deliverable, by posting it on the teams's private area on our Trac site. Each individual also turns in a completed confidential peer evaluation form, through the Blackboard dropbox. The entire time will receive one grade for the team deliverable. That grade will apply to everyone on the team, unless a team member fails to turn in his or her peer evalution form on time.
Individual project deliverables : Each person turns in her or his own version of the deliverable, by submitting it to the dropbox for the assignment. These deliverables will later be merged into a team deliverable, but will first be graded individually for what each person has done at this milestone.

Please keep in mind that the SRS is cumulative. That is, each deliverable is another increment in a series of refinements and additions that leads to a completed SRS by the end of the term. You are expected to have maintained, and improved as appropriate, the deliverables from the prior week, as part of the growing SRS. Beware of developing inconsistencies between different parts of the SRS. Keeping the entire document consistent as you update it is a challenge, but something you are expected to do. In particular, it is critical to keep the use case diagram and the class diagram up to date and consistent with the detailed use case descriptions, class descriptions, etc.. Those diagrams may not be re-evaluated for grade directly, but they will be referenced for context in the evaluation of the other parts of the SRS, and if there is an inconsistency it will be counted as an error.

Refer to the course Calendar page for deliverable deadlines, and to the templates directory for a list of templates and examples. For examples you may also want to look at the following two sets of team web pages from the Fall 2009 offering of CEN4020:

Note that the following timetable is not intended to tell you when to start work on the deliverables, but only the points at which should should be prepared to have them evaluated. You should keep the long-term goals in mind, plan ahead, and work ahead. By the end of the term you will need to have completed:

The complete SRS
The complete HCI prototype

You have enough information you need to get started on all parts of these, working them in parallel making use of your full team.

D0	The following needs to be done before the start of work on D1. This semester we did it somewhat less formally, in order to fit our first meeting with customer Towainga Katsvairo into his travel schedule, so this part is not graded. Post your personal resume on the Web Post a message with a link to your resume on the class's Blackboard discussion group Conduct virtual team interviews with classmates to form a team When you have formed a team, send your list of team members to Meet with your team members, to decide on an initial team organization, and how to break down the work on D1 (below).
D1	On team private Wiki/Web page: (50 pts) Extract an initial set of user requirements from the project vision document, concentrating on identifying a core set of use cases. Interact with the customers, via the e-mails and/or your teams's Blackboard discussion group, to see what they think of these use cases. For this, you will need to describe the use cases in words they can understand. Produce and turn in an initial use-case diagram for your project, including what you think are the most essential use cases. If you don't have at least one use case per team member you will not be able to do the next step. If you get more than 2 or 3 use cases per team member, you probably will not get around to expanding them all, but this is not such a big problem as having too few, or having ones that are too trivial. (50 pts) Edit the team Trac site, removing the generic Trac information and replacing it by information about your team and your project. Include at least the following elements: Team name, project title, and a paragraph describing the purpose of the project. Team definition and contact information, in a tabular form similar to the team definition template. You may use the Wiki formatting method. Minutes of at least one team meeting, in a tabular form similar to the team meeting minutes template. This can be a file attachment. Home page, similar to the home page instructions and template. The home page should include at least the team name, the project title, a paragraph describing the purpose of the project, and links to the above two items. When you have the website up, send the URL to By assignment D1 drop-box on Blackboard: individual team peer evaluations
D2	On team web page: (20 pts) SRS Section VI - use case diagram, updated (60 pts) SRS Section III and IV - requirements lists (10 pts) Initial task breakdown, using the Wiki ticket mechanism, for this deliverable and the next. This should include assignments of individual use cases and actor descriptions, for example. (10 pts) Updated team minutes By assignment D2 drop-box: team peer evaluations
D3	On team web page: (50 pts) SRS Section V - class diagram (15 pts) SRS Appendix A - DD actor descriptions (25 pts) SRS Appendix A class descriptions. If you have more than two classes per team member in your class diagram, you may prioritize them (highest risk first) and just turn now two descriptions per team member. However, you will need to have descriptions for all of them by the end of the term. (5 pts) Updated task breakdown, using the Wiki ticket mechanism (and every week hereafter) (5 pts) Updated team minutes (and every week hereafter) Updated use case diagram (and every week hereafter), as basis for evaluation of other deliverables By assignment D3 drop-box: team peer evaluations
D4	On team web page: (20 pts) SRS Sections I and II (20 pts) SRS Appendix A attribute Descriptions (10 pts) SRS Appendix B - Raw Use Case Point Analysis - Summary Table (20 pts) Project Plan, with use case assignments to individual team members. See also instructions for project plan. Attempt to distribute the workload evenly among the team members, based on the use case point analysis. Task list on team Wiki should match project plan tasks, though tasks on Wiki may be broken into sub-tasks. (20 pts) SRS Appendix E Screeens and Reports List. See also Appendix E of Example SRS for VRS (5 pts) Updated work breakdown into tasks, using the Wiki ticket mechanism (and every week hereafter), with milestones corresponding to project deliverables D1-D10 (5 pts) Updated team minutes (and every week hereafter) Updates to other artifacts, as basis for evaluation of the above By assignment D4 drop-box: team peer evaluations
D5	This is to be individual work. Assemble all of the following into a .zip file, and upload it to the assignment D5 drop box: (40 pts) Complete SRS Appendix A - DD Use Case Descriptions. Your team will eventually be required to provide a complete description for each use case in your use case diagram. The goal for this milestone is analyze and document in detail as many of your use cases as you can. You should turn in the descriptions of the use cases that your team assigned to you. Your team should have divided up the use cases by this time. If your team has more than two use cases per team member, and you do not have time to complete all of the by this milestone, you may limit the number turned in at this point to two, but if you do that you must elaborate those that are highest risk and thos most central to accomplishing the user's goal. If you have large use cases, you may split them among different people, using inclusions and extensions. The description of each use case must be consistent with the current use case diagram and shall-list posted for your team, so you must include in the files you turn in a link to the versions of the use case diagram and shall list on which your work is based, in case your team continues to update them. (40 pts) Screen and report mock-ups. Your team will eventually be required to produce an HTML prototype of each screen and each report. The minimum goal for this milestone is to construct a first draft of all the screens and reports needed for the use cases assigned to you. You need to include sufficient detail to allow them to be reviewed for completeness of use case coverage, and to allow you to estimate the time it will take you complete the full prototype when you construct your PERT chart (see below). These first drafts may be drawings done with pencil, Word, or any tool you like, but please convert them to .pdf files for submission to the drop-box. At this point you only need to give a rough sketch of the information that will appear on each screen, but if you have time to go further, perhaps to write some HTML code for the page, you do not need to do a drawing first. You may submit a screen print of your HTML page, or links to the actual pages. (20 pts) A PERT chart from each member. The idealized purpose of this deliverable is for you to develop a plan that will enable you and your team manager to track your progress on your assigned prototype between now and the final deadline. The pedagogical purpose is for your to demonstrate that you have mastered the concept of PERT charts. Normally, there would be one chart for the entire team. However, to give everyone a chance to experience creating a PERT chart, you will do individual charts. Normally, this would include all the work on the project, but to keep this simple you are only required to cover your individual plan for work on the HCI prototype portion of you team project between now and the end of the term. You should break down your work into tasks, estimate the amount of time for each task, and order the tasks. This will probably be simpler than the examples in the textbook, because you are only one person and you have rather few tasks. Consider construction of the HTML prototype for each screen and each repot, as a separate task, and also include tasks for coordination and integration with your team members. Don't forget the development of the user interface navigation matrices, and the integration of those into a single one for the entire team. The deadline is the HCI delivery date shown on the course calendar. Please use the chart format shown in the textbook, or if you are using a tool such as MS Project, you may use the format supported by the tool. You will send me your piece, and then provide your piece to your team leader for inclusion into a master PERT chart for the entire project. (This is all individual work, submitted via D5 drop box, so there is no team peer evaluation)
D6	Individual work, by D6 drop box: (50 pts) Scenario analysis tables for assigned use cases. See notes on how to do this in ScenarioAnalysisTable.ppt. The objective is to verify that your set of screens and reports is sufficient to cover each of the use cases. (10 pts) Peer evaluations Although individuals will be turning in work separately, teams are expected to coordinate to establish a consistent format for the screens within each team, and to collaborate as necessary for any screens that are logically shared between use cases. Teams are also expected to come to the recitation meetings prepared to present a joint progress report, including examples of some individual contributions.
D7	Individual work, by D7 drop box: (100 pts) Functional Test Cases for all the use cases assigned to you. These should be presented in the form of a table. The idea is to analyze each use case to determine how to test that the system behaves correctly on that use case, and document it. These tests are not expected to necessarily be all-sufficient, but should be enough to check that the implementation is basically correct. See the following for more information: Example & template Instructions A more detailed example is provided at http://www.math-cs.gordon.edu/courses/cs211/ATMExample/InitialFunctionalTests.html. There is a discussion of how to derive test cases from a use case at http://www.mcbreen.ab.ca/papers/TestsFromUseCases.html REMEMBER: It is critical in this and all other cases that the grader have access to consisten versions of all of the prior deliverables on which this one depends. In this case that means the corresponding use case descriptions, scenario analysis tables, and use case diagram, to which test cases refer. You must either specify URL's where the grade can find these, or if they are not on the team website you may include copies in a zipfile when you turn in your functional test cases through the drop-box for the assignment. There is no peer evaluation collected for D7. However, teams are expected to continue meeting and coordinating, to coordinate and inntegrate the HCI prototype components (D8) and the final SRS (D9 and D10).
D8	Individual work, by D8 drop box: (25 pts) Your choice of either a user interface navigation matrix or a screen navigation diagram for each use case assigned to you. (10 pts) peer evaluations REMEMBER: It is critical in this and all other cases that the grader have access to consisten versions of all of the prior deliverables on which this one depends. In this case that means the corresponding use case descriptions, the screens and reports list, and the use case diagram. You must either specify URL's where the grade can find these, or if they are not on the team website you may include copies in a zipfile when you turn in your functional test cases through the drop-box for the assignment.
D9	Individual work, by assignment D9 drop-box: (10 pts) team peer evaluations Individual work, on team website: (50 pts) Modified scenario analysis table, in HTML, with links to prototype pages and reports of the HCI prototype. This should be posted on your team's Trac website, with a link to it along with the links to the other D9 deliverables. The table entries should be links to the completed HCI pages, so that a person can walk through it to see the pages. Correct any problems you know of with your original table, while you are doing this. Individual work, presented in class: (50 pts) HCI presentation. Follow the link for a detailed explanation of what is expected and how it will be graded. On team web page: (100 pts) Complete integrated HCI prototype By this point, the entire HCI prototype of each team should be completed, integrated, and posted for unrestricted (no password) access on the team's website at sis.cs.fsu.edu. The prototype should cover (at least) all the use cases assigned to indviduals. It should be a working prototype, with at least data entry, display, and navigation, to the extent that each use case involves these items. If you are able to provide additional functionality such as data persistency, you may do so, for a higher score. Please get this up on your public web page a few days before you are scheduled to do the in-class demonstration, so that the customers can pre-view it.
D10	By assignment D10 drop-box: (10 pts) Final team peer evaluations. This last one should summarize your view of your team's operation for the entire term. You are encouraged to go beyond the basic form, adding free-format comments on the team, comments on how the course might be improved, and things that went well enough that you think they should be maintained in future offerings of the course. On team web page: (100 pts) The final completed SRS, including all the work items produced as prior individual deliverables. Please get this up on your public web page a few days before you are scheduled to do the in-class demonstration, so that the customers can pre-view it. (50 pts) Slides for your team's SRS presentation. See more on that below. Please get this up on your public web page a few days before you are scheduled to do the in-class demonstration, so that the customers can pre-view it. In class: (50 pts) Each team will be scheduled for a presentation during the final week of classes. The other class members, the TA's, and the customers (if they are able) will attend and evaluate the talks according to a standard rubric. All team members should participate in the presentation and be prepared to answer questions. By this point, the entire SRS of each team should be completed, integrated, and posted for unrestricted (no password) access on the team's website at sis.cs.fsu.edu.

Delivery of Individual Work

Turn in your individual assignment deliverables using the Blackboard drop box, no later than midnight on the date indicated in the course Calendar.

You can find the link for turning in an assignment by starting at the "Assignments" link on the Blackboard page for this course. Assuming you have created a local copy of the solution file(s) you want to turn in , on your workstation/PC, you can click on the assignment link and load the file using the "browse" button, then click on "submit".

If the deliverable has several parts, you may construct a ".zip" file and upload that, or if they are all in the same format (e.g., all ".doc" or all ".pdf") you may merge them into as single file.

If a template is given for an assignment, you are expected to turn in your work in the same format (e.g., .doc file) as the template is provided. If you do not have a copy of MS Word, you can get a free copy of OpenOffice and use that to edit the file, but remember to safe the file in the original format (not .odf). If you have difficulty obtaining MS Word or OpenOffice, please contact the instructor to work out an alternate solution.

Include your name and the identification of the assignment it is for, inside the the file your turn in. For example:

Name : Joe Smith
Assignment : HW3

Also embed your last name and the assignment number in the filename. For example if it is a ".doc" file, the filename might be "smithhw1.doc". Multiple files can be labeled with suffixes "a",...,"z".

Delivery of Team Work

Turn in your team deliverables by posting them on the team's private website. If we are able to set up a "Trac" server page for each team, you team's web page will be there. If not, we will use a team-private area of Blackboard.

Grading

The description of each major assignment will generally include a scoring rubric. Besides the assignment-specific items specified in the rubric, you may lose points if you commit generic error, such as not including your name as author or turning it late.

Grades for assignments will be posted on Blackgoard in your gradebook. If you do not get a perfect score there will be some comments, and possibly a marked-up copy of the file(s) you turned in. To see this information you will need to click on the grade and select the returned assignment files, which will be identified by a suffix such as "graded". For example, if you submitted "smithhw1.doc", you would look for something like "smithhw1graded.doc".

Deadlines and Late Work

Practice time boxing; turn in your best effort by the deadline. Any time after the deadline (possibly the next class, or a few days later), a solution may be given, either in class or by posting on the web. After that, no further work on that deliverable will be accepted for grading. If you turn in your deliverable between the deadline and the time the class is given a solution, it may be accepted for grading. The person grading the assignment will have discretion over whether to accept it late, and how much to deduct from the score for lateness.

Updates to Assignment Descriptions

If you find anything that looks like it might be an error, or a discrepancy between descriptions of any assignment on different Web pages, or between Web pages and information provided in class, please send e-mail to the instructor to resolve the discrepancy. Do the same if you find an ambiguity. The instructor will generally respond with e-mail to the entire class, after updating the assignment file.

Please refer directly to the on-line descriptions of the assignments, rather than printed copies, so that you have the most up-to-date information in case the assignment is updated after the initial posting.

($Id: index.html,v 1.1 2010/08/29 11:45:03 baker Exp baker $)