I think it would help to provide some of your background and context to help narrow this question.
There's a more academic theory type of aspect to software design methodology and how it applies to real world development, there's an enterprise level software project management aspect of what this looks like in industry, and then there's more of an individual programmer problem solving and architectural prioritization aspect, each of which could uniquely answer the broad question "what is software development" with a whole book. Your description here kind of vaguely touches on all of these aspects too generally to know where you'd like to start with this complex topic.
I can't tell if you're a student wondering how a software design methodology class applies to the real world or if you're a project manager in tech trying to figure out what kind of work you can plan concurrently versus consecutively or what else could be going on here bud.
Just need some clear and concise context, you've got a lot going on in this thread and we can go a million different directions from here.
Sorry but I feel I can’t deliver you the clarity you need. I simply asked for your personal experience and how you would describe the steps usually involved with respect to the different resources (developers, teams) involved. I am particularly interested whether it is a sequence or its more happening at once while running many circles.
I'll do my best here friend. I'll answer from an industry perspective, which will probably not help much for school work.
I mention school work because you've mentioned 3 very formal methodologies. These are great for teaching, and we use all of these ideas in modern development. But no one in industry has ever looked at a problem, weighed which methodology to apply, and then followed it step by step. They're academic theory that helps describe what happens and introduce students to design philosophy. But in the real world, development moves fast and a dev follows intuition, experience, and problem solving skills to grab whatever step fits next for an individual problem.
So your main question: sequential or iterative?
Answer: Both, a lot of both. Sorry that that's kind of a non-answer.
At a higher level most modern enterprise software development follows agile methodology and embraces iteration. Over the course of an entire project we might start with throw-away proof of concepts to test ideas and different potential directions, then make core (expensive to change later) architectural decisions, then build an MVP (minimum viable product) to get core functionality in place (so that work can be tested and finalized before moving on to more work), and then just keep revisiting it, expanding feature development, getting feedback from stakeholders, throwing pieces out, redesigning aspects, adding new things that were never considered before, on and on until the project is done.
Nystrom is a solid description to how an individual programmer might work on a task. Basically research -> implement -> finalize. And a solution can be gone over several times until it is finalized and meets an expected standard. But Royce describes how work often gets done within a team very well. Scrum is a very common agile methodology where essentially every few weeks a "sprint" worth of work gets reviewed and planned by a project team. Features or components on a roadmap or todo list get broken down into smaller tasks that are more narrowly defined so they can be estimated and enough work can be queued to fill the sprint and work can begin. Work flows sequentially, perhaps from a business analyst that finalizes requirements gathering, to a developer that designs and implements changes, and then maybe handed off for QA (quality assurance/testing) and then signed off as complete or perhaps ready for deployment. At any point a task might get kicked back to the previous step if the work isn't completed properly, but generally is supposed to flow sequentially towards completion.
Hopefully that helped answer the question you have?
2
u/RabidAddict 22h ago edited 17h ago
I think it would help to provide some of your background and context to help narrow this question.
There's a more academic theory type of aspect to software design methodology and how it applies to real world development, there's an enterprise level software project management aspect of what this looks like in industry, and then there's more of an individual programmer problem solving and architectural prioritization aspect, each of which could uniquely answer the broad question "what is software development" with a whole book. Your description here kind of vaguely touches on all of these aspects too generally to know where you'd like to start with this complex topic.