So, Modules are filled with Objects, only some of which are requirements. Links to non-requirements are meaningless... but naturally users insist on doing that, regardless. Lazy, careless, or simply undertrained; our users are humans, who will often enter highly imperfect data.
What's the best way to forbid such mislinks? Is there a native way? I fear not, although it seems rather basic. Pop up an annoying warning whenever they try, via DXL?
We have an enumerated Attribute that will tell us if the target is a requirement or not.
You can use triggers to accomplish this!
For a very brief idea, see this relatively recent conversation
You will want a pre-create trigger on the link confirming whether it's target object has the correct enumerated type. This could be a database level trigger, or project level, or even module level if there is only one particularly bothersome section.
Keep in mind this is only for more up-to-date versions of DOORS. Older versions will require something a bit more complex- for example, a trigger that checks a module pre-close to see if any links have been created, and if so if they have 'valid' targets according to your criteria. You could have a post-open dxl that creates an array of links and stores it in the DXL top context... but that might be a bit advanced.
I came across this a few times in my career and never really found an answer. My question is in regards to a web form that contains multiple controls that the user can update, and then saves the data to a database (easiest example I can think of right now is a user profile form - see SO profile edit screen).
So far, I have always just saved every control's value to the database. To me, it seems easier to have one method that calls one stored procedure, passing all the page's form values in.
I have seen pages that seem to save the individual control's value, rather than the entire set of controls. It can definitely look nice (if the page is doing it through AJAX), but is it better? I would think you would need more overhead to get this done, like one (or many?) DTO, more methods, and more stored procedures?
Which way is better? And are there any examples of how the individual control way is done?
Thanks!
I'd generally recommend using the individual control method; it provides for much greater granularity of design.
Depends what you mean by better.
"one method, stored procedure" - quicker to code, easier to maintain. "save the individual control's value" - more optimized? I'd leave optimization to last. Looks nicer? Is usability actually a problem on this page? YAGNI - fix performance/usability only if they are broken.
Some thoughts
It's one call to the database whether it's 25 columns or a single column
(Similar) If you update 6 controls in one edit session, you do it in one call rather than 6 separate ones
You may have forms with dependent or linked controls or disallowed value combinations: The general case would be "multiple control" changes in one edit session: so code for this
The general idea of auditing/timestamping is at the unique *row *level, not column.
We're evaluating the 45 demo of fogbugz. Thus far I like it, but there are some obvious things I'm missing.
What boggles me the most is how I can easely alter fields in the list view. I would like to open the detail screen as little as possible. It seems to be possible with the estimation column, why isn't it possible with all the other fields (like project, priority, status etc.?).
What you are asking for can not be done in FogBugz 6. You have to open up the case in order to edit most of the fields. Why they made exceptions for time estimates, I don't know.
The rationale here was as a feature to accompany quick case entry. (That's the "Add Case" link at the bottom of each group or at the bottom of the grid.)
The thinking was that it'd be neat to be able to add cases quickly and then burn through the list, estimating them quickly. We didn't really expand our thinking to include moving cases around or changing things like releases/milestones, etc.
This is something we'd like to offer in the future for many more fields, and one of those weird situations where adding a small, specific feature can sometimes make the fact that the larger, general implementation of that feature isn't there yet.
FogBugz 6 isn't big on customisation. You can edit the categories and statuses in the database tables directly (though you need to edit the "internal" project and click OK for the cache to be refreshed.
FogBugz 7 is coming out this year hopefully, and may well address many of these issues.
This question is intended to be a discussion of people's personal opinions in handling user input.
This portion of the project that I am working on handles user input in a manner similar to an IRC chat. For instance, there are set commands and whatnot, for chatting, executing actions, etc.
Now, I have several options to choose from for parsing this input. I could go with regular expressions, I could parse it directly (ie a large switch statement with all supported commands, simply checking the first x number of characters in the user input), or could even go crazy and add in a parser similar to Flex/Bison implementations. One other option I was considering was defining all commands in an XML file to separate them from the code implementation.
So, what are the thoughts of the community?
I'd go with a nice mixed bag of all.
Obviously you'll have to sanitize the input. Make sure there's no nasty stuff there, depending on where the input is going to prevent SQL injection, XSS, CSRF etc...
But when your input is clean, you could go with a regexp that catches the ones intended as command and gets all necessary submatches (command parameters etc.) and then have some sort of dispatcher-switch statement or similar.
There really is no cover-all best practice here, apart from always always and quadruple-always making sure user input is sanitized. Apart from that, go with what seems to fit best for your case.
Obviously there are those that say if you've got a problem and you're thinking of using reg exps to solve said problem, you've got two problems, but used cautiously, they're the best thing ever. Just remember that regexp-monsters can read to really poor readability really quick.
I'm currently evaluating the MSF for CMMI process template under TFS for use on my development team, and I'm having trouble understanding the need for separate bug and change request work item types.
I understand that it is beneficial to be able to differentiate between bugs (errors) and change requests (changing requirements) when generating reports.
In our current system, however, we only have a single type of change request and just use a field to indicate whether it is a bug, requirement change, etc (this field can be used to build report queries).
What are the benefits of having a separate workflow for bugs?
I'm also confused by the fact that developers can submit work against a bug or a change request, I thought the intended workflow was for bugs to generate change requests which are what the developer references when making changes.
#Luke
I don't disagree with you, but this difference is typically the explanation given for why there is two different processes available for handling the two types of issues.
I'd say that if the color of the home page was originally designed to be red, and for some reason it is blue, that's easily a quick fix and doesn't need to involve many people or man-hours to do the change. Just check out the file, change the color, check it back in and update the bug.
However, if the color of the home page was designed to be red, and is red, but someone thinks it needs to be blue, that is, to me anyway, a different type of change. For instance, have someone thought about the impact this might have on other parts of the page, like images and logos overlaying the blue background? Could there be borders of things that looks bad? Link underlining is blue, will that show up?
As an example, I am red/green color blind, changing the color of something is, for me, not something I take lightly. There are enough webpages on the web that gives me problems. Just to make a point that even the most trivial change can be nontrivial if you consider everything.
The actual end implementation change is probably much of the same, but to me a change request is a different beast, precisely because it needs to be thought about more to make sure it will work as expected.
A bug, however, is that someone said this is how we're going to do it and then someone did it differently.
A change request is more like but we need to consider this other thing as well... hmm....
There are exceptions of course, but let me take your examples apart.
If the server was designed to handle more than 300,000,000,000 pageviews, then yes, it is a bug that it doesn't. But designing a server to handle that many pageviews is more than just saying our server should handle 300,000,000,000 pageviews, it should contain a very detailed specification for how it can do that, right down to processing time guarantees and disk access average times. If the code is then implemented exactly as designed, and unable to perform as expected, then the question becomes: did we design it incorrectly or did we implement it incorrectly?.
I agree that in this case, wether it is to be considered a design flaw or a implementation flaw depends on the actual reason for why it fails to live up to expectations. For instance, if someone assumed disks were 100x times as fast as they actually are, and this is deemed to be the reason for why the server fails to perform as expected, I'd say this is a design bug, and someone needs to redesign. If the original requirement of that many pageviews is still to be held, a major redesign with more in-memory data and similar might have to be undertaken.
However, if someone has just failed to take into account how raid disks operate and how to correctly benefit from striped media, that's a bug and might not need that big of a change to fix.
Again, there will of course be exceptions.
In any case, the original difference I stated is the one I have found to be true in most cases.
Keep in mind that a part of a Work Item Type definition for TFS is the definition of it's "Workflow" meaning the states the work item can be and the transitions between the states. This can be secured by security role.
So - generally speaking - a "Change Request" would be initiated and approved by someone relatively high up in an organization (someone with "Sponsorship" rights related to spending the resources to make a (possibly very large) change to the system. Ultimately this person would be the one to approve that the change was made successfully.
For a "Bug" however, ANY user of the application should be able to initiate a Bug.
At an organization I implemented TFS at, only Department Heads can be the originators of a "Change Request" - but "Bugs" were created from "Help Desk" tickets (not automated, just through process...)
Generally, though I can't speak for CMM, change requests and bugs are handled and considered differently because they typically refer to different pieces of your application lifecycle.
A bug is a defect in your program implementation. For instance, if you design your program to be able to add two numbers and give the user the sum, a defect would be that it does not handle negative numbers correctly, and thus a bug.
A change request is when you have a design defect. For instance, you might have specifically said that your program should not handle negative numbers. A change request is then filed in order to redesign and thus reimplement that part. The design defect might not be intentional, but could easily be because you just didn't consider that part when you originally designed your program, or new cases that didn't exist at the time when the original design was created have been invented or discovered since.
In other words, a program might operate exactly as designed, but need to be changed. This is a change request.
Typically, fixing a bug is considered a much cheaper action than executing a change request, as the bug was never intended to be part of your program. The design, however, was.
And thus a different workflow might be necessary to handle the two different scenarios. For instance, you might have a different way of confirming and filing bugs than you have for change requests, which might require more work to lay out the consequences of the change.
A bug is something that is broken in a requirement which has already been approved for implementation.
A change request needs to go through a cycle in which the impact and effort has to be estimated for that change, and then it has to be approved for implementation before work on it can begin.
The two are fundamentally different under CMM.
Is my assumption incorrect then that change requests should be generated from bugs? I'm confused because I don't think all bugs should be automatically approved for implementation -- they may be trivial and at least in our case will go through the same review process as a change request before being assigned to a developer.
Implementation always comes from requirement. It may be from product manager, it may be from some of you random thought. It may be documented, it may be from some conversation. In the end of the day, even something as simple as a := a + 1, the "real" implementation would be based on compiler, linker, CPU, etc. which depends on the physical law of real life.
A bug is something that is implemented against the ORIGINAL requirement. Other than that, it is a change request.
If the requirement is changed and the implementation need to be changed as well, it's a change request.
If the dependency has been changed, for example web browser stopped supporting some tags and you need to make some change, it's a change request.
In real word, anything that is not properly documented should be treated as change request. Product manager forgot to put something in the story? Sorry, that's a change request.
All change requests should be properly estimated and pointed. Developers get paid for making change requests, not for making bugs and fixing those made by them.