Project Implementation
Interim: 50 Points
Final: 100 Points

Objectives:

• Be able to build a non-trivial MATLAB program to solve a real-world problem.
• Be able to create a user-friendly graphical user interface.
• Be able to work with large data sets.

Due Date/Time:

The interim project implementation is due at the beginning of class on Lesson 37.

• M3-M4: Wednesday, 30 April

• T3-T4: Thursday, 1 May

This project implementation is due at the beginning of class on Lesson 40.

• M3-M4: Thursday, 8 April

• T3-T4: Friday, 9 April

A late penalty accrues at a rate of 25% for each 24-hour period (including weekends) past the on-time turn-in date and time.  The late penalty is a cap on the maximum grade that may be awarded for the late work.  Thus zero points will be awarded for a submission 72 hours or more late.

Help Policy:

AUTHORIZED RESOURCES: 

      Any, except another cadet’s program.

NOTES: 

• Never copy another person’s work and submit it as your own.

• Do not jointly create a program.

• You must document all help received from sources other than your instructor.

• DFCS will recommend a grade of F for any cadet who egregiously violates this Help Policy or contributes to a violation by others.

Requirements For Documentation:

• You must document all help received from any source other than your instructor.

• The documentation statement must explicitly describe WHAT assistance was provided, WHERE on the homework the assistance was provided, and WHO provided the assistance.

• If no help was received on this assignment, the documentation statement must state “NONE.”

• If you checked answers with anyone, you must document with whom on which problems.  You must document whether or not you made any changes, and if you did make changes you must document the problems you changed and the reasons why.

• Vague documentation statements must be corrected before the assignment will be graded, and will result in a 5% deduction on the assignment.

Project Implementation

• Your project implementation should produce a MATLAB program that contains the functionality you listed in your specification document for your "first release".
   

• You should implement your specification's highest priority functionality first and then proceed to the lower priority functionality. The amount of functionality each cadet implements will vary based on the complexity of the functionality they choose to include in their "first release". Your grade will be based partially on:

  • the amount of functionality you implement,

  • the correctness of this functionality, and

  • the efficiency of this functionality.
    
    Your grade will be higher if the functionality you implement works correctly on a variety of test cases.
    Your grade will be lower if you implement lots of functionality, but what you implement is "buggy" and/or poorly written.
     

• Your program implementation must be readable code. Specifically,

  • You must use descriptive and consistently-formatted names for your functions, variables, and constants.

  • Any constant values that are used repeatedly in your code, or values that need explanation, must be assigned names. For example, if you have a value that is the maximum number of plot lines in a graph, give it a name like Maxiumum_plot_lines,
     

  • Use global variables for values that are used in more than one function and that are not stored in the GUI components.

  • Use local variables for values that are needed only for one specific function (and whose value is not needed for later use).
     

  • In general, no function should be longer than 50 lines of code and each function should perform a single, specific task.

  • Use the smart-indent feature to properly align your code.

  • Group statements that are performing similar tasks by leaving a single blank line between such statement groups.
     

  • Your code should contain no statements that are wider than your printed page when printed with a 10pt font.  Use the light red line as your guide for when to start a new line.  Remember that strings can generally be split with multiple fprintf or sprintf (with concatenation) statements
     

• Your code must be well commented with a main program header block, function comment headers, and appropriate comments within the code. Specifically,

  • Every function must have a "comment separator line" above its function definition. For example:

    %==========================================================================
    function Pause_button_Callback(hObject, eventdata, handles)
    

  • For all callback functions, delete the comments inserted by MATLAB's guide tool and replace them with an appropriate function comment header. For example:

    Delete these comments:

    function Pause_button_Callback(hObject, eventdata, handles)
    % hObject    handle to Save_menu (see GCBO)
    % eventdata  reserved - to be defined in a future version of MATLAB
    % handles    structure with handles and user data (see GUIDATA)

    Add comments like this:

    %==========================================================================
    function Pause_button_Callback(hObject, eventdata, handles)
    %--------------------------------------------------------------------------
    % DESCRIPTION: Pause the playback of the sound file if it is playing.
    %
    %    MODIFIES: The playback status of the audio player.
    %
    %--------------------------------------------------------------------------

    If a function is not a callback function, the header comments should describe its input arguments and output arguments. For example:

    %==========================================================================
    function Indexes = Time_to_indexes(Time_range)
    %--------------------------------------------------------------------------
    % DESCRIPTION: Converts a vector of 2 time values into corresponding index
    %              values.
    %
    % INPUTS:  Time_range - A 2-vector of time values.
    %
    % OUTPUTS: Indexes    - A 2-vector of corresponding index values.
    %
    %--------------------------------------------------------------------------

• If the guide tool created callback functions that you are no longer using, delete them from your *.m code file.
   

• Your code must be reasonably efficient. If you struggling with an efficient way to perform a specific task, consult with your instructor.

Helpful Hints

• Use incremental development -- i.e., implement a small section of code and test that code before starting on the next code section.

• Start simple and then add complexity! 

• If you need to make a large deviation from your original submitted design, consult with your instructor.
   

• It will make your code more readable if you create a single global structure array to store all your global values. (I like to call this variable G.) Then include the command
  
      global G

  in any function that needs access to your global variables.
   

• If you add, remove, and/or modify components from your GUI design using the guide tool, your *.m file that is created by the guide tool can become corrupted. Ask your instructor for help if this happens. In the worst case you might have to do the following:

  • Make a copy of your *.m file.

  • Delete your *.m file (only after making a copy of it).

  • Save your *.fig file, which creates a new "clean" *.m file.

  • Copy appropriate code from your backup *.m file into the newly generated *.m file.
     

• Always test your code with small test cases before using large test cases.

• After you have made substantial progress on your implementation, save a back-up copy of your code somewhere other than on your laptop.  Make a back-up copy of your code before you submit it.
   

• If you are working as a team:

  • Make sure you do not copy your partner's work over you own work -- thus losing your work.

  • Your *.fig and *.m files must be in sync! If one partner modifies the *.fig file and the other partner modifies the *.m file they can easily become incompatible. One partner should keep a "master copy" of the software and any changes made by the other partner should be copied/pasted into the master copy.

Project Help

• If you are implementing the digital photo editor, refer to this help.

• If you are implementing the sound editor, refer to this help.

• Interested in using graphics/icons as push buttons, look to this example.

• Interested in adding a background image for your GUI, look at this example.

• If you are implementing any other project, you will need to get individual help from your instructor.

Project Report

Create a professional report that contains the following information. Title and format the report so that the information can be extracted easily by your instructor.

1. A title for your project.

2. The name of all software developers for your project.

3. Your customer's name.

4. The name(s) of your program's m-file(s) and fig-file(s).

5. A description of the input data your program can read and manipulate.

6. A list of the capabilities of your program that were fully implemented (the functionality works in all cases). Briefly describe each capability.

7. A list of the capabilities of your program that were partially implemented (the functionality works in some cases). Briefly describe each capability and why it was only partially implemented.

8. A list of the capabilities that were proposed in your design specification for the initial release but not implemented. Briefly explain why each capability was not implemented.

9. If you implemented functionality that was not listed in your proposed design specification for the initial release , list and briefly explain each capability and why it was added.

10. Copy and paste your specification chart from the design phase and add an additional column for the actual time you spent implementing each functionality.

11. Briefly explain the stability of your software system. (Does it crash under certain circumstances? Does it crash for no known reasons?)

12. What aspect of this project did you find the most challenging?

13. If you worked as a team, explain what portions of the project each person implemented.

14. Provide any additional information you would like your instructor to know about your program, its implementation, or this project.

Turn-in Requirements

You must submit electronic copies of your documents (one copy per team) to the course web site by the beginning of class on Lessons 37 and 40. This should include:

• Your program's *.fig file(s).

• Your program's *.m file(s).

• One or more example data files that your program processes.

• Your word processing "project report".

You must hand-in a printout of the following (one copy per team) to your instructor by the beginning on Lesson 40.

• Your word processing  "project report".

IMPORTANT: Make sure that your main MATLAB .m file includes a documentation statement under the References section of the file comment-header-block. If you are a team, and each team member received different help, make sure you identify who received the help.

Grading Information:

Proper Documentation Statement (-7 pts)?                               

Interim release follows the same grading criteria (with half the point values