New answers tagged

0

a) The design is correct and consistent with and traceable to requirements. Traceability is achieved by formally documenting the relationships between the various individual system requirements and the individual design elements. Both upstream and downstream relationships need to be captured and documented for bi-directional traceability. c) ...


3

What you have there is version control. I think we can all agree that it is a pretty crappy form of version control, but you at least do have different versions, even if you don't have commit messages. Why throw away that history? From what I can gather from your description, it's a three-line script and a matter of minutes to import that history into a ...


2

If you only have to update/patch/support a single version, then just starting the repository with your last version is a perfectly good idea. Keep a backup of the old versions, just in case, but I'd expect it to be unlikely you'll need it. However, if you have to support multiple versions of your project, I would recommend making a commit per each of the ...


6

I'd say, do not bother with the old snapshots. Commit current state into the repo and start using it as soon as possible. Just backup the old snapshots and in a couple of month you will not even remember they've existed. From experience, when we migrated from CVS to GIT, the old CVS source control was left there for reference, but after a few month nobody ...


0

This is a very common problem, no matter how fast a project is advancing on technical terms the client perceives it as going much much slower and feels free to change requirements as they like thinking that the developers must not be doing much anyway. This flawed perception comes from three major development tasks that consume time and will never be ...



Top 50 recent answers are included