I've been looking for a solution for kindergarten teachers to submit daily student evaluations (different criteria) in Moodle. So far, the closest solution that I've found is the Attendance plugin.
Does anyone know of a plugin that allows the teacher to submit a daily evaluation?
Another option that I'm looking into is Moodle Competency, which can actually fit the need, however, it looks like competency is not cumulative ... if I can find a way to make it cumulative that will be awesome.
For example, one of the competencies we have is "able to read sentences" and the scale is "1 - non-developed", "2- being developed" and "3- fully developed". At any point, the teacher or school admin would like to know how competent the student is. In our case, if this is an indicator that is being responded daily, we should be able to take the average and be able to evaluate the student.
The competency framework (to my understanding) doesn't calculate the average, rather it relies on being rated by the teacher.
Any thoughts where I should continue to look?
Attendance could be a great solution to your needs.
It could be hidden to the ones acting like students (I'm not shure if the kindergarden kids be interested in see this, maybe their parents)
Attendance have a full compatibility with course grading.
It could be configured to have diferent percentaje of final grading, so far, you can use one attendance activity for have a registry for their personal clairliness, another to record assessment in math, one more to social assessment and so on.
Finally all users with minimun acces as teacher (or another role you defined: example: school administration, scholar control) Could have facilities to export every grading to spreadsheet.
I've several years using it in a similar way you are asking to.
I hope this helps you.
I've been using the Android billing client for a while now and always display the prices using getPriceAmountInMicros() from the SkuDetails object returned from the billing client.
Often we get complains from some of the customers that the price we display is not the same price they're paying. I've always assumed this is due to local taxes and that the Google play Store doesn't return the prices with local taxes included.
However, going to the documentation of getPriceAmountInMicros() things start to get a bit fuzzy. In particular this section:
This value represents the localized, rounded price for a particular currency.
What is a "localized price"? Is this including taxes? I cannot find any explicit place where it says this includes taxes or that it doesn't. By contrast the documentation for getPrice() explicitly states that the price does not include taxes.
Looking into a completely different resource, yet connected to a sku, one can see the same method - getPriceAmountInMicros(). In this method, it's explicitly stated that the price does not include taxes. It would seem odd to me that they would choose to name the method in a SkyDetails object the same, but have different semantics. Nevertheless, I want to be sure and would highly appreciate your help!
Thanks for pointing this out.
Because the QPS of computing taxes during skuDetails queries would be high, our servers defer tax computation to the purchase flow. So unless you need getPriceAmountMicros() for, say, refunds; you should simply use getPrice().
Is there a known way to deal with users writing responses over multiple lines? - is it best to handle this case on the client level? as in checking if the user is still typing and have a delay between responses, or can this be handled on Watson somehow?
An example would be:
Bot:
What's Your Name?
User:
My name is
Nour
Those are two independent messages by the user over 2 lines.
It is best to always send the full "utterance" to Assistant in one request, because the processing does not work across multiple split calls to Assistant. Otherwise you would need to do some complex logic with context variables, or ask back the user their name if they uttered "my name is" without an actual name.
Generally the client side UI would wait for the user to press Enter before sending the utterance to Assistant. So you can be sure they have entered the full utterance.
But perhaps if they do utter "my name is" you could have an intent which checks for a name and an entity that extracts the name, and a dialog node which if the intent is found has a slot which ensures the entity is also found. In that way, if they do say "my name is" and no name, the bot will ask them for their name.
DSeager's approach is potentially the right way for the example you gave. The reason being is that within your overall question you have an entity.
What about where there is on real entity? For example:
Two Intents.
Pay my speeding fine
Pay my parking fine
Here you are using the intents to understand the answer without the need of an entity. Some will argue the Intent->Entity approach, but depending on your solution it can generally not scale as well versus just an intent answer.
So now your user enters the following:
How do I pay my
parking fine
Entity solution doesn't really work here as you have no context that they want to pay.
So one approach.
1. Send "How do I pay my" to WA. Assuming you have trained the system well it should come back with a low confidence or irrelevant.
2. Before you respond to the user, see if another utterance has been cached to send. If it has, then append with some kind of marker and send. For example:
How do I pay my !! parking fine
This will return the correct answer.
But wait a second, what if they do this?
How do I pay my parking fine?
Where do I pay it?
Both are valid questions, but the second one will fail and you can't append it to the previous.
In this instance, when an answer displays have it set a $anaphora context variable. Then if you get a low confidence/irrelevant response try reasking with the $anaphora value appended.
For example:
Q: How do I pay my parking fine?
A: <Answer> $anaphora = "parking fine"
Q: Where do I pay it?
A: <Irrelevant>
Q: parking fine !! Where do I pay it?
Both of these require some work at the application layer.
In Opencart, I have a product which you select colors of.
Basically the pricing should be: Each additional printing color costs a flat rate of $50 + $0.25 for each.
So if a person were ordering 1000 items, with 2 colors, the cost would need to be BASECOST + $100($50x2) + $250(1000x$.25)
Right now I'm only able to set up the cost for each product. Since people are going to be both ordering large and huge quantities, there's no easy way to build it into the each price.
I could have sworn I saw a free extension awhile ago that allowed you to set both a flat price for an option, and a price for each on the quantity. Trying searching everything I could think of, but the only thing that I could find is for shipping (we already have a pretty complex setup for the shipping, so can't mess with that).
Has anyone came across a solution, or simple extension for this problem. Seems like a simple thing, but still can't find a solution for the life of me.
Thanks!
The easiest way I can see to do this would be to have fixed costs for certain price breaks which can be done through the Discount tab of each product, and can even be set based on customer group if you have wholesale as well as regular customers or other customer groups
An initial draft of requirements specification has been completed and now it is time to take stock of requirements, review the specification. Part of this process is to make sure that there are no sizeable gaps in the specification. Needless to say that the gaps lead to highly inaccurate estimates, inevitable scope creep later in the project and ultimately to a death march.
What are the good, efficient techniques for pinpointing missing and implicit requirements?
This question is about practical techiniques, not general advice, principles or guidelines.
Missing requirements is anything crucial for completeness of the product or service but not thought of or forgotten about,
Implicit requirements are something that users or customers naturally assume is going to be a standard part of the software without having to be explicitly asked for.
I am happy to re-visit accepted answer, as long as someone submits better, more comprehensive solution.
Continued, frequent, frank, and two-way communication with the customer strikes me as the main 'technique' as far as I'm concerned.
It depends.
It depends on whether you're being paid to deliver what you said you'd deliver or to deliver high quality software to the client.
If the former, simply eliminate ambiguity from the specifications and then build what you agreed to. Try to stay away from anything not measurable (like "fast", "cool", "snappy", etc...).
If the latter, what Galwegian said + time or simply cut everything not absolutely drop-dead critical and build that as quickly as you can. Production has a remarkable way of illuminating what you missed in Analysis.
evaluate the lifecycle of the elements of the model with respect to a generic/overall model such as
acquisition --> stewardship --> disposal
do you know where every entity comes from and how you're going to get it into your system?
do you know where every entity, once acquired, will reside, and for how long?
do you know what to do with each entity when it is no longer needed?
for a more fine-grained analysis of the lifecycle of the entities in the spec, make a CRUDE matrix for the major entities in the requirements; this is a matrix with the operations/applications as the rows and the entities as the columns. In each cell, put a C if the application Creates the entity, R for Reads, U for Updates, D for Deletes, or E for "Edits"; 'E' encompasses C,R,U, and D (most 'master table maintenance' apps will be Es). Then check each column for C,R,U, and D (or E); if one is missing (except E), figure out if it is needed. The rows and columns of the matrix can be rearranged (manually or using affinity analysis) to form cohesive groups of entities and applications which generally correspond to subsystems; this may assist with physical system distribution later.
It is also useful to add a "User" entity column to the CRUDE matrix and specify for each application (or feature or functional area or whatever you want to call the processing/behavioral aspects of the requirements) whether it takes Input from the user, produces Output for the user, or Interacts with the user (I use I, O, and N for this, and always make the User the first column). This helps identify where user-interfaces for data-entry and reports will be required.
the goal is to check the completeness of the specification; the techniques above are useful to check to see if the life-cycle of the entities are 'closed' with respect to the entities and applications identified
Here's how you find the missing requirements.
Break the requirements down into tiny little increments. Really small. Something that can be built in two weeks or less. You'll find a lot of gaps.
Prioritize those into what would be best to have first, what's next down to what doesn't really matter very much. You'll find that some of the gap-fillers didn't matter. You'll also find that some of the original "requirements" are merely desirable.
Debate the differences of opinion as to what's most important to the end users and why. Two users will have three opinions. You'll find that some users have no clue, and none of their "requirements" are required. You'll find that some people have no spine, and things they aren't brave enough to say out loud are "required".
Get a consensus on the top two or three only. Don't argue out every nuance. It isn't possible to envision software. It isn't possible for anyone to envision what software will be like and how they will use it. Most people's "requirements" are descriptions of how the struggle to work around the inadequate business processes they're stuck with today.
Build the highest-priority, most important part first. Give it to users.
GOTO 1 and repeat the process.
"Wait," you say, "What about the overall budget?" What about it? You can never know the overall budget. Do the following.
Look at each increment defined in step 1. Provide a price-per-increment. In priority order. That way someone can pick as much or as little as they want. There's no large, scary "Big Budgetary Estimate With A Lot Of Zeroes". It's all negotiable.
I have been using a modeling methodology called Behavior Engineering (bE) that uses the original specification text to create the resulting model when you have the model it is easier to identify missing or incomplete sections of the requirements.
I have used the methodolgy on about six projects so far ranging from less than a houndred requirements to over 1300 requirements. If you want to know more I would suggest going to www.behaviorengineering.org there some really good papers regarding the methodology.
The company I work for has created a tool to perform the modeling. The work rate to actually create the model is about 5 requirements for a novice and an expert about 13 requirements an hour. The cool thing about the methodolgy is you don't need to know really anything about the domain the specification is written for. Using just the user text such as nouns and verbs the modeller will find gaps in the model in a very short period of time.
I hope this helps
Michael Larsen
How about building a prototype?
While reading tons of literature about software requirements, I found these two interesting books:
Problem Frames: Analysing & Structuring Software Development Problems by Michael Jackson (not a singer! :-).
Practical Software Requirements: A Manual of Content and Style by Bendjamen Kovitz.
These two authors really stand out from the crowd because, in my humble opinion, they are making a really good attempt to turn development of requirements into a very systematic process - more like engineering than art or black magic. In particular, Michael Jackson's definition of what requirements really are - I think it is the cleanest and most precise that I've ever seen.
I wouldn't do a good service to these authors trying to describe their aproach in a short posting here. So I am not going to do that. But I will try to explain, why their approach seems to be extremely relevant to your question: it allows you to boil down most (not all, but most!) of you requirements development work to processing a bunch of check-lists* telling you what requirements you have to define to cover all important aspects of the entire customer's problem. In other words, this approach is supposed to minimize the risk of missing important requirements (including those that often remain implicit).
I know it may sound like magic, but it isn't. It still takes a substantial mental effort to come to those "magic" check-lists: you have to articulate the customer's problem first, then analyze it thoroughly, and finally dissect it into so-called "problem frames" (which come with those magic check-lists only when they closely match a few typical problem frames defined by authors). Like I said, this approach does not promise to make everything simple. But it definitely promises to make requirements development process as systematic as possible.
If requirements development in your current project is already quite far from the very beginning, it may not be feasible to try to apply the Problem Frames Approach at this point (although it greatly depends on how your current requirements are organized). Still, I highly recommend to read those two books - they contain a lot of wisdom that you may still be able to apply to the current project.
My last important notes about these books:
As far as I understand, Mr. Jackson is the original author of the idea of "problem frames". His book is quite academic and theoretical, but it is very, very readable and even entertaining.
Mr. Kovitz' book tries to demonstrate how Mr. Jackson ideas can be applied in real practice. It also contains tons of useful information on writing and organizing the actual requirements and requirements documents.
You can probably start from the Kovitz' book (and refer to Mr. Jackson's book only if you really need to dig deeper on the theoretical side). But I am sure that, at the end of the day, you should read both books, and you won't regret that. :-)
HTH...
I agree with Galwegian. The technique described is far more efficient than the "wait for customer to yell at us" approach.