Semester Project Weeks

CSC385 - Spring 2012

           

Note: "bring" means "bring to scheduled weekly meeting"

           

Choice Week {Wk2: January 30-February 3}

          Choose your semester project and describe it in 1-2 paragraphs.  If you are not yet sure, describe the area of computer science in which you wish to work and indicate no more than 3 possible choices.

          If you find later that this choice is not a good fit, it can be changed (though any changes should come early in the semester).  But it is important to clarify your direction as soon as possible.  Remember the adage – if you aim at nothing, you will be sure to hit it!

           

iNewton Choice Week {Wk3: February 6-10}

          Identify an area of IT/CS research that is relevant to your project.  Bring the name or a reference to the publication venue where academic papers in that area of research are to be found.  Publication venue can be a journal, conference, textbook bibliography, website of an academic research team, or website of a particular author.

           

Here are some examples of the above:

          Journal – ACM Transactions on Human-Computer Interaction

     Conference – International Joint Conference on AI

     Text Bibliography – Richard Szeliski, Computer Vision: Algorithms and Applications

     Research Team – Team Gamma

     Author – Erik Stolterman website & publications

           

          Further links:

     CS/IT Journals rankings:

              http://appsrv.cse.cuhk.edu.hk/~chhoi/jrank.htm

              http://www3.ntu.edu.sg/home/ASSourav/jrank.htm

              With links: http://citeseer.ist.psu.edu/impact.html

     CS/IT Conferences:

              Rankings:

              http://www.cs-conference-ranking.org/conferencerankings/alltopics.html

              http://www.cs.albany.edu/~ashwin/Conf_rank.html

              http://www3.ntu.edu.sg/home/ASSourav/crank.htm

              http://webdocs.cs.ualberta.ca/~zaiane/htmldocs/ConfRanking.html

              Other lists:

              Wikipedia list

              Confy's: http://www.st.ewi.tudelft.nl/~mathijs/conf/

              http://www.allconferences.com/Computers/Computer_Science/

              Yahoo: http://dir.yahoo.com/science/computer_science/conferences/

              http://www.conferencealerts.com/it.htm

              ICIT: http://www.conferencealerts.com/seeconf.mv?q=ca1mm0mh

           

If you have already identified a paper to study, bring a copy of it or reference to it.

           

RAPS, Personas, Timeline & Diagram Week {Wk5: February 20-24}

RAPS = requirements analysis and project specification.

In a nutshell – the RAPS document answers 2 questions:

          What Do?

          How Do?

What – what should the program do?  Describe its proposed functionality.

How – how will this functionality be achieved?  Specify its design.

                                                                    

Personas – hypothetical archetypes of actual clients

Begin by identifying 3-4 classes or communities of clients.

          For each group, create a persona.  Focus on describing that person in real life terms apart from how he/she will be using your software.

                                                                    

More on personas:

A persona is a hypothetical archetype representing a subset of actual users. Personas are defined by their goals and are determined by a process of successive refinement.  They must be specific, precise as they will constitute the cast of characters which will be your design taxonomy.  They must have names and should be described in terms of their overall "life goals", not only their goals vis a vis your software.

          The basic idea of personas is described in chapter 9 of Alan Cooper's The Inmates Are Running the Asylum.  Here is a summary of his 8 rules of personas and here is a good example of personas for a 385 project.

                                                                               

Analysis:

Having chosen a project, researched current work in the field and written a description of the user community, it is time to write the design specifications and set goals for completion of the project's phases.  Here is a quick overview of requirements analysis.

          The kinds of things you want to look at during analysis:

    Needs – what needs will this project be addressing?

    Persons – who will be using the software?

          what are their goals?

          how will the software produced help them achieve their goals?

          how, specifically, does this analysis relate to your personas?

    Organizations – will the software be used within the context of a business or                              organization?

          if so,

                   how does the project fit within the business/organization's goals?

                    what impact does that have on the project's design?

    Requirements – what is required of the software in order to meet needs & help achieve goals?

                                                                              

Specification:

    Notice that this word contains the word specific!!

    Functionality – during the analysis phase described above you were seeking to answer for yourself the question: What do?  Now you must put that answer to paper; i.e., describe what your project should do.

    Logical design – after answering “What do?” you must answer: How do?  How are you going to create a design which meets the needs you have identified and which will provide the functionality you have specified.

    Project components – what will be the operational components of the project in terms of

          data structures

          data flow

          execution flow

          development platform

          deployment platform

                                                                              

Diagram:

    Diagram – show the logical and functional structure of your project; display the

          relationship between the major components.  Here is an example of a

          good diagram.

                                                                              

Timeline:

    Timeline – a week by week list of what you plan to accomplish

                                                                               

Bring

3-5 personas

timeline

 diagram

RAPS

                                                                                    

Testing Protocol Week {Wk6: February 27-March 2}

Keep in mind that F. Brooks divides software development thus:

1/3 - planning

          1/6 - coding

          1/2 - testing

                                                                                    

Protocol - a detailed plan of a scientific or medical experiment, treatment or procedure {Merriam-Webster}

                                                                                    

Testing is not a separate activity which begins after analysis, design and coding have been completed. Within the framework of the triad of design logic and in accordance with the V3 principle, testing is interwoven within the design process and occurs throughout design, development and implementation.  To give coherent structure to the testing process one must develop a testing protocol.

                                                                                                                                   

The genius of a high quality testing protocol is (1) identify accurately the key functions/tasks that should be tested, (2) choose the best testing model for each, (3) abstract away the irrelevant from the relevant, (4) design tests which hone in on the relevant, (5) correctly interpret test results, and (6) fold them back into the design.

                                                                                                                                   

The reason it is called a protocol is because, ultimately, the test designer specifies not only the tests, but the exact parameters of the testing process, the manner in which results are to be collected as well as the interpretation of those results.

                                                                                                                                    

The three models we have studied are:

Tesler-Mott – interact closely with clients in participatory design fashion; employ

guided fantasy.

Tesler-Atkinson– employ a regular design-develop-test cycle with frequent

deliverables (much like agile design and development models).

Verplank – (1) identify performance characteristics, (2) distill into performance

essence, (3) transform essence into distilled performance tasks, (4) provide

measures for distilled tasks, and (5) test distilled tasks.

You may pattern your testing protocol after one of these models or devise one of your own.  Ultimately, though, your protocol should flow from the interaction of the logos, telos and teleios of your design and verify the coherent interaction of these in your finished product.

           

Testing humor.

           

A final word:

"A good programmer is someone who looks both ways before crossing a one-way street." – testingstuff.com

            

iNewton Reports Week {Wk8: March 19-23}

          Using powerpoint, present your iNewton report, as per posted schedule.

           

Prototype Week {Wk9: March 26-30}

          Bring and demonstrate a prototype of your project.  The minimum properties of a prototype are:

     – it is executable

     – basic framework is in place

     – major data structures and functions are present in at least skeletal form

     – some data structures and functions are present in fleshed out form

           

Project Presentations Weeks {Wk13&14: April 24-May 3}

          Using powerpoint, present your project, as per posted schedule.