Forgotten design phase
Now, in almost every article about web 2.0 and startups, among the recommendations you can see the advice: give up long thoughts and pre-project documentation - make a project! And very often this advice is taken literally, the first lines of the code appear even before the idea is finally formed. What is the result? As a result, the core of the system for the entire period of development is rewritten 15 times, not to mention the front end. As a result, the project that was conceived as a 1-2x month is stretched for half a year - a year. And the code turns into a bunch of bugs.
What to do to avoid it and not to do planning for half a year?
I admit honestly, I attacked this rake many times. Many projects died due to inadequate or poor quality training. And it would have continued like this if one day I hadn’t met the simple thing “Standards for the development of software projects”. Those who worked in large software companies have probably heard or used this or that methodology or standard.
I imagine in advance the disgruntled faces of some people, saying that this is an extra bureaucracy, no good. Fortunately, this is not the case. Indeed, many standards are quite extensive and describe a huge number of unnecessary things in a particular project. But that's what it is and the standard to build its own on its basis. It is necessary to choose only those parts that are really necessary.
')
Why use standards? First, in order to describe who in the team is doing what. In order to avoid a situation that somewhere in the middle of a project, one of the participants says that he will not have something to do with it. He did not promise or does not know how. Secondly, to determine exactly what you want to get in the end. It is necessary to make a list of requirements for the final result. Otherwise, how will you determine the quality of the output? Thirdly, in order to avoid the situation that both programmers simultaneously develop a class, one loads its version into the repository, after some time the other loads its own replacing the previous one, you need to determine how you will update the code, set the rules.
Try to document your project at least to a minimum and I think you yourself will begin to better understand what you are doing.
Enough of descriptions let's move on to practice. Divide the whole project into several parts.
Initialization - here you discuss what you roughly want to receive, exchange thoughts.
Design - this is the stage that is forgotten. About her in more detail below.
Coding - I hope everything is clear :)
Testing - But this stage without design does not happen, if you do not know what you wanted to get, how do you check what you got?
Integration - we start the project.
Now more about the design.
In the case of a small team, I do not propose to use some kind of super fancy software. Let's just limit ourselves to the wiki. I chose DokuWiki for myself, you can use any other. We will use the IEEE standards for project management, although we will not follow it literally.
The first document we need is SPMP (Software project management plan) aka “Program Management Plan”. Here we will indicate who for what in the project is responsible, how the management will take place, what methods you will use. For those who need specific examples at the end I will give a few references.
Next, we need SRS (Software Requirements Specification), also known as the Software Requirements Specification. This is a very important document, here all the functions that should be implemented in the system are described. Requirements for the interface, as well as use cases. Draw the structure of your site, create a prototype. By prototype, I do not mean something really working. The prototype is an outline of the user interface. You can use for example MS Visio. I would recommend to always make a prototype of the front end, even if it seems that everything is simple. If it is simple - it will take 5 minutes, but what if you forgot something? There is no talk about graphic design or something like that. Just buttons, forms and input fields, as well as their practical location on the page is not of any importance now.
Now let's move on to SCMP (Software configuration management plan), also known as the Software Configuration Management Plan. Here I rarely adhere to the standard, but still a document is necessary. It describes what software you use when developing, how versions are ordered. How are assemblies, etc.
Finally, SDD (Software Design description), also known as design dock. Armed with the list of requirements described in SRS, we begin to design our system. We describe the project architecture, main packages and classes. The degree of detail of the descriptions is determined individually.
That's all, not so much as it seemed. From personal practice: the section in the SRS wiki can be used as a requirements management system. Simply assign each function its number, status and priority. Do not create yourself problems with excess software.
Now a couple of links:
Documentation for Open Source MOORPG Ireon - a practical example of filling out some documents.
SPMP (eng) here
Original
If desired, all standards are Google.
What to do to avoid it and not to do planning for half a year?
I admit honestly, I attacked this rake many times. Many projects died due to inadequate or poor quality training. And it would have continued like this if one day I hadn’t met the simple thing “Standards for the development of software projects”. Those who worked in large software companies have probably heard or used this or that methodology or standard.
I imagine in advance the disgruntled faces of some people, saying that this is an extra bureaucracy, no good. Fortunately, this is not the case. Indeed, many standards are quite extensive and describe a huge number of unnecessary things in a particular project. But that's what it is and the standard to build its own on its basis. It is necessary to choose only those parts that are really necessary.
')
Why use standards? First, in order to describe who in the team is doing what. In order to avoid a situation that somewhere in the middle of a project, one of the participants says that he will not have something to do with it. He did not promise or does not know how. Secondly, to determine exactly what you want to get in the end. It is necessary to make a list of requirements for the final result. Otherwise, how will you determine the quality of the output? Thirdly, in order to avoid the situation that both programmers simultaneously develop a class, one loads its version into the repository, after some time the other loads its own replacing the previous one, you need to determine how you will update the code, set the rules.
Try to document your project at least to a minimum and I think you yourself will begin to better understand what you are doing.
Enough of descriptions let's move on to practice. Divide the whole project into several parts.
Initialization - here you discuss what you roughly want to receive, exchange thoughts.
Design - this is the stage that is forgotten. About her in more detail below.
Coding - I hope everything is clear :)
Testing - But this stage without design does not happen, if you do not know what you wanted to get, how do you check what you got?
Integration - we start the project.
Now more about the design.
In the case of a small team, I do not propose to use some kind of super fancy software. Let's just limit ourselves to the wiki. I chose DokuWiki for myself, you can use any other. We will use the IEEE standards for project management, although we will not follow it literally.
The first document we need is SPMP (Software project management plan) aka “Program Management Plan”. Here we will indicate who for what in the project is responsible, how the management will take place, what methods you will use. For those who need specific examples at the end I will give a few references.
Next, we need SRS (Software Requirements Specification), also known as the Software Requirements Specification. This is a very important document, here all the functions that should be implemented in the system are described. Requirements for the interface, as well as use cases. Draw the structure of your site, create a prototype. By prototype, I do not mean something really working. The prototype is an outline of the user interface. You can use for example MS Visio. I would recommend to always make a prototype of the front end, even if it seems that everything is simple. If it is simple - it will take 5 minutes, but what if you forgot something? There is no talk about graphic design or something like that. Just buttons, forms and input fields, as well as their practical location on the page is not of any importance now.
Now let's move on to SCMP (Software configuration management plan), also known as the Software Configuration Management Plan. Here I rarely adhere to the standard, but still a document is necessary. It describes what software you use when developing, how versions are ordered. How are assemblies, etc.
Finally, SDD (Software Design description), also known as design dock. Armed with the list of requirements described in SRS, we begin to design our system. We describe the project architecture, main packages and classes. The degree of detail of the descriptions is determined individually.
That's all, not so much as it seemed. From personal practice: the section in the SRS wiki can be used as a requirements management system. Simply assign each function its number, status and priority. Do not create yourself problems with excess software.
Now a couple of links:
Documentation for Open Source MOORPG Ireon - a practical example of filling out some documents.
SPMP (eng) here
Original
If desired, all standards are Google.
Source: https://habr.com/ru/post/13480/
All Articles