How does professional software development work?

Customer has problem

Problem / task is analyzed

Task is not covered by finished solutions or only partially?

Specification/specification is created and between technicians, users, etc.verifies whether it covers everything required, constraints, interfaces to other components, old systems, etc. are in it

The scope, time and cost should already be predictable (even if the majority of projects exceed them)

Platform and programming ecosystem (to put it this way) is selected, unless specified by constraints

Subtasks are split, prototypes or mockups are created, test data is collected, or created

Prototypes for neuralgic parts to improve the feasibility (performance, capacity, scalability, basic function) of previously unimplemented or unpredictable subtasks

Programmers (“coding monkeys”) implement their subtasks, approach top-down or bottom-up or code skeleton by generators (UML-based development with OOP/OOAD) possible, vertical or horizontal prototypes/parts, initially certain parts as dummy or with minimal funtkion circumference can be mounted

Tester and depending on the phase of the customer check the progress -> Alpha phase

Tests are refined, systematized and automated, depending on requirements black-box, white-box, full-coverage, random entries and on the edge of the specification (defined behavior in extreme cases), depending on tools for certain types of errors (e.g. for C memory leaks, code linter, initially higher debug level and fewer compiler optimizations)

often a production and one or more test system is operated in parallel, so that testers and programmers do not get in the way.Here, the automatic roll-out is used by modern ecosystems to quickly create specific test cases/situations (tests must be reproducible)

Performance tests to address case-by-case optimizations at a higher level (than compilers and bilbliotheques)

at some point the functionality and stability (both technically and with regard to the test series) is given to the extent that a work is considered useful with it + in order to let real-world experiences flow back and ev. to take over old data sets

Ev.burn-in-test especially if no gentle pan/initial parallel operation is planned from old to new system -> Deployment

Any errors or missing functions are added or corrected

These are roughly the steps that are required, whereby more or less finished specifications can be directly from the customer.The cycle between Specification/Supplements – Coding – Testing – Feedback may vary depending on the process model (waterfall model, V, extreme programming, agile method, etc.) and the circumstances and schedules.

At the same time, documentation should be created (*g*) and a maintenance contract for long-term troubleshooting (*hahaha*)

Thumb rules quantify the proportions of specification, coding and testing rather direction 1/3 each, practically many projects get bogged down due to poor specifications (customer basically has no idea what he needs and comes with constant changes) and unclean Coding methods mainly in the middle part and when it gets scarce, one shortens the testing (“it compiles – let’s ship it”), docu is anyway a matter of luck

Experienced companies and teams try to adhere to the methodology and then have to argue the more realistic costs and time required to the customer during the offer, usually laboriously.

Leave a Reply