A project from start to finish

L.Jenkins

I'm just wondering, has anybody been responsible for a project within an organisation from start to finish? It's my first experience of taking over a project, from requirements gather, doing up a design document with functional requirements, development, testing, documentation and ongoing support. I'm currently responsible for everything from the System Architecture to the language it will be written in.

Manach

Not at the start but at the end. When the product was been wound up, but some code fixes/support had to be delivered to the customer as per contract which turned out to rather a long period. Being someone rather comfortable with one core set of tenets having to constantly multiple task and context switch was a challenge.
For requirements, I'd recommend the text Mastering the Requirements Process by Robertson to gain traction and focus on what the customer actually wants.

L.Jenkins

I'll look into it. Have never had a project to completion, so I'll have a steep learning curve.

Aswerty

Every job I've had so far has been a start to finish greenfield project. My problem is not having enough experience working on applications in the middle of their life cycle.

One thing about a project like this is that you need to get as comfortable with the process you are automating as the people who are currently involved in the manual (or less automated) process. This means asking a million questions. It means making them think about why they do the things they do – often existing procedures fell into place without clear thought put into them. This means that the application you build might not only automate the business process but improve it. This is effectively the Domain Driven Design approach.

What you need from your customer (who might be an internal manager or something like that) is a requirement specification. Now chances are they won't actually bother writing this up; so you'll have to extract the information from them and do it up yourself. This specification should not mention technologies, it is just a list of business requirements the software should be able to meet. This would include things like:

• notify a manager when a change is made
• allow files to be uploaded and viewed by other users
• track tasks put on the system throughout their life cycle
• send emails to customers when tasks are completed

With a requirement specification it is important to put everything they want into it. Once the specification is completed you can then look at what can go into the first version of the software. Often you can get away with an initial release that only has 20% of the functionality as per the 80:20 rule.

When you have a requirement specification at that point you can look at creating a functional specification. This is effectively a document that describes what function of the application will meet each business requirement. Note that you still shouldn't be mentioning any technologies at this point. Once this specification is done up you should be in a position where you know the process back to front. If you don't ask another million questions! With the completion of this document you have the feature that your software will be comprised of.

At this point you have undertaken the most important part of the project. Mistakes made on these tasks can result in significant pain or failure in the later stages.

Beyond the above you can do a design specification. If you are the only person on the project this can be pretty high level as in just saying what technologies will be used to implement what features and the general architecture of the application. For more involved projects you'd have to go into greater detail and maybe even into detailed design of specific features and start doing up UML and all that. For a one man project that shouldn't be necessary.

Finally the first stage of development is the database. As usual this is by far the most important aspect of building the system. Your data structures will dictate how your business logic is implemented. If the database design is poor you business logic will turn into spaghetti. When designing your schema you need to realise you are literally mapping the business process into a relational data structure. When doing the database design if your gut says that seems like a bit of a messy relationship – it probably is. Stop and review what you are doing and try find a saner approach because otherwise you are punting the problem into a later stage of the application development.

Beyond the database design the rest of the application is easy. You've done all the hard work and now you get to implement it.

As you might realise from the above I've hardly touched on the coding aspect of such a project. This is because I expect this is the aspect of it that you know. The role you currently have requires you to be a competent business analyst and project manager. So you are effectively wearing two hats at the first half of the project: BA and PM, and at the second half of the project you are wearing the developer and PM hats.

Hopefully I haven't rambled to much and this is of some use to you. I'd also just finally point out that a PM and business analyst don't have the luxury of sitting at the computer all day. They are out and about talking to (and annoying) people to get the information they need and getting things moving so things aren't being held up needlessly.

These kinds of project really improve you as an engineer. So jump in head first even though it's scary. And ask for help if things aren't going your way, constant communication is your most powerful ally!

L.Jenkins

Thanks Aswerty, that was quite an insightful post and a lot to work. It validates the Design Documentation in terms of complication, in which very little is needed as I'm the only developer. I given a couple of weeks, 2 at most to hammer down the requirements for the project as I have other things to work on at the same time that requires development and administration also.

You've also hit the nail on the head by stating the DB should be the first stage of development/implementation. I already have the development and testing environment set up for when everything is ready to go.

Thanks again for the advice.

Aswerty

I kind of made an assumption that it was a line of business application you'd be building. That might be wide of the mark but a lot of the advice is transferable to the development of other software.

L.Jenkins

I would see it as somewhat transferable as the project (1) may need to be scaled up to near enterprise level to cover a number of sites globally and (2) may need to be configured to work across a number of departments. If it grows beyond my ability to work alone however, then I will have no other choice but to go to my Manager to request a few developers and testers.

mewso

I can only speak for myself in terms of Domain Driven Design but I take this approach literally and model the domain before then mapping it to the database. I find it works very well when used with ORMs like Nhibernate for example. Database last for me.

Aswerty

mewso wrote:

I can only speak for myself in terms of Domain Driven Design but I take this approach literally and model the domain before then mapping it to the database. I find it works very well when used with ORMs like Nhibernate for example. Database last for me.

Then I would revise my statement to 'persistent data structures' first. But that is a bit wordy.

Personally I don't think it is worthwhile distinguishing whether the models/mappings or database schema is designed first (beyond presonal preference). For most ORM's a click of a button is all it takes to produce one from the other. Such that desiging one is the equivalent of designing the other.

mewso

Aswerty wrote: »

Then I would revise my statement to 'persistent data structures' first. But that is a bit wordy.

Personally I don't think it is worthwhile distinguishing whether the models/mappings or database schema is designed first (beyond presonal preference). For most ORM's a click of a button is all it takes to produce one from the other. Such that desiging one is the equivalent of designing the other.

What I'm getting at is moving away from designing for tables and foreign relationships and designing for actual objects. I found it very beneficial having come from a database first background back in the day. So in essence it becomes model first and mapping last but you are correct it's not important to this thread just that designing the database first was emphasised by the OP which is not the approach I would recommend.

Aswerty

mewso wrote: »

What I'm getting at is moving away from designing for tables and foreign relationships and designing for actual objects. I found it very beneficial having come from a database first background back in the day. So in essence it becomes model first and mapping last but you are correct it's not important to this thread just that designing the database first was emphasised by the OP which is not the approach I would recommend.

You're completely right. I think our points of view are just a tad off-beat.

I was the one that first introduced the concept of database first. Just not in the ORM context of: database first vs code first. But in a more general recommendation to design your data structures before you implement the logic/presentation layers. Adding in an ORM in that case would mean, as you say, incorporating the models and mappings into the design process. Though this is still a data structures first approach – which I was trying to get at in my last post.