User:Linda.webster

Linda Webster

Linda Webster, Ph.D., MBA, is a tenured Professor of Computer Science and Information Technology at Westminster College in Fulton, Missouri. Westminster is a traditional residential, undergraduate liberal arts college with enrollment of around 900. Being one of a two-faculty department requires Dr. Webster to teach a wide variety of courses. The CS/IT Department espouses a Problem-Based, Project-Oriented approach to student learning.

Dr. Webster's current areas of teaching include software engineering, systems analysis and design, project management, CS 0 and CS 1 with C++, cybersecurity concepts, information storage and management, and business continuity/information assurance.

Previously, Dr. Webster served as the Associate Dean of Faculty at Westminster College, responsible for campus wide academic advising, transfer student advising, transfer articulation agreements and course equivalencies, new student initiatives, the Tomnitz Family Learning Opportunities Center, academically at-risk students, and general student success. As a faculty member, she continues to coordinate departmental articulation agreements and serve as academic advisor for departmental majors.

Dr. Webster's scholarly interests span computing and IT education, software engineering, student software development projects, and business continuity/information assurance issues, particularly in nonprofit organizations.

Prior to coming to Westminster College, Dr. Webster taught at a several types of postsecondary institutions, including a community college, state university, historical black college, and a liberal arts college. She has worked in business and industry from small entrepreneurial businesses up to large corporations. She brings a unique blend of educational and industry experience to her classrooms.

In her spare time, Dr. Webster enjoys spending time with her family, watching old movies, exploring her family history, and watching men's professional cycling. As a former homeschooling mom (both children are now college graduates), she continues to stay abreast of homeschool curriculum issues.

Ideas for Foss in my Classes

As I think about implementing HFOSS into my classes, the two HFOSS projects that intrigue me is Mouse Trap and Sahana. I see opportunities for my students to be engaged that are more than coding. The course that I am considering these types of projects for is Systems and Software Engineering Studio. Since the focus of this course is on software engineering principles as applied through the systems development life cycle of a project, I am attracted to some of the non-coding activities. Initial ideas I have are in the areas of testing, documentation, communication, and providing real world examples.

In the area of Testing, students can develop a testing plan to work to diagnose bugs, create tickets, check bugs that have been fixed, close tickets, recreate fixed bugs, perform testing on various platforms, write a test, write validation tests, eliminate compiler warnings, and add comments to code.

In the area of Documentation, students can create/edit documentation and coding standards documents, develop documentation standards for coders, create a glossary, and develop user guides.

Contributing to the project community by contributing to the blog posts and answering questions. Making design and edit suggestions/changes to the project web site is something that does not require a high degree of technical knowledge, but can provide great enhancements for improvement.

Adding real world examples for ways in which the project can be used would be helpful to encourage new users and help them understand the potential of the project in question.

The tasks listed above are at varying levels of difficulty, require varying amounts of time, and require varying levels of technical expertise. One idea I have is to categorize these tasks by difficulty and time required. Students would be required to complete lower level tasks and learn about the project before advancing to the higher level tasks. A modification of this would be to assign some value to the tasks with students being assigned to earn a certain number of points for each task.

I look forward to ideas from other participants about incorporating these projects into my class. With the wide variety of projects options available, I look forward to finding a project component that will fulfill the learning objectives of my class. Providing this real world experience for students can give them a view of software development they cannot get out of a textbook.

Part 1: Bug Reports

For this assignment, I followed the link to the GNOME Accessibility Bugs page. Here are the column headings on this a page along with an explanation and range of possible values where appropriate.

ID – Unique identifier of the bug.

Sev – Severity – How severe the bug is or whether it's an enhancement.

Pri – Priority – Engineers prioritize their bugs using this field.

OS – The operating system in which the bug was observed (could be any OS for which the program has been released or tested).

Product – The name of the product or component in which the bug resides (in this case, within the GNOME 3 platforms housed on Bugzilla).

Status – Indicates the current status of the bug. A NEW bug has recently been added to the database and is UNCONFIRMED. Once a user with the “CanConfirm” status confirms the bug, the status is changed to CONFIRMED (or VERIFIED), or it may be changed to RESOLVED. A CONFIRMED bug is in IN_PROGRESS when someone is working on them, or may be changed to RESOLVED. ASSIGNED indicates that the bug has been assigned to someone. An IN_PROGRESS bug has been assigned to the proper person who is working on the bug. If a future bug is reported that is the same bug or related to the same bug, a bug can be REOPENED status. A status of NEEDINFO indicates that the reviewer needs more information from the user or reporter of the bug before proceeding.

Resolution – Indicates what happed to the bug. Any bug still open will not have a resolution set. FIXED is a bug that has been fixed and tested. INVALID indicates that the problem described is not a bug. WONTFIX is a bug which will never be fixed. DUPLICATE is a duplicate of an existing bug, and should also indicate the bug of which it is a duplicate next to the resolution. NOTABUG means that the problem is not a bug but some other problem, such as user error or lack of training. NOTGNOME indicates that the bug is not part of the GNOME project. WORKSFORME indicates that all attempts at reproducing the bug were futile and the programmer is indicating that the code “works for me”; if more information appears at a later date, the bug can be reopened. Other values that show up in the search drop down list include INCOMPLETE, INVALID, GNOME1.x, MOVED, OBSOLETE, NOT XIMIAN.

Summary – short sentence which succinctly describes what the bug is about.

In order to discover the definitions and information above, I used the resources provided in this web site. The initial link provided was to the GNOME Bugzilla Bug List page that contained some of these items as column headings to the current bug list for this project. For the other items, I went to the Home page and explored other pages in this site. On the Reports link is a section of “Explanation of various terms and fields” which I found very helpful, not only for this assignments but also for learning more about bug tracking. I could not find ranges of possible for some of the values. Another source for finding the list of possible values is the Search page, where there are drop down lists of the values in each category that can be used to filter the list of bugs for this project.

By default, only open bugs are displayed. It does not appear that there is any organization to the items in the list, so I would assume it is the order in which they are stored in the database.

The shading on some of the bug reports is an indication of severity. Red is a bug with severity that is at least critical. Gray represents an enhancement. Black indicates a bug whose severity is less than critical.

I selected one of the bugs to view more closely by clicking on the bug number. The bug I selected was Bug 102666: Popup menus should appear beside object, not under mouse. Here are my answers to the questions related to my selected bug. 1. Identify when the bug was submitted. January 6, 2003 2. Identify if there has been recent discussion about the bug? Nothing since 2005 in the discussion thread. However, it was recently Modified on July 30, 2015. 3. Is the bug current? It is listed as NEW. 4. Is the bug assigned? To whom? I do not find any indication that this is assigned to anyone. 5. Describe what you would need to do to fix the bug. The first step I would do is to try to confirm the bug, then assign it to a programmer.

The second bug I selected to explore was Bug 349190: Don't hard-code colors. 1. Identify when the bug was submitted. July 29, 2006. 2. Identify if there has been recent discussion about the bug? A couple of postings in 2006, a couple in 2012, and one posting in 2014. 3. Is the bug current? It is listed as NEED, which indicates that more information is needed. 4. Is the bug assigned? To whom? I do not find any indication that this is assigned to anyone. 5. Describe what you would need to do to fix the bug. The first step I would do is to try to get more information from the person who reported the bug, then determine if it needs to be moved to NEW or RESOLVED.

Part 2: Collective Reports

For the second part of the assignment, I went to the Reports link and selected “Summary of Bug Activity for the last week”. Here are the answers to the questions posed:

1. Click on the “Reports” link on the top of the page.

2. Click on the "Summary of Bug Activity for the last week".

3. How many bug reports were opened in the last week? 314 How many were closed? 282

4. What was the general trend last week? Were more bugs opened than closed or vice versa? By observing the summary, in the last 7 days, there were more bugs opened than closed. In fact, several of the products had 0 bugs closed.

5. Who were the top three bug closers? Matthias Clasen (47), Carlos Soriano (16), and Milan Crha (14). Why is this important to know? These are the top individuals who are getting the bugs resolved.

6. Who were the top three bug reporters? Bastien Nocera (12), Alexander Larsson (9), and Andreas Nilsson (8). Are these the same as the top three bug closes? No. What is the overlap in these two lists? Bastien Nocera, Sebastian Droge, and Michael Catanzaro.

7. Who are the top three contributors of patches? Carolos Soriano (26), Bastien Nocera (16), and Sebastian Droge (13).

8. Who are the top three reviewers of patches? Carols Soriano (25), Sebastian Droge (24), and Matthias Clasen (22). What is the overlap between these lists and the bug closers and bug reporters? Carlos Soriano, Bastien Nocera, Sebastian Droge, Michael Catanzaro, Debarshi Ray, Matthias Clasen, and Tim-Philipp Muller. What is the overlap between patch contributors and patch reviewers? Carolos Soriano, Bastien Nocera, Sebastian Droge, Michael Catanzaro, and Philip Withnall.

9. Click on the “Generate Graphical Reports” link.

10. Plot a line graph of the severity of bugs by component for Orca:

1. Select "Severity" for the vertical axis

2. Select "Component" for the horizontal axis

3. Select "Bar Graph" for type of graph

4. Leave the "Multiple Images" as <none>

5. Scroll down and select Orca from the Product menu.

6. Click "Generate Report".

11. What class were the majority of the bugs for braille? Normal

12. What other reports can you generate? Other graphical reports that can be generated include line graphs and pie charts in addition to the bar chart based on a wide variety of data.

Part 3: FOSS in Courses Planning 2

In refining my plans for implementing FOSS into my courses, my suggested activities would take place in an Introduction to Software Engineering course. As a foundation, I would select one HFOSS project to use throughout the semester. Below I summarize the three assignments.

Assignment 1: Learning about HFOSS.

This assignment would be designed for early in the course with the goal of having students explore the HFOSS community in general, and more specifically, the project that was selected for the course. It would be designed as the first exposure most students have with the FOSS community. The assignment sheet would guide students through an exploration of various web sites to introduce them to HFOSS, the specific project, and how projects are modular in design.

1. Identify some possible learning outcomes that should be fulfilled with the activities/task.

• define HFOSS
• differentiate between HFOSS projects and commercial software projects
• research and find information related to HFOSS projects
• relate phases in the Systems Development Life Cycle (SDLC) to various components of the selected HFOSS project
• explain how large software development projects utilize a modular approach to development
• explain the development methodology and compare it to the traditional waterfall approach

2. Describe any pre-requisite knowledge needed to complete the activity. This does not need to be a complete list.

• define open source software, FOSS, and HFOSS
• define SDLC
• describe each phase of the traditional SDLC
• describe different development methodologies that have evolved from the traditional waterfall approach (JAD, RAD, Scrum, Agile, UML, etc.)
• explain a modular approach to software design
• Student should be able to use the Internet for research.

3. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule. This activity would require some preparation on the part of the instructor, but would not be a significant amount of time. Since this would be an introduction, having the students explore the site for the selected project could accomplish the learning goals. This activity would not have to be synched up with the project community, and could be easily completed as long as the project web site was available. It would take the students 1-3 hours to complete, and would make a good one-week outside of class assignment.

4. Think about possible input required from the HFOSS community. How much input is required and what kind? None.

5. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness. None at this point.

6. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community? I would have this first activity as an individual project, to be certain that each student becomes familiar with the HFOSS project selected. The assignment would be a series of questions the student would have to answer. Grading would be based on the accuracy of the questions, some of which would be course content and some based on questions from the web sites.

7. List any questions or concerns that you have about the activity/task. I will have to be careful not to make this assignment too complex or involved, and always keep in mind that this is the introduction to the project.

8. List any stumbling blocks or barriers to carrying out the activity/task. None that I can think of.

Assignment 2: The Role of Testing in HFOSS

This could be a two part activity. The lower level activity would be an introduction to how testing is implemented as a phase in the SDLC in software development using the HFOSS project as the example. The assignment would be a series of questions based on a combination of course content and questions from the project web site related to testing. At a higher level, students could join the community and assume responsibility for testing, based on the needs of the project.

1. Identify some possible learning outcomes that should be fulfilled with the activities/task.

• list and describe different tasks that occur in the Testing phase of the SDLC
• explain why testing is important
• describe characteristics of an effective project test
• explain why it is important to keep a log of tests performed and what should be included in this log
• explain a bug tracking system

2. Describe any pre-requisite knowledge needed to complete the activity. This does not need to be a complete list.

• define the phases in the SDLC
• explain the steps in the Testing phase of the SDLC
• review of the bug tracking feature of the selected project

3. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule. This assignment would take the instructor quite a bit of time to create. Students could complete it in 2-3 hours as an introductory assignments. However, this assignments could be expanded for the more advanced student by having them actually get involved in doing some project testing and submitting input to the project community. For this level of participation, the instructor could set a goal of time or number of submissions. For maximum effectiveness, the student should receive response from someone in the HFOSS community, so it would best be completed during a time when the project is active.

4. Think about possible input required from the HFOSS community. How much input is required and what kind? For the lower level activity, none. For the upper level activity, someone to respond to the students' input regarding tests they have submitted and or tickets for which they have provided input.

5. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness. For the lower level activity, students would gain a wider understanding of HFOSS and the project being studied. For the upper level activity, students could actually work through some of the bugs and at least move them forward toward resolution.

6. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community? For the lower level activity, grading would be based on the accuracy of the questions, some of which would be course content and some based on questions from the project web site. For the upper level activity, additional grading would come from their bug submissions. It would be great if someone from HFOSS could comment on the quality of the students' submissions to the bug tracker.

7. List any questions or concerns that you have about the activity/task. None.

8. List any stumbling blocks or barriers to carrying out the activity/task. Feedback to students on the quality of their bug submissions. Students can get frustrated if they submit tickets or make comments, and do not see a result or response. Keeping the site active and current.

Assignment 3: Documentation in HFOSS

In this assignment, students would be assigned the task of reviewing the HFOSS project web site and related documents, first to answer the questions provided and later to submit changes/edits to the project site.

1. Identify some possible learning outcomes that should be fulfilled with the activities/task.

• describe the importance of effective project documentation
• define and give example of project repository
• describe who uses project documentation
• explain how documentation is useful to a programmer

2. Describe any pre-requisite knowledge needed to complete the activity. This does not need to be a complete list. Student should have a basic understanding of programming logic and design, have completed at least some prior programming assignments.

3. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule. This assignment would not take a lot of time for the instructor to prepare, and would require approximately 2-3 hours of student time outside of class. It could be done at any time as long as the HFOSS project web site was active and current.

4. Think about possible input required from the HFOSS community. How much input is required and what kind? Feedback provided to students as to the quality of their submissions.

5. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness. Identification of errors in format, content, spelling, etc on the web site and provided documents. Identification of errors or gaps in user documentation and support documents. Correction of some of these errors.

6. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community? Students could submit to the instructor the edits that they find and/or make. However, getting feedback from the HFOSS community would be invaluable in that it would be coming from a professional in the field and not just from their instructor.

7. List any questions or concerns that you have about the activity/task. None.

8. List any stumbling blocks or barriers to carrying out the activity/task. I would want to be sure that I, as instructor, understand the submission process well enough to make this work for the students.