implementation before documentation

Question

I am doing a design and build dissertation for my final year.

Everything is more or less good, except I cant find a software methodology to fit my process.

Basically I did the implementation FIRST and then from that I used tools to reverse engineer class diagrams, ERD, etc...

I can blag that I followed the waterfall method or something, but I would rather try to find an actual Software Development Mythology which does the implementation first.

I do know that is REALLY bad and is probably non-existing, however its small project and personal use only.

any helpful suggestions are greatly appreciated.

Answer 1

There is no real process or software model that endorses coding before anything else. Well, technically there is the "Code-like-hell" approach but that is universally condemned (and not actually even a "real" approach in that it's considered a mistake.)

(See #27: http://www.stevemcconnell.com/rdenum.htm)

Most software models and processes exist to bring engineering principles to projects, and coding before planning is not an engineering principle. Granted, it's not necessarily wrong on an incredibly small project to just go ahead and code (most people would do it that way). At the same time, it does not follow any type of process or model that is well-established or almost universally accepted.

Your best options now are to redo it, say you reverse engineered it, or try to fudge it to fit some type of model, but I can't actually endorse doing the last one as it would probably end up just becoming lying.

Answer 2

If you didn't design it first I don't think it will fit in any DESIGN pattern...

Most of the Design patterns are focused on designing it first, to save you the trouble of ending up with a bad software poorly designed.

You can just say you did the design you reversed engineered and followed it, assuming it fits any design pattern.

Answer 3

Read about XP: extreme programming http://www.extremeprogramming.org/

Answer 4

If the project is small enough to excuse doing something you say is "bad," maybe it's small enough to redo in a way that's "right." Just pick a methodology, (re)design your project according to that methodology, then re-code it according to the design. That way you wouldn't have to fudge anything.