29
I was reading the answers to the question When to use Waterfall and when to use Scrum? and came across something cited by the user utluiz which left me with doubt, which is the sequence of software development:
Requirement > Analysis > Design > Implementation > Testing > Integration
I would like an explanation regarding each step of this sequence and what is the purpose of each of the steps?
35
We have a problem! And we need a solution.
18
Each of these steps tries to isolate part of the problem, sometimes this division is not very clear.
Requirement: At this stage the development team has the first contact with the problem and the scenario. The stakeholders briefly tell what is the problem or objective of the project. At this moment a documentation is made (preliminary).
Analysis: After having done a study on the problem the development team elaborates a solution that goes from the creation of a process or implantation of equipment. A documentation is written describing how the problem will be solved. The text should be clear for both development and stackholders this is a conference that everyone has correctly understood the problem and business rules.
Design: Based on the documents generated in the analysis it is possible to define which technologies will be used, which architecture, which type of software (web, desktop, mobile, embedded etc). This choice may suffer interference from the customer’s environment that restricts the range of possibilities.
Implementation: Here yes starts coding, business rules are adapted to machine language.
Tests: There are various types of tests (unit, integration etc) here are made the accepting which basically checks that the software behaves according to the documentation.
Integration: After the software is finished and packaged it is placed in the client’s production environment, at that stage configurations, database migrations and other types of tasks are performed. There is also the problem of part (or all) of the software not working in the client due to the tests made with simulated external resources and not the real ones so an adaptation is made.
+1! Only one however: integration tests can happen in a scenario that replica production, however without interfering in the real environment - usually called staging area.
+1! First time q see the term stakeholders what it means?
@cat Project participants who define or validate the requirements but this does not mean that they will be obligatorily end users, are the most 'interested'. Sometimes they act throughout the project or in a specific part.
complementing @rray’s response, stakeholders can be, for example, customers, business owners, competitors, employees... anyone who has an interest - positive or negative - in the project.
11
As the term says, it is what is required, what is desired to be done. For example, a customer needs an online chat app and looks for a development company to implement it. At this stage, it is set what the application should fulfill, which the functionalities main, what will be the end users, possible restrictions (as for example, in this case, that there should be no delays in sending messages). All this is agreed between the client and the company, and can be from something more informal as a conversation, to a Requirements Document (example).
That stage is extremely important, since, if the customer says he wants one thing and the development team understands another, it will be as if the customer requests a screwdriver and ends up receiving a hammer. It may sound stupid but it really happens, because many times not even the client knows exactly what he wants, and then when the project is almost ready can see and say "oops, but I didn’t want any of this, do it again". And nobody wants that, right?
This famous image portrays the idea a little:
Possession of the established requirements, the team analyzes what should be done and the focus now becomes as will be done:
and so on
Just like the requirements, it’s important that everyone understands what must be done and now, how it should be done, So you also have a document or some other form of communication that makes that clear to the whole team. This prevents, for example, two developers from taking the same thing to implement. A very famous and important (and easily understandable) concept in Software Engineering is commonly expressed by the graph below:
Which means "the longer it takes to change something, the more expensive it will cost". To understand this just think about how much it costs to keep a team working on something, for after a while you arrive and "oops, we’ll have to throw it away and do it again". Having to pay salary again and other costs involved, which could be being employed in other projects.
Defining the issues most related to project management, it is time to think about which technologies will be used, such as programming language, which platform the program will be used on (Windows, Linux, Android, multiplatform). In addition, the main structures and routines of the program can be defined, such as the creation of a certain table in the database, a function to log in with Facebook etc.
Finally it’s time to get down to business, the time when the structures and routines mentioned above should be implemented, that the functionalities described at a high level should actually be translated into the code.
After implementation, it is not guaranteed that the product is 100% OK, working properly, without any problem. In fact, it’s practically impossible not to have none bug. The more complex the system, the harder it is to ensure and the harder it is to identify as well.
This is where the tests come in: they are an attempt to search for possible problems, exhaustively (as much as possible), until a minimum of reliability can be guaranteed to the customer (of course this reliability depends a lot on the type of product). There are many types and techniques of Testing, and this has become an important sub-area of Software Engineering. There are people within the team who specialize in testing software. I won’t go into details but the image gives an idea (who is interested just search by the terms).
It is the moment when the product produced is delivered to the customer and is put into production, actually running. In our example, it’s like when the app is published in the Play Store and released. At that moment there may be problems, as the famous "in my machine works" but in the customer’s. And then this is being adjusted.
I would like to add the maintenance step that was not mentioned but is a constant in any project. As it is difficult to define all possible problems with the tests, it is possible that the product is delivered and then problems arise that must be fixed, or even a possible improvement can be implemented. It is worth looking again at the graph of change cost x time above: fixing something in a maintenance is much more expensive than solving the problem before.
Finally, this cascade system has problems because it is more plastered, it was used a lot in the past, but today it uses more and more agile methodologies like Scrum, in which these steps are more flexible and not strictly linear.
Browser other questions tagged project-management methodology
You are not signed in. Login or sign up in order to post.
Simple and practical response, addressing all necessary. + 1 :)
– Luiz Felipe