Guidance/help/suggestions for creating (grad) student assignments

Community
, ,
1

Hi all,

I’ve been following OpenMRS for a while and using it in my courses as an example for class assignments. However, I’d like to have my students contribute more as opposed to just doing assignments that then just lie on the shelf an die. :wink:

This semester, I am teaching a graduate course in advanced software engineering and I still have a few assignment slots to fill. While I see great things of all kinds they could contribute, I need to be able to relate it to the topics I am teaching in that course and I could use some guidance. I tried to find assignments on my own that would be suitable for those topics but I think you may have a better overview and experience of how to create adequate tasks. So I am reaching out to officially connect and to ask whether you would be interested in proposing a few tasks students could work on?

The topics I am looking to cover are Estimation for software projects, Project scheduling, Risk management, Maintenance and reengineering, Dependability of systems, Reliability engineering, Safety engineering, Security engineering, and Resilience engineering. If you have any ideas for a couple of these doing something that could contribute to OpenMRS I’d be open to hearing them. Each task should ideally be 4-6 hours of estimated effort. I’m sure we can find a good maintenance one, but maybe also scheduling and something around some of the quality characteristics?

Looking forward to hearing from you! Please put me in touch with who I should be bugging about this :smile:

Kind regards, Birgit

2 Likes
2

Also, I taught a course on requirements engineering in Spring where I used OpenMRS as system under analysis. I’d love to feed some of that back into the community (requirements reengineering, analysis, etc.) but I am not sure how. Anyone in that area who can make suggestions for that? I’ll be happy to provide more details on what we did and what the deliverables were. Most of the produced artifacts were stakeholder models, goal models, use case specifications, and the likes. Slides for the content are available here: https://www.slideshare.net/kamikitty/requirements-engineering-introduction

3

@twinkleflip this is a great initiative and thank you very much! :slight_smile:

Concerning who you should be bugging about this, am one of them. :smile: Do you mind sharing examples of tasks you have been doing for these assignments? This will help us get more informed about what you are looking for.

Regarding the system analysis, you can start a new talk thread and post the feedback for our consumption. I have looked at your slides and they are good.

4

Wonderful, I am happy to get a positive response here :slight_smile:

Yes, let’s see, here are the assignments I have given them for the first two topics:

1) Assignment: Process and project metrics

This is the hands-on assignment for you to practice getting into the details of process and projects metrics. Submission by Tuesday, Sept 26th 5pm into the BeachBoard Dropbox (our online submission system). We will be assessing the metrics of a Humanitarian Free Open Source Software (HFOSS) project called OpenMRS. First, to get yourself acquainted with the project, you will carry out an introductory activity. Second, you will perform a project assessment and search for project, process and product metrics you can find in the project infrastructure and documentation. _ ( … omitting description of how to get familiar with OpenMRS … )_

a) Research the different infrastructural and documentation parts of the OpenMRS system and develop a metrics catalogue (see template in table below) of what you were able to identify and classify in terms of process metrics and project metrics.

_Table to fill in with columns titled as follows: _ _- Metric (first list process metrics and then list project metrics) _ _- Instance in OpenMRS (and the source of where you found it plus URL) _ _- Unit (of measurement) _ - Assessment and Rationale (why is the metric important, is this a good or a bad value, and why do you think so) _ _ b) Look at the bug tracker for OpenMRS and compute the defect removal efficiency (DRE) over the last 12 months. Document your assumptions, where you took the information from and what exactly you used as an input.

c) Please write about 200 words in which way the measurement of FOSS projects differs from measurement of a standard commercial software project.

2) Assignment 2: Estimation and Scheduling

This is the hands-on assignment for project estimation and scheduling. Submission required by Tuesday, Oct 3rd 5pm into the BeachBoard Dropbox. _As you got yourself acquainted with the OpenMRS project, you hopefully _ _• Got an OpenMRS ID https://id.openmrs.org/, _ _• Introduced yourself Welcome! Please introduce yourself. _ • And got your first badges reading the guidelines etc. And took a look around the • Guide http://guide.openmrs.org/en/ _• Documentation Wiki https://wiki.openmrs.org/display/docs/Home _ _• Issue Database https://issues.openmrs.org/secure/Dashboard.jspa _ _• Wiki Developer Guide (more concise) https://wiki.openmrs.org/display/docs/Getting+Started+as+a+Developer _ _• Developer Guide (more detailed) _ http://devmanual.openmrs.org/en/ _• Collaboration tools http://devmanual.openmrs.org/en/Community/collaborationTools.html _ _If you haven’t done that yet, please do so this week. Next, I would like you to self-assess whether you have learned your way around OpenMRS yet https://www.surveymonkey.com/r/omrs-dev1 _

For the project estimation and scheduling, take a look at the Technical Roadmap to get started: _https://wiki.openmrs.org/display/docs/Technical+Road+Map _

_Then use your best educated guess of OpenMRS for filling out the following parameters in the COCOMO calculator: http://csse.usc.edu/tools/COCOMOII.php _

Copy the results into a document and add 200 words of description on your choice of factors and your rationale for that. That includes the milestone of the Technical Roadmap you are using for your size estimate as well as the factors that go into the calculation. I’d suggest doing a table for all those factors and assumptions and then a final conclusion comment on what your experience was with trying out different numbers and settings.

Further planned assignments: Those two past assignments made them use what we learned about in class but it doesn’t feed back into your project in any helpful or meaningful way. Therefore I would like to get some suggestions on what you think may be suitable assignments and tasks for the following topics and then we can hopefully contribute something meaningful to the project :slight_smile:

Potential Topics:

  • Project scheduling
  • Risk management
  • Maintenance and reengineering
  • Dependability of systems
  • Reliability engineering
  • Safety engineering
  • Security engineering
  • Resilience engineering

Looking forward to input and discussions and collaboration :slight_smile:

5

PS: Will be adding a separate thread on feedback for the requirements reengineering we did in Spring.

6

Ok, I’ll be moving into these topics soon, in the order they appear - still brightly-eyed looking for suggestions on where we can contribute :slight_smile:

  • Maintenance and reengineering
  • Dependability of systems
  • Reliability engineering
  • Safety engineering
  • Security engineering
  • Resilience engineering For example, is there a list of maintenance issues I should be looking at to then create a list of tasks suitable for my students? Except the curated bugs one? Thank you!
7

By maintenance and reengineering am assuming you mean the process of continuous bug fixing and improvements, right?

8

Yes, exactly :slight_smile:

9

We use jira for versioning and issue tracking i.e bug fixes and new features, you want to be looking at the tickets marked as ready for work because those are the ones in the work queue.

10

Hi @twinkleflip ,

I am about to pass over to the OpenMRS Community a module that we developed a while ago for one of our clients (VDUI, see here) . There is a broad roadmap envisioned for this module, with quite a bunch of tasks of various complexity and going all the way through the tech stack.

Something that might interest you is that the actual roadmap needs to be defined and detailed prior to everything else that needs to be done.

Would that be a useful ‘school case’ for your group of students?

Cc @mogoodrich

11

Ok, thank you @wyclif , that I have already been doing and we are continuing on that track. :slight_smile:

12

That may indeed be a good case @mksd as it is a much more confined scope and it may be easier for the students (and me :wink: ) to get an overview. I will look into it in more detail. Developing a more detailed roadmap certainly sounds like a good task for the Requirements Engineering course (Jan-May 2018). But not sure whether that fits your timeline or you wanted / needed that earlier. Were you envisioning that over the next 6 weeks or rather a few months from now?

Would you be willing to serve as our point of contact for this? And you said there is a broad roadmap envisioned. Is there any of that documented or how can we elicit the information for that? Meeting minutes of IRC chats? Talking to you over Skype?

13

Yes I would have envisioned the detailed roadmap to be set out within the next 6 weeks. But it doesn’t have to be. I would rather have imagined that by end of May a new version of VDUI would be released. Meaning that the whole development cycle would have then been performed.

What I meant to say is that you could certainly use VDUI to cover multiple types of assignments, from outlining a clear set of requirements to actually releasing new features down the line.

Yes sure.

It’s been written here and there on Talk. So I could gather everything in one place, maybe just in a Google Sheet or something? And this would be a starting point for a todo/wish list. This list + analysing the current state of VDUI (so at runtime) could kick start the engineering of requirements.

How does that sound? We can certainly discuss this over a call as well, please PM me your Skype ID, I’m on CEST.

14

@mksd Thank you for the additional details. Ok, I can work with that. Yes, pulling everything together in a Google Doc would work well for me. Sure, I’ll PM you my Skype ID.

15

@mksd following up on our Skype call today where we established that I ask my students about their interest in working on VDUI and get back to you. Answers:

  • 2-3 yes to interested on working on a roadmap
  • 8-9 yes to interested in replicating and reporting bugs
  • 7-8 yes to interested in fixing bugs and developing (these students are a subset of the 8-9 yes above)

So please do gather all the information for the roadmap in a Google Doc and share the access with us. I will have a small team working on the roadmap and a larger set of students on fixing issues and implementing.

1 Like
16

Hi @twinkleflip,

That’s fantastic news! I’m really glad that this project caught their interest!

Yes as agreed I will gather all items in one Google Sheet. And I guess we should call this module “Attachments” from now on then, and no longer “Visit Documents UI”. See this thread from here.

Cc @mogoodrich @dkayiwa

17

Sounds great! Looking forward to this collaboration!

18

@twinkleflip Great that this is moving. I would also like to suggest that part of the deliverables also include documentation on how to use the module being developed which is a usually missed aspect of software engineering/development but a very important aspect for users. This is a cross-cutting effort across all the groups of students and is highly collaborative too.

1 Like
19

Yes, it is a very important aspect, and we can already see in the distribution of people interested (and voicing enthusiasm) in coding versus writing roadmap why documentation is often ‘missed’. :slight_smile:

And that’s why I need to teach them to still do it, so I’ll advocate for this. There is a good start provided in the readme file, and I think we can get some good user documentation produced.

Where shall we put this while in the making? Are drafts on Google Docs with links in here a good way to keep things traceable and accessible while in draft stage?

20

Update: 3-4 potentially interested in documentation. You mean to guide future users, right? Where apart, from the readme file on github, is the module (partially) documented so far? Also, pointers towards what the format of the documentation should be like? (Maybe a good example to point to from another module?)