New answers tagged

2

The design phases decides the architecture of the system (including the software architecture). Emphasis goes into identifying components and their interactions, and also on identifying entities and their attributes and relationships. Which is all very abstract. Remember that the design should come from requirements. By the way, tests come from requirements ...


1

The only way you will get a good read on how design affects the final product is to design a product and then build it. Otherwise, this is all just theoretical musings. I can tell you with a high degree of confidence, however, that the design phase does, in fact, profoundly affect the final product, including "what it looks like." How could it be otherwise?...


0

Chicken meet Egg, Egg meet Chicken. Any plan you develop without understanding the requirements will be a poor plan by nature. It has no hope of being that grand well developed plan where the unicorns frolic, rainbows end, and nothing is out of place. It will however beat the pants off no plan. Because with no plan, how will you choose your next action? ...


1

Requirements can appear, change or disappear at any moment during the life of the software. It is worth noting that the life of the software is not the same as the life of the software development project. The life of the software begins as a concept. An idea is somebody's head. This idea, may or may not come from a problem or a necessity. And while it is ...


-1

It is not stupid, it is shameless. You sell an optimistic planning to your client. He accepts your offer and you start working. You do not make the target of course but you can show something that provides enough hope to your client to cling to. Something that will make him understand that starting over with a competitor will surely take longer still than ...


1

Requirements come in many forms. Regardless of what the project requirements are the company may have requirements about time and staffing that don’t change just because project needs get in the way. It can seem unreasonable but leaving company needs unmet can leave you without a company. A lot of the dark magic here is finding a way to match up both ...


4

Both. The idea of "planning" as a step you do once in your project and never afterwards is pretty unrealistic. Planning is something you will do before requirements analysis (for exactly this step), you will do it afterwards, you will do it again whenever you reach a certain milestone in your projects and maybe between milestones. Don't take models of the ...


2

Scheduled releases are good for planning. Say you have an eCommerce site and the big boss has asked for a new feature "size charts" The Big Boss will be telling investors that the new "size chart" feature will make the company more valuable, they should invest more! The investors will want to, know when it will be done, the marketing dept will be producing ...


1

In the original paper of Boehm about the spiral model, he explains that the prototyping is meant for "building twice", a principle suggested by Royce in his paper about improving the waterfall approach. Applied to a requirement analysis, the prototype can be as simple as a first mock, to explain and discuss the first ideas with the stakeholders. This is ...


3

Well, the only real values I can think of would be that your stakeholders know when to expect a new release and you have to ensure some development discipline to get things done before a certain release date is hit. Your stakeholders cannot know when a sizable effort has been completed, they won't have enough insight to know and probably don't really care ...


0

Instead of wikipedia and the original article from Boehm, I propose you a quote from an article about a NASA case study in using the spiral model of software development: The spiral model of software development offers a flexible, risk-driven approach to developing software that can often match the reality of a project better than document-driven models ...


Top 50 recent answers are included