User:Jnwokeji
From Foss2Serve
(Difference between revisions)
(→FOSS Activities/Topic and Structure) |
(→FOSS Activities/Topic and Structure) |
||
(5 intermediate revisions by one user not shown) | |||
Line 261: | Line 261: | ||
|- | |- | ||
! style="width:10%;" | FOSS Activity/Topic | ! style="width:10%;" | FOSS Activity/Topic | ||
− | ! style="width: | + | ! style="width:30%;" | Learning Oobjectives |
− | + | ||
! style="width:10%;" | Structure | ! style="width:10%;" | Structure | ||
! style="width:10%;" | Time Required <br/> (''All activities are independent of the HFOSS community schedule'') | ! style="width:10%;" | Time Required <br/> (''All activities are independent of the HFOSS community schedule'') | ||
Line 268: | Line 267: | ||
! style="width:15%;" | Grading Criteria | ! style="width:15%;" | Grading Criteria | ||
|- | |- | ||
− | | ''' (Re-)Engineering use cases ''' | + | | ''' (Re-)Engineering use cases ''' |
− | | | + | |(a) Translate user needs into use case diagrams using UML standards. (b) Apply use case description template to analyze and clarify use cases. |
− | + | ||
|Lecture, assignment, and project. | |Lecture, assignment, and project. | ||
− | | | + | |1 week lecture (2 classes of 90 mins each); Assignment: 1 week. Project: 3 months, submitted towards the end of the semester. |
|Serve as stakeholders to provide feedback and be available to answer students questions. | |Serve as stakeholders to provide feedback and be available to answer students questions. | ||
|To get full mark, students must create use case diagrams and descriptions that meet UML standards, and clearly describe all the elements of each use case. | |To get full mark, students must create use case diagrams and descriptions that meet UML standards, and clearly describe all the elements of each use case. | ||
|- | |- | ||
| '''(Re-)Engineering Quality Requirements''' | | '''(Re-)Engineering Quality Requirements''' | ||
− | | | + | |(a) Specify functional requirements that satisfy all the characteristics of good requirements specification. (b) Identify and specify non-functional |requirements or NFR; develop data requirements and high level data model; produce a complete software requirements specification. |
− | + | ||
|Project, and stream of related activities. | |Project, and stream of related activities. | ||
|Review and revise functional requirements; provide feedback and constructively critique functional specification; implement functional requirements |specified by students. | |Review and revise functional requirements; provide feedback and constructively critique functional specification; implement functional requirements |specified by students. |
Latest revision as of 19:45, 8 November 2017
Joshua C. Nwokeji
Dr. Joshua C. Nwokeji is an assistant professor of Information Systems at the Department of Computer and Information Science (CIS), Gannon University Erie, Pennsylvania. He completed his Ph.D., in June 2016, and joined CIS Dept., in August 2016. Click here to view my [My Homepage].
As a faculty in early career stage, Joshua is seeking and willing to collaborate in research that will lead to high quality publications and attract funding. Please feel free to [get in touch].
Joshua is interested in these broad research areas:
- Software Requirements Engineering,
- Goal oriented requirements engineering (GORE);
- Enterprise Modeling and Agility;
- Systems Analysis and Design;
- Requirements Engineering Education;
- Enterprise Architecture.
Currently, Joshua has few publications in these areas, some of which are available in Google Scholar.
Contents |
Stage 1 Activities
Intro to IRC: Deliverables
- How do people interact?
- Interactions are generally via instant messaging.
- What is the pattern of communication?
- Not sure, but based on my experience in using IRC, I would say that communication is linear, formal and can be a mix one to many, and one to one.
- Are there any terms that seem to have special meaning?
- It appears that terms such as 'startmeeting', 'action', 'info', topic, 'endmeeting' etc., have special meaning.
- What advantages might IRC have over other real-time communication methods (like Google Chat or Facebook Messenger?) Are there potential disadvantages?
- I think IRC is more structured and can ensure anonymity more than the others. Keeping track of who left the meeting is really cool.
- Commands:
- /whois','/quit', '/me', etc.
Sugar Labs Project
- Summarize the roles that you think would be most applicable for your students.
- Designer--My students can contribute to requirements development and management (any requirements development team?).
- What are the commonalities across roles? What are the differences?
- Each role specifies a set of skills, projects and teams, specific tasks, and contact person.
- Some roles include links to mentors and mailing list.
- Describe the general process for submitting a bug.
- Step 1: Find the activity that relates to the bug in the repository using this [link]
- Step 2: In the repository page select 'issues'.
- Step 3: Click on 'New Issues'
- Step 4: Login into GitHub if you already have account else create account first
- Step 5: Enter title, describe the issues and submit.
- Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.
- Issues; pull request.
- Last Commit.
- September 8, 2017
- Describe how the release cycle and roadmap update are related.
- I think that roadmap update is the herald of, or provide detail information about, a release cycle.
The Sahana Eden Project
- Community
- POSSE and students can contribute to any of the following roles:Developers; Testers (Bug Marshals); Community Outreach; Designers; Documenters; GIS Specialists; System Administrators; and Translators
- In general, roles have similar structure to the Sugar Lab project and include information that can be useful to prospective volunteers. But, some roles provide more support for newbies than others. For instance, the 'Developer Role' has a mailing list, virtual training environment,and developers guidelines.
- Tracker
- I found tickets that relates to the following components of the software: Request Management; User Interface; GIS Mapping, Inventory, etc. Tickets are structured in tabular format containing the following columns: Ticket Number (appears to be a unique ID); summary (a brief description); component (I think component/module of the program where bug is found); priority, type, owner, and date created.
- Repository
- The last commit was done today October 5th 2017.
- Release Cycle: I found three (3) milestones on this page:
- Milestone 0.9.0 "Medway" is 92% completed with a total of 107 tickets, out of which 92 are closed and 7 are open. Some of the functionalities to be delivered in this milestone include: GIS, advanced interactive search, request management, and other.
- Avon or Milestone 1.0 is 73% completed with 106 tickets out of which 77 is closed while 29 is active. Messaging, synchronization, GIS, and Android application supports are among the key deliverables in this milestone.
- Milestone 2.0 is 98% completed, only 1 ticket out of 45 is open. The key functionalities include AJAX UI Framework, Workflow Engine, and Offline Support.
FOSS Field Trip
- How many repositories are there in this category?:
- 15,649.
- What information does this page provide?:
- Commit provides information about updates, changes or revisions to the application.
- How many repositories are there in humanitarian category?
- 331
- Locate the HTBox/crisischeckin project. When was the last update?
- Last update: April 2017
- How many repositories are there in 'disaster management' category?
- 173
Part 2--Openhub
- How many projects were returned?
- 225 pages (225*10) 2250 projects.
- Is any of the code located on GitHub?
- Most of the code 'Repository URL' listed their 'SCM type' as Git.
- How many similar projects are listed?
- I counted ten similar projects.
- What information does OpenHub provide about the project?
- I found the following information: Project Summary; Code Data; SCM Data; Community Data.
- How many projects were returned for each search:
- 3 pages or 30 humanitarian projects.
- 3 pages or 30 disaster management projects.
- Why do so many projects do not have activity information available?
- This because there are little or no commits and contributors to these projects.
- Information on Organizers Page:
- This page provides a table that gives information about the organizations that are working on various projects. Available information include: The type, size, number of projects, and number of affiliates for each organization. It also shows the 30 day commits, and the most active organization.
- When was the last commit for OpenMRS Core?
- 11 Days Ago (September 28th 2017).
- The last commits on GitHub: Jul 10, 2017
- These two FOSS platforms are used by different people/volunteers, in different locations, this, I believe, is why there are different commit dates for both them.
- I think using the two can provide more options and alternatives for volunteers i.e., if someone is not comfortable using GitHub then they can use OpenHub.
- The major drawback could be the inconsistencies in information on both platforms e.g., dates of commits. These can be confusing.
Project Evaluation Rubric
Evaluation Factor | Level (0-2) |
Evaluation Data |
---|---|---|
Licensing | 0 (I did not see license for the OpenMRS Project) | Appears not to use an OSI approved open source license? |
Language | 0 Java (95.4%) SQLPL (3.0%) GAP (0.7%) | I currently do not have expertise in these languages |
Level of Activity | 1 | Some quarters are active in the past year. |
Number of Contributors | 2 | There are currently 271 contributors |
Product Size | 1 (220.81MB) | The Google Chrome Extension shows the size in MB instead of lines of code |
Issue Tracker | 1 | I found 19 open issues, 1 closed issue and 1 cancelled issue. |
New Contributor | 2 | OpenMRS provides step by step instructions for downloading and installing the development environment, [see No 5 and No 6]. Communication Mechanisms such as Telegram and IRC are apparent, [see No 10]. The discussion platform can be accessed using the link in [see No 4], but it appears that no discussion has been posted this year, the last posted was in March 2016. Web presence is included [in this link]. |
Community Norms | 2 | Based on my review, the communications appear appropriate and professional |
User Base | 1 | There are some instructions on how to download and install the software. But it is not very clear how many are actually downloading and using the software. |
Total Score | 10 |
Intro to Copyright and Licensing
Project | Can | Cannot | Must | Can Contribute |
---|---|---|---|---|
openmrs/openmrs-core | None at the moment | None at the moment | None at the moment | No, because the license currently does not state terms of usage i.e., what I can, cannot, and must do. |
apache/fineract | Distribute; modify; be used for commercial purposes; and sublicense. | Hold software/license owner liable for damages; and use contributor's name, trademarks or logos. | Include copyright; and license. | Yes, because the license clearly states what I can, cannot, and must do; and I accept these terms. |
regulately/regulately | N/A | N/A | N/A | No, because the license currently does not state terms of usage i.e., what I can, cannot, and must do. |
FOSS in Courses 1
- Requirements and Project Management (GCIS514/CIS350 ): The course focuses on the requirements engineering and project management process, and how these two practices are intertwined. Requirements engineering (RE) includes the study of tools, methods and techniques that covers the key phases of software requirements development process i.e., elicitation, analysis, specification, and validation. Along with the requirements engineering focus, the project management skills for managing software projects are addressed. The course also includes specific techniques for requirements modeling and management as well as a general introduction to the PMBOK terminology. Ethical practice of software engineering and information system development is addressed.
- Students in my 'Requirements and Project Management Course' can benefit from the following activities under the 'Specification and Design' category:
- (Re-)Engineering A Domain Model:
Students will be expected to build conceptual models to help understand the system under study. Sample models include business process, data model, goal model, context diagram, ecosystems map, etc. - (Re-)Engineering A System Vision:
Students will be expected to deliver a 'vision and scope' document for a selected HFOSS project) - (Re-)Engineering Quality Requirements.
- (Re-)Engineering Stakeholders:
Students will be expected to identify and analyze stakeholder analysis using TOGAF stakeholder map, RACI matrix/chart, and other techniques - (Re-)Engineering use cases:
Students will be expected to produce use case models and use descriptions. - Propose New Features:
Students will be expected to propose new systems features, feature tree model can be used to organize new features.
- (Re-)Engineering A Domain Model:
- Students in my 'Requirements and Project Management Course' can benefit from the following activities under the 'Specification and Design' category:
Bug Reports
Columns | Definition | Range of Values |
---|---|---|
ID | Bug Identification: A number or code that uniquely identifies each bug. | Integer |
Sev | Bug Severity: Shows how severe the bug is and whether or not the bug is an enhancement. | Blocker ("application unusable") to trivial ("minor cosmetic issue"). (I also found others such as critical, major, enhancement, and normal). |
Pri | Bug Priority: Shows the priority of the bug. | From low to Urgent (I also found others such as normal and high) |
OS | Bug Operating System: Shows the operating systems where the bug was found. | Linux, Windows, Mac, others. |
Product | A classification scheme for bugs. Each bug is product that has some components. | Character Strings |
Status | Bug Status: Describes the state of the bug, e.g., Assigned. | New, 'need info', unconfirmed, reopened, assigned, closed. |
Resolution | N/A | N/A |
Summary | Provides a short summary of the bug usually in one sentence. | Character Strings |
- I discovered these information by selecting the 'Help" link from the GNOME homepage and navigating to Section 5.3: "Anatomy of a Bug'.
- I think bugs are initially ordered by priority from low to urgent.
- I think the color is used to show the severity of the bug: Red shows that a bug is critical; grey shows that a bug is an enhancement; while black shows that a bug is normal.
- Bug 317764 - make desktop icon text easier to read
- Bug submitted on: 2005-10-02 19:58 UTC by Jean-François Fortin Tam. Modified: 2017-08-19 00:22 UTC.
- The most recent discussion on this bug was on: 2017-08-17 19:35:30 UTC by António Fernandes
- The status of this Bug is new.
- This Bug is assigned to: Gnome-themes-standard-maint.
Collective Reports
- 13+27+27+1+2+6+8+1+18+6+3+14= 126 bugs reports were opened in the last week.
- 35+32+21+1+25+7+11+1+16+2+3+6= 160 while 12 were closed.
- I think more bugs were closed than than opened last week.
- The top three bug closers are :
- Philip Withnal; closed 25 bugs.
- Michael Gratton; closed 24 bugs.
- Matthias Clasen; closed 24 bugs.
- I think recognizing top bug closers is a source of motivation.
- The top three bug reporters are:
- Ralf; reported 8 bugs
- André Klapper; reported 6 bugs
- gkrithi8; reported 5bugs
- i think these are not always the same as the top three bug closes, but in this case André Klapper is both a bug reporter and a bug closer.
- The top three reviewers of patches are :
- Philip Withnall; reviewed 30 patches.
- Sebastian Dröge (slomo); reviewed 23 patches.
- Matthias Clasen; reviewed 17 patches.
- In general, I think anybody can assume any of the roles: closer, reporter, reviewer, contributor, etc.
- Graphs:
FOSS Activities/Topic and Structure
FOSS Activity/Topic | Learning Oobjectives | Structure | Time Required (All activities are independent of the HFOSS community schedule) |
Input from HFOSS | Grading Criteria |
---|---|---|---|---|---|
(Re-)Engineering use cases | (a) Translate user needs into use case diagrams using UML standards. (b) Apply use case description template to analyze and clarify use cases. | Lecture, assignment, and project. | 1 week lecture (2 classes of 90 mins each); Assignment: 1 week. Project: 3 months, submitted towards the end of the semester. | Serve as stakeholders to provide feedback and be available to answer students questions. | To get full mark, students must create use case diagrams and descriptions that meet UML standards, and clearly describe all the elements of each use case. |
(Re-)Engineering Quality Requirements | requirements or NFR; develop data requirements and high level data model; produce a complete software requirements specification. | Project, and stream of related activities. | specified by students. | structured in a readable and understandable format. Data model and NFR must conform to standards. | |
(Re-)Engineering A System Vision: | Students will be expected to deliver a 'vision and scope' document for a selected HFOSS project. | Project, and stream of related activities. | |||