Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Recently I've been assigned a bug to fix, which from my point of view, was actually a change request. After some investigation it turned out that this bug was caused by a defect in business requirements, but it was still considered as a bug.
I often see change requests being pushed forward masqueraded as bugs. I am just trying to figure out if there are any differences.
A "bug in requirements" means there was something wrong with how the functionality was originally designed.
A "change request" means that everything was defined correct, but the customer wants a piece of functionality changed/added.
It happens all the time.
We as developers generally get annoyed if we get our things thrown back at us as having bugs to fix where it wasn't our fault.
What to do depends on the situation and on the process. Unless you get your performance reviews damaged by those, just don't think of those much and implement those bugs/changes.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
So, I working on a problem at my workplace, that is a big company with a serious CNC shopfloor. Here I thought I could make the life much easier with a little software. I have the conception, I put a lot of work in it together with my helpful friends and here is the point, when I suppose to explain it to my leaders.
The problem is, I've never made anything like this before. So I don't know the way. I should use UML-diagrams and use cases, class diagrams etc? Or which is a preferred way?
Out of the management perspective you could explain why your programm is efficient and required to optimise the workflow. Creating a presentation could help you make the idea of the application clear and bring it in a form which is understandable.
If I were you I will go in priorities for activities diagram. You create an activity diagram of the old flow and another with the new flow. You show both to your manager and you compare them. Normally your program will minimise steps inside the new flow. Then you can say that with less steps to manage there will be more money to earn for your manager and you at the end :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've witnessed a number of debates regarding this question, and have seen a few inconclusive discussions online as well. The debate just sparked up between students in my Software Architecture and Design course, and I'd like to hear some thoughts from a more knowledgeable perspective.
So my question is simple: Should "logging in" be considered a use case? Is there a definitive answer to this, or is it something that will always welcome debate?
Although I think that here is not a good space for debate, because of the site format and rules, I think this is a valid question. At first I wondered why not considering logging in as a use case. So, I google it and found that enlightening discussion. Now it is clear to me. There is no easy answer. It also depends on the level of the use case modelling. At the requirement eliciting, logging in is not a use case, but at the system design level it might appear as a use case . If security is a concern, it must appear and be treated as a special use case.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
So I've read some reports about both of these methods but I can't really grasp the dif between the two.
If anyone could sum it up for me or try to explain it I'd be ever so grateful!
BR, Fredrik
Similar to a car. If you test it, you usually drive it around or at least turn it on. If you inspect it usually you check fluids, maybe pull a spark plug, connect it to a computer and check its settings, fiddle with buttons and switches to make sure there is connectivity. During an inspection you may test the vehicle, but during a test you do not always inspect the vehicle.
Software testing is useful because it allows for a mock up of a production environment to be used in order to see if there are bugs, or errors which either throw exceptions or cause logical errors such as making relationships out of state.
Software inspection is more involved. It can involve testing, but can also involve doing code review to make sure that efficient process is used, and that the readability and maintainability is proper. It helps to make sure that features are properly decoupled, the program is running as fast as possible, and that nothing is going on behind the scenes which is undesirable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
CRC cards are known as one of the simple, intuitive method
to simulate your system before creating it.
Many people praises its goodness with a few of criticism
but I could not find well, solid examples about its actual usage
or good case studies.
YouTube only provides two direct examples how CRC methods
are used - both of them are played in not american, even the
creators of the method are two great american ^^.
How funny?
So here I want to know how many people actually uses CRC in design session?
Is it still valid or great? Is it worth to investigate, practice and put in many hours?
My guess is that this is largely replaced by UML. Never heard of anyone using CRC, but then again I'm more in the web than corporate development..
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on quite complicated project, in terms of business-logic quantity and quantity of components.
Each developer mostly works on "his own" component. I understand that this isn't very cross-functional, but it is impossible to know every components' details.
Team sostav changes from time to time. So we have situations when one person have to work on "other person's component". And this can be on periodic basement, so you can come back to the issue a month later - in that moments you can ask component business-logic's owner the same questions again and again, because you simply can forget some tiny but important details a month later.
This situation is annoying sometimes.
We have daily stand-up meetings, when person tells about what he has done and going to do.
We have project's wiki F.A.Q. page - we extract the most frequently asked questions.
What do you think about the problem?
And how would you recommend us to solve it?
given the component nature I'd go with:
1.) A framework document specifying the applications purpose, setup, requirements etc.
2.) Module documents for each component in a common format and indexed by name.
Look at the http://docs.python.org for a good example of general docs and http://docs.python.org/modindex.html for a good example of module/component docs
Oh, and daily meetings are generally bad, they take up a lot of time and answers get forgotten. Newcomers or sick people miss the meetings and have to be re-briefed. It's 100x better to write it all down and keep a paper/email trail unless discussion/feedback is required.