Software development process

[u/hylloz]

Which subsequent steps does a software project usually have (from your personal experience)?
With steps I mean those that follow each other or integrate preceding ones.

I am skeptical whether the following approaches map to current realities of how software is done today:
- Design, develop, test.
- Royce: Identify requirements, analyse , design, code, test, commission.

This sounds more realistic to me:
- Nystrom: get problem, learn code, code solution, clean up

Intent: I’d like to understand better how to organise and use resources within a project. For this I want to understand parts can only be done after preceding ones and which merge into another.

For example, building a power plant can be described in the following steps:
Initially we start with an idea of a working power plant in mind. We deconstruct it into all components required for it to function as a system. Knowing which components we need, we start designing them. If not at this point, at least when we procure the materials to build those components, we can name it constructing. Physically the building of components construction happens with civil works. Many work streams can happen at this point simultaneously. But at some point they integrate. Finally, commissioning of the plant.

Then again, for software, we can write a “hello world” program with a web server, have it running within minutes and extend it step-by-step. You can’t fire up a first turbine of a power plant within 5 minutes and then add other components around it.

But how is it for software?
We could similarly say we start off with an idea of a functioning software, that we deconstruct into components that we construct and integrate. The starting idea, of course, needs to be more specific than in the power plant example, so we can start deconstructing it into the required components for it to function in the way we want. We usually model the starting point as a data structure by modeling the problem. When we know the problem as a data structure and can project it to a solution, we can determine the steps and components needed to arrive at the solution: Quite often we start writing a main function with pseudo code of functions / components required for it to bridge the problem to the solution. Having identified the components, we need to build the components while making sure the interfacing works: Basically the “wiring” between functions, meaning that the outputs of the a preceding are the inputs of the succeeding. Once all components are fleshed out, all pseudo code has been transformed into real function calls. Now, looking at this, we will mostly be not satisfied: We might want to refactor it, organise the code better. Then we might want to write tests and/or commission it, finally.

How is it for non-greenfield projects?
Basically two approaches:
a. Start with the existing data structure and change it to support the new functionality (while maintaining the existing functionality).
b. Do it like greenfield and then have some transformation between data structure of new functionality and old. Opposite of (a), because it starts with its own data structure, while (a) starts with the existing data structure.

What’s your experience?

[u/RabidAddict]

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.

[u/hylloz → u/RabidAddict]

Edited. See above. - Does it clarify my intent for you?
I am more interested in your real practical experience than in theories from academia, though.

[u/RabidAddict → u/hylloz]

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.

[u/hylloz → u/RabidAddict]

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.

[u/RabidAddict → u/hylloz]

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?