Application Development Guidelines

[Breezwell]

Hi everyone,

Quick question regarding application development guidelines.

After working for a few months on developing an Access-based search tool, I have found that I may not have planned the whole project as well as I could initially.

Having no formal training in software development methodologies, I was wondering if anyone could recommend some good reading on the topic or point me to some templates / checklists. I have discovered SRS (Sofware Requirements Specifications) templates, but am not sure if this all I need. In the future, I would like to be able to organize my development projects better and, most importantly, document my work as I progress in a more professional manner on all levels concerning the development process.

Thanks for any suggestions.

[Breezwell]

Well, after doing some research, it appears I have been actually applying Agile development techniques to my projects without knowing it. This feels like a natural approach to me, so I guess I will stick with it as the issues I considered 'problems' turn out to actually be actual iterations in the philosophy.

[Frinavale]

I was required to write a Software Requirements Specifications for an application I developed for university. It was over 170 pages long........... ..for a web site application.

Although SRS is a great way to outline the specifications your application has to meet I don't think they are required unless you are developing something important: like avionics landing gear, a nuke missile launch application or something.

They are a lot of work...in fact I think I did more work on the SRS than I did on the entire web application.

I also can see some limitations to them.
Although they outline what the application should do, the programmer is still left up to guess what that really means:

"There shall be a menu that lists A, B, C, and D"

What does that mean really? Where does the menu go, how does the menu link together...etc.

The other thing that I didn't particularly like about them was that you can constrict yourself by specifying too many requirements.

I honestly did not like this approach.
I can see how they could be used for applications that are critical, but they are too extreme for regular development.

[Breezwell]

Frinavale

The more I delve into software design and programming, the more I would agree 100% with what you have said.

Not having known what an SRS even was when I started working on this project probably saved me considerable time. I have spent some time 'looking back' at the initial stages of the applications development trying to figure out how I would have written an SRS. Based on the numerous diversions and changes in priorities / capabilities / users along the way, there is absolutely no way I could have written an SRS that would come close to outlining and specifying what I would need just to get to this preliminary stage.

My code is commented to the point of probably being annoying, but I feel it is something that can be handed off and utilized better than a lengthy manuscript. I am thinking I would rather spend my time writing a nice, direct and continuously updated user manual than SRS's in the future for smaller application projects.

Thanks for the feedback

[r035198x]

Let me point out just one important rule of software development.

Code to the interface rather than to the implementation.

Aninterface is a specification of what is available without any reference as to how those things are made available. System specifications are often mistook for interfaces. Instead, they are usually less general and contain implementation details which cloud the mind when trying to specify just the system interface.

Most system "changes" result in software designed with implementation details in mind rather than just the general contract of the software. With a more general design, those changes would simply become additions of implementation within the same original specification . A trivial example is a specification which says that "clicking the help button on page x should display a help message saying y". The more general specification for this is that the system should have context sensitive, user configurable help.

The key point in all this rambling is that system specs are evil during application design. Read them only to extract a very general interface of what the system does and use that for the application design. You only open the specs again when you have finished all of your application's base (i.e base objects, model objects, front to back connectivity objects, e.t.c).

[Frinavale]

The key point in all this rambling is that system specs are evil during application design. Read them only to extract a very general interface of what the system does and use that for the application design. You only open the specs again when you have finished all of your application's base (i.e base objects, model objects, front to back connectivity objects, e.t.c).

That advise would have been useful a couple of years ago when I was developing that web application.

[Breezwell]

So when we talk about interface vs. implementation, is it correct to view application frameworks basically as an implementation level from a 'routine software requirements' level? Connecting to the database, creating basic objects, etc. While on the other hand, the interface level would be such work as creating the database schemas, table joins, business logic, etc.?

It makes much more sense from a development perspective when you break this out into these two 'camps'.

Thanks for the great feedback!

[r035198x]

Choosing a framework decides how to do things so it's an implementation decision. If you change a framework you don't change what can be done (interface) but you do change how you do those same things.

The rule should be applied even when creating database schemas and business objects as well. In fact the rule applies at any level of software development even when declaring methods and fields.