User:Stefan.christov

Latest revision as of 01:47, 7 February 2017

Stefan Christov

Stefan Christov is an Assistant Professor of Software Engineering at Quinnipiac University. He currently teaches courses on software quality assurance, software engineering in health care, software project management, and a software engineering module in an introductory engineering course.

Stefan Christov's current research interests include improving the quality of human-intensive processes (HIPs), such as medical processes, with a focus on detecting human errors before harm is done and preventing such errors. He has used software engineering techniques to formally express and analyze models of complex HIPs and industrial engineering techniques to elicit and validate models of such processes. He is also interested in human-computer interaction techniques for presenting information to assist process performers during an ongoing process.

Stefan enjoys outdoor activities, such as running, hiking, and skiing. Other hobbies include traveling and salsa dancing.

Part A Activities

Answers to "Intro to IRC Activity" questions:

• How do people interact? By entering comments in the IRC channel, using a combination of free text and IRC commands.
• What is the pattern of communication? A meeting chair initiates the meeting and sets a topic. Other meeting participants discuss the topic (e.g., issues they have encountered, proposed solutions).
• Are there any terms that seem to have special meaning? 'IRC meeting chair', 'MeetBot', the IRC commands.
• Can you make any other observations? Occasionally, the meeting chair issues IRC commands to summarize discussion points and log action items.
• Join an HFOSS project's channel, observe for 24 hours, summarize observations. I joined the #foss2serve channel. For the period that I observed, someone changed their nick and there was an announcement about a conference.

Answers to "Project Anatomy Activity" questions:

• The Sugar Labs Project
  • Summarize the information under 'Contacts' for several teams of Sugar Labs. It is typical for a team to provide information about team coordinator(s), team members, and an IRC channel. Some teams also provide a mailing list.
  • Indicate the types/categories of tickets listed on this page as well as the information available for each ticket. Types: defect, enhancement, and task. Info for each ticket: ticket number, summary, status, owner, type, priority, milestone.
  • Does the project use a web-based common repository or a local repo? It uses a web-based repo.
  • Describe how the release cycle and roadmap update are related. A roadmap update is performed at the beginning of each release cycle.
• The Sahana Eden Project
  • Summarize the information found under each group. Most groups contain information about the activities of the group, guidelines for performing these activities, and information about tools to support these activities. The structure of the page for each team in the Sugar Labs project seems a bit more rigorous than the structure of the teams' pages in the Sahana Eden Project--for example, for the Sugar Labs project, each team's page starts with a mission, the contacts page has a standard set of sections, etc.
  • Tracker
    • How is the information here different than the information found on the Sugar Labs tracker page? The info here is organized by queries related to the existing tickets, such as tickets that are currently active and recently fixed bugs.
    • Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket. Types: defect/bug, enhancement, task, documentation. Info for each ticket: Ticket number, Summary, Component, Version, Priority, Type, Owner, Status, Date Ticket Created.
  • Does the project use a web-based common repository or a local repo? The code resides on GitHub, so there is a web-based common repository. Users/developers can clone the code into a local git repository on their machine.
  • Describe the information found on the project's roadmap. The roadmap contains different releases and the key features each release must contain, along with other information, such as how much of each release is completed and when the release is due.

Part B Activities

FOSS Field Trip Activity

Part 1 - SourceForge

Do the following:

1. Go to: http://sourceforge.net/
2. Use the Search feature in the center of the screen to view applications in an area of interest to you (e.g., gaming, sports, music, computing, etc.). Healthcare.
3. How many projects are there in this category? 2490
4. How many different programming languages are used to write software in this category? 15
5. List the top four programming languages used to write programs in this category. Java, PHP, C++, JavaScript
6. Identify the meaning of each of the statuses below:
   1. Inactive The project is not currently being worked on.
   2. Mature The project has been thoroughly tested, has been released and used? has a steady development community?
   3. Production/Stable The project is not rapidly changing, there are no major bugs, a working version has been released.
   4. Beta The project is in beta testing.
   5. Alpha The project is in alpha testing.
   6. Pre-Alpha The implementation on the project has started (i.e., it is part the planning stage), but alpha testing has not been performed yet.
   7. Planning The project is still being planned, major implementation hasn't started yet.
7. Compare two projects in this category that have two different statuses. Describe the differences between the statuses. OpenMRS, status Production/Stable; Digit Span Tester, status Inactive. I noticed that some projects are in at least two different statuses. E.g., OpenMRS seems to be both in Production/Stable and Beta statuses.
8. Which projects are the most used? How do you know? Hospital Management System, Liferay Portal, Pentaho, based on Sourceforge's sorting of projects by "Most Popular". Another indicator could be the number of downloads.
9. Pick a project in your category. Answer the questions below: YAWL
   1. What does it do? Provides support for modeling and managing workflows.
   2. What programming language is the project written in? Java.
   3. Who is likely to use the project? How do you know this? People interested in modeling workflows. Two major audiences are people who deal with business processes and people who deal with healthcare processes. This assumption is based on some prior knowledge about YAWL and the description of the project on Sourceforge.
   4. When was the most recent change made to the project? 2015-06-18
   5. How active is the project? How can you tell? The project seems pretty active based on the recency and the frequency of commits.
   6. How many committers does the project have? 3
   7. Would you use the project? Why or why not? Probably yes. It has high ratings, good reviews, and it seems that it is actively maintained.

Part 2 - OpenHub

In this activity, you will use OpenHub to gather information about a Humanitarian Free and Open Source project named OpenMRS.

Explore OpenMRS:

1. Go to: https://www.openhub.net/
2. In the upper-most search space, enter: OpenMRS
3. Click on the OpenMRS logo or link.
4. What is the main programming language used in OpenMRS? Java.
5. How many lines of code does OpenMRS have? 3,871,399
6. Click on "User & Contributor Locations" (lower right side of screen). List some of the locations of the developers. Boston, MA; Indianapolis, IN; Cape Town, Republic of South Africa.
7. Go back to the main OpenMRS page. Click on the "Languages" link. How many languages is OpenMRS written in? 15
8. What language has the second highest number of lines of code? JavaScript
9. Of the programming languages used in OpenMRS , which language the has the highest comment ratio? Java
10. Click on the “Contributors” link under "SCM Data" menu.
11. What is the average number of contributors in the last 12 months? 7
12. Scroll down to the Top Contributors section. How long have the top three contributors been involved in the project? 4 years
13. Use the information on the project summary page to compute the 12-month average of commits. What is the average number of commits over the past 12 months?. 64

Project Evaluation Activity

Material related to this activity is posted on my blog.

FOSS In Courses Activity

1. Topics of interest related to OpenMRS:
   1. The ability of OpenMRS to support core electronic health record (EHR) functionalities identified by the biomedical informatics community.
   2. The user experience associated with using, deploying, and maintaining an installation of OpenMRS.
   3. The possibility to integrate within OpenMRS a tool for providing real-time guidance to medical professionals as they perform a medical process.
   4. The ability of OpenMRS to collect data that can be used to support continuous improvement of medical processes into which OpenMRS is integrated.
2. Integrating FOSS-related activities into a course:
   1. Possible activity 1: Perform an evaluation of OpenMRS against each of the five functional components of an EHR as described in "Biomedical Informatics: Computer Applications in Health Care and Biomedicine", 4th edition, editors Edward Shortliffe and James Cimino, Springer, 2014. This activity can be part of a software engineering in healthcare course that I am currently developing. The main objectives of this activity would be to allow students to exercise their understanding of the core functional components of an EHR, familiarize themselves with an open source EHR, and potentially identify bugs/enhancements for OpenMRS.
   2. Possible activity 2: Evaluate OpenMRS's user interface against principles for designing usable graphical interfaces. This activity could be part of a human-computer interaction course.
   3. Possible activity/project 3: Integrate real-time process guidance within OpenMRS. There could be different variants of "real-time process guidance". One example would be a checklist that helps medical professionals adhere to best-practice protocols as they treat a patient.

Part C Activities

Bug Tracker Activity

Part 1 - Bug Reports

1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.
   1. ID A unique identifier for the bug/issue.
   2. Sev How severe the bug is, or whether it's an enhancement. Possible values: blocker, critical, major, normal, minor, trivial
   3. Pri The priority of the bug. Possible values: immediate, urgent, high, normal, low
   4. OS The operating system the bug was observed on. Possible values: All, AIX, BSDI, Cygwin, etc.
   5. Product The product or the component of the FOSS system with which the bug is associated. Possible values: accercizer, accountsdialog, acme, etc.
   6. Status The current status of the bug. Possible statuses for open bugs: "UNCONFIRMED", "CONFIRMED", "IN_PROGRESS". For closed bugs: "RESOLVED", "VERIFIED"
   7. Resolution Describes how the bug has been dealt with. This is applicable only to closed bugs. Possible resolution values: "FIXED", "INVALID", "WONTFIX", "DUPLICATE", "WORKSFORME"
   8. Summary A short sentence which succinctly describes what the bug is about.
2. Describe how you discovered the definitions and how did you find the information from above (hint: the advanced search shows the options or the Reports link has a link)? The descriptions are accessible via the Reports link, the possible values for each column can be found in the Advanced Search.
3. Identify the order in which the bugs are initially displayed? It appears that they are sorted by status, where unconfirmed bugs show up first.
4. What is the meaning of the shading of some bug reports?
5. What is the meaning of the colors used when describing a bug (red, gray, black)? Gray: enhancement, black: bug whose severity is less than critical; red: bug with severity at least critical
6. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). Bug 517888 - Missing events of buttons 4 and 5
   1. Identify when the bug was submitted. 2008-02-21 15:18 UTC
   2. Identify if there has been recent discussion about the bug? Not very recent--the discussion happened in 2008.
   3. Is the bug current? No.
   4. Is the bug assigned? To whom? At-spi maintainer(s)
   5. Describe what you would need to do to fix the bug. Familiarize myself in great detail with the at-spi product and in particular with the code that generates button events.
7. Repeat the previous step with a different kind of bug.

Part 2 - Collective Reports

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? How many were closed? 307 reports open, 245 closed
4. What was the general trend last week? Were more bugs opened than closed or vice versa? More were opened than closed.
5. Who were the top three bug closers? Why is this important to know? Matthias Clasen, Sebastian Dröge (slomo), Joanmarie Diggs (IRC: joanie). It is important to know, because this is an indication of who the active and knowledgeable developers on this project are.
6. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? Christian Stadelmann, Lapo Calamandrei, Sebastian Dröge (slomo). They are not the same, but one person overlaps. 4 people are on both lists.
7. Who are the top three contributors of patches?
8. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? Debarshi Ray, Jonas Ådahl, Sebastian Dröge (slomo). Some of the top bug closers are also among the top bug reporters. 4 out of the 10 people among the top patch contributors and reviewers are the same.
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? Line and table reports.

Source Code Management/Control Activity

1. Updated rollcall.md file and issued a pull request to the foss2serve/git-activity repository.

FOSS in Courses Planning 2

Proposed activity 1: Evaluation of an open-source electronic health record system

• Description: Perform an evaluation of OpenMRS against each of the five functional components of an electronic health record (EHR) as described in "Biomedical Informatics: Computer Applications in Health Care and Biomedicine", 4th edition, editors Edward Shortliffe and James Cimino, Springer, 2014.
• Learning outcomes:
  • Ability to evaluate an open-source software system against a set of criteria established by domain experts
  • Familiarity with the structure of an open-source project
  • Ability to navigate through an open-source project and successfully install and run the software
• Prerequisite knowledge
  • Familiarity with the functional components of an EHR
• Time estimates:
  • Instructor prep: 2 hours
  • Student completion: 3 hours
  • The activity does not need to be synchronized with the HFOSS's community schedule.
• Input from HFOSS community
  • If students use the online interactive demos of OpenMRS, little input will be needed from the HFOSS community.
  • If students are asked to set up and install OpenMRS, support from the HFOSS community might be needed with installation problems. The installation of OpenMRS requires the installation and configuration of several software components, such as a web server and a database management system. The installation guide on OpenMRS's page might be useful, provided that students have the necessary background to install and configure all the required components.
• Result of activity
  • Students will produce reports evaluating OpenMRS. These reports might identify new bugs or propose new enhancements, which might be useful to the community as they will be based on an evaluation with respect to peer-reviewed, widely accepted criteria for EHR systems.
• Assessment/grading approach
  • This would preferably be a team activity, but could also be performed by a single student, if more time is allocated.
  • Main assessment criteria could be whether the system was evalauted against all five functional components, how thorough and well-argumented the evaluation is, success with running/installing the system, and the sophistication of the scenarios/use cases explored as part of their evaluation.
  • Little help from the HFOSS community will be needed with assessing students' work. The HFOSS community might be able to help with decisions about whether bugs/enhancements that students identify have been previously identified and potentially judging the value of the newly proposed bugs/enhancements.
• Questions/concerns/stumbling blocks
  • Ease of installation of OpenMRS.

Proposed activity 2: Fix a bug or implement a proposed enhancement identified as part of the activity above

Idea: create a virtual machine with OpenMRS set-up on it. Students can start from there, instead of having to go through the installation process.