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
I'm working on a large project for a university assignment, we're developing an application that is used by a business to compile quotes for their various services.
I need to document the algorithms in a way that the client can sign off on to make sure the way we calculate the prices is correct
So far I've tried using a large flow chart with decisions diamonds like in information systems modelling but it's proving to be overkill for even simple algorithms.
Can anybody please suggest some ways to do this? It needs to be as little like software code as possible, and enough for the client to see how we decide what prices are quoted
Maybe you should then use pseudocode.
Create two documents.
First: The business process model (BPM) that shows the sequence of steps required to be done. This should be annotated with the details for each step.
Second: Create a spreadsheet with each input data item defined so that business can see that you understand the type of field for entry of each data point and the rules for each data point. If the calculation uses a table for the step, then that is where you define the input lookup value from the table. So for each step you know where the data is coming from and then going to. Your spreadsheet can include the link to the BPM so they can walk through each data point in the BPM and see where it is coming from/going to.
You can prepare screen designs to show the users how your system is doing actually.
Well, the usual way to document algorithms is writing papers.
If your clients have studied business, I'm sure they are familiar with reading formulas.
Would a data flow diagrams help? Put psuedo code or math in the bubbles. I've had some success combining data flow models and entity relationship diagrams, but it's non standard.
What about Nassi-Shneiderman-Diagram, it's a diagram from structural programming. I think its good to show decision flows.
http://en.wikipedia.org/wiki/Nassi%E2%80%93Shneiderman_diagram
You could create an algorithm test screen to display and comment on the various steps through the calculations.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
My team have recently gone to sprints and we are going through breaking down our user stories into tasks. What is the best practice in breaking down the user stories?
Should each task include developing, design, testing, and so forth? Or can the tasks be individually broken out? If so, should the tasks that aren't testing related just go straight to done and skip "Verify" or "To Test" column in the workflow?
From what I've read online it seems there is no 'set' way and people do it differently. I'm curious if people have had problems with their way of doing it.
Any help would be useful!
What is the best practice in breaking down the user stories?
Splitting user stories: the hamburger method
Elephant carpaccio
Should each task include developing, design, testing, and so forth?
As you wish. Maybe, you can test feature, not a task. But testing of small peaces (task) is easier, than whole feature (if it possible). BUT sprint product should be tested as well.
+1 for the Elephant Carpaccio :-)
The goal is to understand the power of thin and vertical incremental developments :
Thin : the smallest code is written, the less code have to be changed for future stories
Vertical : each story should change any part of the n-tier
architecture
code (presentation, logic, data), so that each story delivers
immediate business value
I facilitated it and met his creator (Alistair Cockburn). This game/exercise is really interesting for teams facing customers with frequent change needs and small cash funds.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I need to add an item to our product backlog list that has no (perceived) value to the users.
Context: every week we need to parse and import a TXT file our system. Now the provider decided to change the format to XML, so we need to rewrite the parsing engine.
In the end the user won't see any benefit as he'll keep getting his new data, but we still have to do this to keep importing the data.
How to add an item like this to the product backlog list?
What happens if you don't make the change? Is there value to the user in preventing that from happening? If the answer is yes, I'd recommend tying your business value statement to that. Then, you can write a typical user story with business value and treat it like any other PBI.
It has no value to the user, but it has value to your company.
As company X I want to be able to support the new XML format so that I can keep importing data from provider Y.
How does that sound like? Not all stories necessarily evolve around the end user.
Note: technical stories and technical improvement stories are not a good practice and they should avoided. Why? Because you can't prioritize them correctly as they have no estimable value.
The correct way to do tech stories is to include them in the definition of done. For example: decide that every new story played is only complete once database access is via Dapper and not L2S. This is a viable DoD definition and makes sure you can evolve your system appropriately.
We typically just add it as a "technical improvement" and give it a priority that we think fits. If the user asks you about it, you just explain them high level what the change does and why it's needed.
Don't forget that your application will most likely start failing in the future if you don't make the change. Just tell them that, and let them decide whether they want that or not.
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
What's a good way to capture user stories when you have features that are common across multiple UI modes?
For example, imagine a commercial flight information system, something someone might use to answer the question "When is flight UA211 expected to land?"
As is often the case, the feature of providing schedule information is common underlying functionality, even though you might ask for it via a desktop web browser, a mobile browser (where you want to apply different style to make it more usable), and maybe even via SMS shortcodes.
Now, that certainly could be a single user story ("As someone meeting a traveller, I want to see flight arrival information so that I can be at the airport on time"). But that seems wrong (and would probably be an epic story, anyway).
You can make it separate user stories ("As a desktop user...", "As a smartphone user...", etc), which I've done in the past, and the team just knows to estimate the first one to include all of functionality, and the subsequent ones to estimate only UI implementation.
A third option is to make the underlying functionality a story isolated from the presentation layer, and then have UI stories: "As a flight info system front end, I want to get flight status information so that I can present it to the user", "As a desktop user, I want to see flight arrival... etc". But that seems artificial.
Thoughts?
dwh
I think the problem is that you are trying to tie the UI functionality to the backend too tightly.
For example, if you break it into a simple story:
A user may want to know the flight status given the flight number.
OK, now, given that you implement that, now you can look at which platforms will be calling this, as, one part of agile is not to over-develop, but in this case, if you have a business need to support mobile and desktop devices, then you should look at implementing this as a REST service, since that is the simplest solution for both to work with.
So the REST service solves the first story above.
Now, you will find that there are other specifics for each platform. For example, is there something on the phone that may already have the information, for example, did the traveller go to a trip site and already enter his info, then you may want to go there, assuming that the traveller is in the users contacts.
Or, if the user is just going to enter a flight number and that is it, then why not just do it as a webpage, as that is the simplest approach that supports both concepts. Then, if you have a url that supports GET, and outputs as HTML then you can easily display.
So, my first story was too simple, you may want to consider whether it is possible to return different types of data, so a user may want to have HTML, PDF, json or xml, but for each of these there should be a business need.
Unfortunately it is hard to answer your question as there are too many unknowns, which is why you are having a difficult time. If you ask the wrong question then you do have an epic, but if you can just break it down to a few simple stories then it becomes much easier to solve.
I would recommend the second option.
As you suggested, the first sounds like too much for a single story, and a story should always fit into a single iteration.
With the third option, the big problem is that you aren't delivering business value at the end of the story, which is generally a bad practice.
There are other ways you could split this work though. You could initially develop a very cut-down, barebones version which would work across all clients, and then refine each of them in subsequent stories.
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 7 years ago.
Improve this question
I have been thinking about setting up some sort of library for all our internally developed software at my organisation. I would like collect any ideas the good SO folk may have on this topic.
I figure, what is the point in instilling into developers the benefits of writing reusable code, if on the next project the first thing developers do is file -> new due to a lack of knowledge of what code is already out there to be reused.
As an added benefit, I think that just by having a library like this would encourage developers to think more in terms of reusability when writing code
I would like to keep this library as simple as possible, perhaps my only two requirements being:
Search facility
Usable for many types of components: assemblies, web services, etc
I see the basic information required on each asset/component to be:
Name & version
Description / purpose
Dependencies
Would you record any more information?
What would be the best platform for this i.e., wiki, forum, etc?
What would make a software library like this successful vs unsuccessful?
All ideas are greatly appreciated.
Thanks
Edit:
Found these similar questions after posting:
How do you ensure code is reused correctly?
How do you foster the use of shared components in your organization?
Sounds like there is no central repository of code available at your organization. Depending on what you do this could be because of compatmentalization of the knowledge due to security restrictions, the fact that external vendor code is included in some/all of the solutions, or your company has not yet seen the benefits of getting people to reuse, refactor, and evangelize the benefits of such a repository.
The common attributes of solutions I have seen work at mutiple corporations are a multi pronged approach.
Buy in at some level from the management. Usually it's a CTO/CIO that the idea resonates with and they claim it's a good thing and don't give any money to fund it but they won't sand in your way if they are aware that someone is going to champion the idea before they start soliciting code and consolidating it somewhere.
Some list of projects and the collateral available in english. Seen this on wikis, on sharepoint lists, in text files within a source repository. All of them share the common attribute of some sort of front end search server that allows full text over the description of a solution.
Some common share or repository for the binaries and / or code. Oftentimes a large org has different authentication/authorization methods for many different environments and it might not be practical (or possible logistically) to share a single soure repository - don't get hung up on that aspect - just try to get it to the point that there is a well known share/directory/repository that works for your org.
Always make sure there is someone listed as a contact - no one ever takes code and runs it in production without at lest talking to the previous owner of it - and if you don't have a person they can start asking questions of right away then they might just go ahead and hit file->new.
Unsuccessful attributes I've seen?
N submissions per engineer per time period = lots of crap starts making it's way in
No method of rating / feedback. If there is no means to favorite/rate/give some indicator that allows the cream to rise to the top you don't go back to search it often because you weren't able to benefit from everyone else's slogging through the code that wasn't really very good.
Lack of feedback/email link that contacts the author with questions directly into their email.
lack of ability to categorize organically. Every time there is some super rigid hierarchy or category list that was predetermined everything ends up in "other". If you use tags or similar you can avoid it.
Requirement of some design document to accompany it that is of a rigid format the code isn't accepted - no one can ever agree on the "centralized" format of a design doc and no one ever submits when this is required.
Just my thinking.
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 5 years ago.
Improve this question
I'm going to give a two hour workshop on a programming topic (NHibernate). It will be a small group, of around five people. The attendees will all have their own laptops.
What would be the best way to structure the workshop so that the attendees get an insight into the topic and preferrably don't fall asleep?
I don't know if you can get a black-n-white answer here, but definitely there's opinions on how to best engage your audience...
You will probably know your audience much better than I do, so you're in a better place to make this determination. I'll assume your attendees are going to be developers, due to the topic you'll be presenting.
And here's my personal opinion: "what we learn to do, we learn by doing", right? So, go with some hands-on exercise. For instance, look at the NerdDinner tutorial online to see how you can have them 'build' something while exploring the features of NHibernate you wish to expose them to.
I also reccomend making sure one of the exercises is more similar to a 'maintainance' task instead of a 'create from scratch' example since people will eventually spend more time in the former rather than the latter mode. SO perhaps have an exercise or two for them to do from scratch, and then have a prepared 'code base' they'll have to modify.
HTH
Add a few (or just one!) hands-on lab(s) into the mix. You could burn it on CD or whatever, hand it out at the start and they can all load it up and play along and run it. It just means you need to put some effort in, in terms of creating the template project and to ensure they just have to fill in a few things/gaps here and there, and it will run without a problem.
During your presentation you will then have 'Hands-on lab intervals'. Where you go through some of the steps and let the candidates fill in some of the pieces of the puzzle.
That way, you can let them fill in the appropriate gaps that you think are necessary in order to "get" it. And at the same time, it ensures the attendees won't fall asleep, as they actually actively participate.
I think the most important thing to keep in mind is that your attendees are going to have different learning styles. What I would do is create a slide-show or outline that gives the skeleton of the topics you want to cover. Then create the code examples you want to work from based off of the topics. Once that is done create your solution code files to all of the examples you made. Ideally, you will want to give all of the attendees a copy of the material when they show up. This way they have something to following along with and if they get ahead or fall behind they have the material necessary to still learn. Finally, make sure you practice your presentation. When you practice it you won't want it to take the full 2 hours because you will want to leave time for questions. It also could help if you mark on your outline how long it should take you to get to each major point. That way you know if you are staying on pace or not.