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
For a beginner hobbyist, it seems fairly common to create everything in the order it will be viewed by the user, regardless of its importance, and to intertwine back-end and front-end development.
Obviously, this isn't the most efficient method and would probably be avoided by more experienced developers. I've been exploring different ways to order software development, but I'd like to know if there's a standard that's widely accepted or recommended by the industry.
That is what software development processes are for.
Thing is: there are many different processes; thus there are many different answers to your question.
In 2017, most organisations use processes around the "agile" mindset (or they try to get there), thus your first stop could be Agile software development.
And to give a direct answer to your question:
when you start an agile project, you simply don't know about "all the things the user will view"
instead, you collect requirements
you translate requirements into "user stories"
then the development team and the users (or user representatives) decide on the priority of those user stories
and then, during the development iterations (sprints) a subset of the "most important" user stories is implemented
The key part here: requirements and their priorities are subject to change. The idea to collect everything upfront, to then define an order over all items is simply rejected nowadays.
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 1 year ago.
Improve this question
I have to write the "assumptions" part of a pentest report and I am having trouble understanding what I should write. I checked multiple pentest reports (from https://github.com/juliocesarfort/public-pentesting-reports) but none of them had this paragraph. Also I found this explanation "In case there are some assumptions that the pen-tester considers before or during the test, the assumptions need to be clearly shown in the report. Providing the assumption will help the report audiences to understand why penetration testing followed a specific direction.", but still what I do have in mind it is more suited for "attack narative".
Can you provide me a small example (for one action, situation) so I can see exactly how it should be written?
I would think the "assumptions" paragraph and the "Attack narrative" paragraph are somehow overlapping. I would use the "Assumptions" paragraph to state a couple of high level decisions made before starting the attack, with whatever little information the pentester would have on the attack. I would expand on the tools and techniques used in the "Attack narrative" paragraph
For example an assumption could be:
"The pentester is carrying on the exercise against the infrastructure of a soho company with less than 5 people It is common for soho companies to use consumer networking equipment that is usually unsecure, and left configured as defualt. For this reason the attacker focused on scanning for http and ssh using a database of vendors default username and passwords"
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 7 years ago.
Improve this question
I'm currently involved in a scrum project for a small organization.
Some events have led us to believe the organization doesn't understand their role in the scrum process. We've already gone as far as arguing about the size of the development team which, in my opinion, shouldn't be something for them to worry about (negative conclusion to this project has little to no impact on their end and large impact on us).
Learning the lingo as they go, they've asked us if they could see our backlog.
I don't have a ton of experience with scrum but is it wise to show it?
I fear we might get a lot of negative feedback because they don't understand the process all that well.
(Additional context: we are students and this situation is not covered by our classes, our teacher hasn't responded to our e-mails yet.)
Scrum is transparent. Everything the team does is open and visibile to all interested parties. Regular showcases are held to demonstrate completed work and both the sprint and project backlogs are public.
If you are following the Scrum framework then you will have a Product Owner who represents the business and is fully engaged with the team. It is the Product Owners responsibility to engage with stakeholders (i.e. other business users) to explain the contents of the product backlog.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have some software which we added an open common file format (.iwb) to. The government organisation that initiated that work has been cut in the cutbacks.
Now a not for profit organisation has taken up the mantle, however its going to cost and once you pay you are not allowed to reveal the "materials" you gain.
http://www.imsglobal.org/iwbcff/jointheIWBCFFIalliance.cfm
I understand people need to be paid but the whole not sharing thing makes it feel like its going against what a standard is meant for.
What's a good strategy:
Pay up and shut up (there might be plenty of closed standards
that work in this way)
Fork the standard to an organisation that will not require people to pay to read it
Drop the file format
Stay behind the curve and reverse engineer the files
Any standard that is not freely accessible is no standard at all but is instead a proprietary format. I'd say either:
petition them to open the standard up
Drop your support for it (and tell your customers why you have to)
Fork an earlier open version and create a free version of the standard
Paying for access to a standard sounds like a horrible idea because:
It encourages this behavior
It's likely to just be wasted money because others won't want to pay either, and a standard used by no one is not a standard.
Publish the last version you had access to.
Site that you support that version of the standard.
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
We have now installed Agilo to manage our Scrum projects, and we have that proble: we can handle just one backlog. How can we have different backlogs?
Thanks for your time!
Maybe you should try other tools? :)
Here are some other tools you might like to try.
Installable onsite are Rally, Version One. I think Thoughtworks' Mingle is available onsite but they prefer to host it for you.
You may also like to try some of the new online Lean tools: LeanKitKanban, AgileZen.
If possible, get one or more big whiteboards and some post-its, then back it up / produce reports etc. electronically. Excel worked well for this for me. Also there's nothing like the tactile and immediate visual feedback from moving post-its around. You can use index cards and holders or blue-tack if the post-its fall off.
You can also represent the multiple backlogs at different scales; for instance, showing whole features, apps or systems completed at a project or programme level while tracking the smaller stories and tasks at a team level.
Do you have multiple products? There should only be one product backlog for each product - having more than one doesn't make much sense.
To break down a product backlog, it often makes sense to add extra columns to the backlog for different categories within that product. That would make it easier to filter and see different areas of the backlog quickly and efficiently.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
How many people actually write an SDD document before writing a single line of code?
How do you handle large CSCI's?
What standard do you use for SDD content?
What tailoring have you done?
I certainly have. Historically and on recent projects.
Years ago I worked in organisations where templates were everything.
Then I worked other places where the templates were looser or non-existent or didn't fit the projects I was working on.
Now the content of the software design is pretty much governed by what I need to describe to get the idea across to the audience.
"before writing a single line of code" there wouldn't be a a lot of detail. The documents I produce before I start coding are meant to get the idea of what we need to build across to the affected teams and senior management so they introduce high level architecture, functionality, technologies, risks and scope. Those last two are really important. The rest is to show other teams where you need to interface with them and to leave managers with a lingering notion that cool stuff is happening.
Most big software companies have their own practices. For example Motorola has detailed documentation for every aspect of software development process. There are standard templates for each type of documents. Having strict standards allows effectively maintain huge number of documents and integrate it with different tools. Each document obtains tracking number from special document-tracking system. They even have system (last time I seen it was in stage of early development) for automatically requirements tracking - you can say which line of code relate to given requirement\design guideline.
I would suppose that most people who write SDD documents and use terminology like CSCI have to be using a specific software development methodology and most likely are working for some serious government customer. They usually tend to take their preparations quite seriously and the documents are ready and approved before any development starts.
In an Agile process the development and the design document could be developed in parallel. It means that there will be plenty of refactoring to be done but it usually delivers very good results in the end.
In more formal processes (like RUP) a SAD document is mostly created during the elaboration/prototyping phase based on the team research.