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?

  • 1
    You do realize how astoundingly broad your question is as a whole, and how even some of the sub-questions are themselves topics that are covered by complete books (or series of books)? To me, it looks like you need to do a bit more research on your own, including finding out exactly what is expected from you - looks like the scope of what you need to do is very broad, much too much if you need to be asking this question like this here.
    – Mat
    Commented Apr 5, 2016 at 16:05
  • It looks like you have some very specific questions there (each bullet point) within specific parameters I think you need to narrow down your question... maybe focus on one of your bullet points per question, and make the context for your question (CMMI Level 3, QML, C++) clear.
    – Rachel
    Commented Apr 5, 2016 at 21:05

1 Answer 1


Giving your post a quick once over again (I voted to close it first time round), I can see that there are at least 4 areas here:

  • Development paradigm
  • Tooling
  • Checkout/code review policies
  • Documentation

Even if you asked a question about each of these they would still be far too broad to be answered in a concise and readable way.

You do give some specifics (QML, C++) etc but this aside, it boils down to another "how should I program" type question which will (99 times out of a 100) get closed.


Development paradigm

  • Waterfall
  • Mini waterfall
  • Agile
  • Others


  • C++ best practices
  • QML best practices

Checkout/code review policies

  • VCS

  • Static analysis tools

  • Development standards

  • Code review format

  • CI


  • Use of a methodology
  • Generated/outsourced documentation
  • Agile documentation (minimum required)
  • So can you tell me with examples how I should narrow them down? Commented Apr 6, 2016 at 17:05
  • 1
    Not possible - still far too broad. To illustrate I'll break my list down one level further at which point I'll stop - as even here there is nowhere near enough detail to produce a cogent question producing a useful answer. Please bear in mind this is a Q & A site - not a free consultancy service.
    – Robbie Dee
    Commented Apr 6, 2016 at 19:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .