80

The skill isn't to write software without requirements. It is instead to elicit requirements from the project owner regardless of whether there is a formal requirements documentation or not. Gathering requirements is definitely your first priority, but you don't necessarily need to get all of the customer's needs noted up front. The risk is of course is ...


35

This is very ambiguous … Two things I can say: There are a lot of very gifted technical people whose careers get halted because they wait for perfect requirements. Or they play the, "Sorry, can't do it, wasn't in the requirements." The reality is requirements writing is very difficulty. The precision required for good requirements is unlike anything ...


20

The waterfall model that you are referring to was never intended to be a process model used on a real project. Instead, it is a strawman. It identifies the key phases and activities that exist in software projects and the most basic flow between them. This oversimplification of how to develop software is a flawed one, and it was even presented that way. ...


16

How could it? The very nature of the technique dictates some sort of feedback loop between the customer and the developer. Parts of your team can, however, act as "proxy" customers (a similar process to "eating your own dog food") so that you can "pretend" to be agile, although that won't be as satisfactory as getting actual customer feedback. Like it ...


16

V-model is an extension of Waterfall model, so don't expect it to be hugely different. Basically, you follow V-model from left to right, just like in Waterfall model. In Waterfall, you do requirements, design, implementation, verification and finally maintenance. In the same way, in V-model, you do requirements, design, implementation, verification and ...


14

Waterfall model is a software development process consisting of a sequence of phases (requirements, design, construction, testing, deployment, maintenance), followed from first to last one, without going back and without using iterations (unlike in Agile models). Waterfall model helps modeling project management. Object-oriented model is a representation of ...


12

There is one overarching principle that governs the need to refactor and optimize, both in waterfall and Agile: YAGNI (You Ain't Gonna Need It). A second principle is the corollary of the first: "Premature optimization is the root of all evil", the coding equivalent of the general proverb "the enemy of excellence is perfection". Let's take the priciples and ...


12

Requirements are the steps in the journey, a vision is the direction For many applications a highly detailed technical specification is just too much up front since a quick discussion could render their carefully typeset document useless. Instead, start with a vision. If everyone understands the overall picture then the requirements can get filled in along ...


11

You need management, clients and developers each to understand and support the Agile way of thinking and the Agile methods. In more detail: Management must be comfortable with hearing the truth, as opposed to what they traditionally expect to hear (i.e. "yes, the project is on track" for 11 months... then suddenly "oops, we need to delay the deadline by a ...


11

Traditional (and incorrect) waterfall is a single iteration through the phases of the lifecycle. First, you perform requirements engineering. Using those requirements, you architect and design the system and verify/validate those designs. Then, you implement the system. Once the system is implemented, you test it to ensure it works as intended. Finally, you ...


10

Did you ask the instructor why you had to list all the methods? It is possible that, like with much of what is asked for in a classroom environment, the intention was not to make your class diagrams more helpful to developers but to help you and your classmates think about how you would design your classes. When students are learning how to decompose ...


10

if it works, and has been tested, then why fix it? This may go against your own personal temperament as an engineer/programmer, but if it's working, what business value is there for you to continue refining it? Will it make it easier to maintain over time? If so, then working under the agile methodology, you should be able to create new items in your ...


10

Steve Jobs believed that customers cannot describe exactly what they want the future products to look like, so it is your job to deliver them. So, unless you deliver custom software all the time, forget formal specs and start by creating prototypes and letting the customers play with them and tell you what they think. You have got to put the right person ...


9

No, the instructor is right in telling you to list all the properties and methods upfront if you are using the waterfall method. Wikipedia notes a criticism of waterfall: Many argue the waterfall model is a bad idea in practice—believing it impossible for any non-trivial project to finish a phase of a software product's lifecycle perfectly before ...


9

We use waterfall and have completed lots of projects with changing requirements. Waterfall isn't as bad as it's been made out to be and Agile isn't the silver bullet that fixes everything (as many badly done agile projects as waterfall projects as far as I can see.) Neither methodology has a particularly high success rate, in part because users don't know ...


9

People don't use the text-book waterfall model and probably never have. It is an idealized, theoretical construct whose purpose is to get you to think about the steps in systems development. It's main point is that you want the bigger changes to happen as early as possible, because you'll never have the time or money to make a big change once there's a ...


8

Spiral is a cycling waterfall. Thats the definition of spiral. That's what Boehm and other proposed when they invented it. Even in each Spiral or Agile cycle, there are still step-by-step tasks/objectives that need to be finished... Mostly true. Is the main difference the introduction of a feedback loop into the process of development earlier on and ...


8

The mythical waterfall process that is most often compared against agile never existed and therefore can not be considered dead. Real waterfall processes are still alive and well, and excelling at delivering on time on budget software that meets user expectations.


8

I've been assured that I have complete buy-in from the devs and the business team [...] I have no access to the end users [...] One thing to be quite clear on is the difference between being verbally assured that you "have buy-in", on one hand, and on the other hand the actual commitment from whoever is sponsoring your work. My best advice to you is to set ...


7

You need: People who are willing to be very open and honest. Visibility is everything because you need trust across all sorts of layer-boundaries. Customers and managers who really want to hear the truth. People who are willing and able to redefine their roles to suit what's needed right now. Freedom to change processes that aren't working right now. People ...


7

The short answer to your question is 'no'. Here are comments on some parts of your question. To be accurate most of the answers are based on my personal experience and observation. In my experience, waterfall does not work. Waterfall is a sound methodology for delivering systems of varying complexity. It is unfortunate that it is not well presented or ...


7

Gather better, more specific customer requirements. When you refine the requirements to the point where each requirement can be satisfied with a handful of classes, and you have a pretty good idea what those classes will look like in code, it will become much clearer how long things are going to take, and it will be much easier to declare success on each ...


7

I'm not familiar with NQA-1, but I read the overview for federal project directors that the Department of Energy provides. I also found an IAEA slide deck about NQA-1. From what I can tell, NQA-1 is somewhat similar to other quality management standards that I am familiar with. It tells you that you must do certain things and that you must provide certain ...


6

Definitions will vary so I doubt you will get a conclusive answer to this question. Having said that, the most obvious potential difference I see is how the iterations relate to your high level design / architecture: In an iterative waterfall model, you might use the iterations more for refinement/elaboration of elements of the overall design in multiple ...


6

Typically, a systems requirements specification contains the top-level requirements for a system. A system is a set of software and/or hardware subsystems. Typically, this includes the functional and non-functional (performance, safety, security, quality, business, governance and regulatory, and so on) requirements for the system as a whole. Each subsystem ...


6

If I understand your question, you're interested in SDLC that were before the emergence of the Agile, i.e. not only the agile manifesto 2001, but also the agile methods that were promoted individually by the authors of the manifesto (e.g. XP, Crystal, etc...). SDLC time travelling Before Agile, in late 90's, the most popular SDLC was probably the Unified ...


5

You have said that you want to adopt Agile because it decreases the time-to-market and increases the productivity of your developers, so I'd like to focus on those particular aspects. Time to market In traditional Waterfall products, stakeholders only get one chance to sign up for requirements. In Agile, you can produce a much smaller vision and then add ...


5

Perhaps a better way of asking what you're getting at is, "when is less iterative and more formal better?" There are situations where this is the case: When the requirements won't change. When meeting new requirements is less important than hitting 100% of the original ones. When all the technology components are mature and well understood. In a sense you ...


5

Scrum is a complete project management methodology that addresses all aspects of the project lifecycle. Unlike projects managed using a sequential process where things generally happen once and then are revisited if necessary as the project progresses, Scrum embraces a more iterative approach - everything is addressed during each iteration. Of the list of ...


Only top voted, non community-wiki answers of a minimum length are eligible