This was the question: https://softwareengineering.stackexchange.com/questions/314767/what-do-i-need-to-know-to-ensure-that-me-and-other-people-in-the-team-are-writin?noredirect=1#comment665520_314767
I have been told to ensure that me and everyone else in the team is
writing a quality software, and is following a proper process of creating a software.I have been told to ensure that our software does follow CMMI level 3 to some extent.
I want to know what I need to know and do about all this.
Many years back I did read about the Waterfall model etc. where it is ? said that we have to follow a sequence i.e. requirement gathering, making design, then writing code, and then testing. Here I want to know what excatly am I supposed to do w.r.t same?
Making SRS is of course necessary at the start of the project, but I want to know when (at which point of the project) should I enforce class diagrams, data flow diagrams, and flow charts?
Are all these diagrams absolutely necessary all the time or are there some factors on the basis of which I should decide whether I should force them to draw data flow diagrams and not flow charts, or vice versa?
We usually program in Qml and C++. We use Qml to build GUIs and it does not have classes like C++. How should I ensure that everyone is following some design pattern rather then dumping all the code in one file in QML? Is it really practical for me to do it? I guess that will require that I read everyone's code, understand what they are doing and ponder upon it for a long time(?) Can I ensure that they do it someway?
I have been told to checkout codes of different people working on different projects from GIT and then verify using some tools as Lint whether they are writing proper code or not. What options other than Lint are available for the same?
What method should I follow to tell other people that you haven't followed this and that so you should correct it, and how do I keep a tract of what they have done or not done?
Documentation: Ours is a culture where finishing work is important and documenting that work is not considered that important. Many senior people of our company left without any considerable documentation. I want to change this. What should be included in the average level documentation that I can force every team member to write? I cannot expect them to write extensive documentation, they won't do it, and manager is simply not going to force them.
Please consider answering keeping QML and C++ in mind.
I will remove the sentence asking fr software recommendation.
I have been told:
Too many questions is the main reason here, but several of these subquestions are themselves too broad or unspecified to be usefully answerable (and one is a tool recommendation which is off-topic). I'm not sure what part of this would be best to focus on since there's just so much stuff here,...
Which questions should I separate in independent threads, and how should I improve the questions?
