FOSS@CSULB Course Preparation

FOSS in Courses 2

Background

This activity is an extension of the FOSS in Courses Planning 1 activity. The goal of this activity is to have
a 1-3 topics and/or learning ideas to bring for discussion to the workshop and receive feedback on.
We do not expect that these activities/ideas will be completely fleshed out, but to provide an initial starting
point to think about.

Here are ways that I can use FOSS activities:

• Lectures: FOSS examples, FOSS as a hands-on experience

• In-class activity: introductory POSSE assignments (see below)

• Homework: solving an introductory issue

• Stream of related activities: set up github, learn bug tracking, install a FOSS project

• Project: solving a set of related issues

*Questions for myself*: How to include the software lifecycle here - or better into CECS 343/543/542.
Take ideas from Heidie's course on that.
For design, what can I come up with? Documentation assignments in 343 to understand.
This was a major take-away for many students in my 343s, because they do little projects in other courses.
For testing?
For quality assurance?
Documentation is easier... there are lots of tasks there.

Revised activities

"Reengineering a Software Requirements Specification"

Description: Reengineering a SRS from a roadmap and issue database and coming up with a set of questions
on what the functionality should be and what is unclear, then ask community.
Learning outcomes: How to write a requirements specification, how to analyze an issue database and
what to critically ask for making sure that a SRS is sufficiently complete.
Pre-requisite knowledge: Content model of a SRS, requirements notation techniques, how to read issue databases
Time required: for instructor prep (1h), for student completion (3h) and elapsed calendar time (2 weeks incl. feedback)
Input required from the HFOSS community: (optional) feedback on specs and list of questions.
Contribution and usefulness: Requirements documentation in case there wasn't any.
Assessment/grading approach: Base on SRS & list of questions, team activity, (optional) co-rating of spec by community (?)
Questions or concerns I have: Does the community do things like that? How do I select a useful format of SRS?
Would 5 specs of the same system be useful??
Stumbling blocks or barriers: None so far.

"Understanding Design activity"

To-Be-Description: Understanding the existing design? Not much to be graded, unless I quiz them on it... 
Or let them first understand it and then reengineer a SDS? Are they not existent in documentation yet?

Learning outcomes: How to analyze and assess design, hot to develop or reengineer a design spec.
Pre-requisite knowledge: Content model of a SDS, design notation techniques, how to read documentation
Time required: for instructor prep (1h), for student completion (3h) and elapsed calendar time (2 weeks incl. feedback)

Input required from the HFOSS community: (Optional) feedback on specs and list of questions.
Contribution and usefulness: Design documentation in case there wasn't any.
Assessment/grading approach: Base on SDS & assessment, team activity (assessment could be individual), co-rating of spec by community (?)
Questions or concerns I have: Does the community do things like that? How do I select a useful format of SDS?
Would 5 specs of the same system be useful??

Stumbling blocks or barriers: None so far.

"Quality Assurance activity"

Description: Give students a checklist of what to look for: Code documentation, version control documentation,
structure and modularization, "clean-ness" of interfaces, etc.

Learning outcomes: How to analyze a an implementation and a code repository.
Pre-requisite knowledge: Code repositories, some coding skills (enough to read & understand code)
Time required: for instructor prep (1h), for student completion (3h) and elapsed calendar time (1 week)

Input required from the HFOSS community: None.
Contribution and usefulness: None.
Assessment/grading approach: Assessment, individual activity
Questions or concerns I have: None.

Stumbling blocks or barriers: None so far.