Any software developers on here?

[Ant]

I know a lot of you guys/gals are in IT so thought I'd post....Just need some advice on one of my Final Year modules I am doing at uni.

I've been given a scenario where by I have to justify the use of expensive analysis/design techniques over automated testing of software, with a suitable business case. It's a MD vs Software Developer argument with MD wanting know why so much resources are ploughed in to analysis, design and testing instead of automated testing procedures. I was wondering if you could point me in the direction of journals/sites etc that would prove useful for my research.

Or even articles for the imporatance of analysis/design.

Thanks :)

[yeager]

I used to run the QA department in my company, email me with any questions...

[Ant]

Thanks for that....I'm just getting together some resources at the mo. I may be in touch! :) Thanks

[amcluesent]

Some arguments that favour the analysis/design

1) Economic argument. Relative cost of eliminating an error at analysis stage vs. fixing after testing is often quoted at £1 to £100 (or more). Because you've sunk cost into programming against the incorrect specification and unit testing the flawed module. Then when you fix the module, you have to regression test everything that depends on that module to make sure that the fix hasn't created other errors. So the direct cost of a fix from testing is higher.

2) Theory argument. You can never be certain that testing has found all the problems, too many possible paths to follow and dependencies on the initial state. So you can't test in quality. If you are very serious about it, you can formally prove the analysis and design is correct (i.e. a fly by wire control program for a jet aircraft)

3) Project Management argument. When testing for errors, you don't know how many will be found and need fixing, therefore project manager can't determine in advance when project will be finished which increases uncertainty. And management types don't like uncertainty since, unlike risk, it can't be insured against.

Counter arguments -

Expensive analysis/design techniques (short of using mathematical proofs) are still way, way below the rigour of any other engineering discipline (oops, our bridge fell down...).

Even a good design still needs to be implemented and programmers make mistakes. So your design can still be compromised by poor programmers and so the program would need to be tested...

[davidra]

There's a great book called "The Mythical Man-Month" written by an ex-IBM guy. It doesn't really recommend lots of resources, but it does show the importance of design (and planning for the inadequacies of your design)... very true to life I've found..

[Mr_Sukebe]

Well one point you could make is that analysis and design are completely different steps in the project lifespan.
i.e.
Analysis - I'd suggest that this would involve turning a business idea into a proposed feasible technical solution. It should include a detailed summary of what business processes would be involved and the implications for the business using it.
From a technical perspective, it should have a high level feasibility study of the system to be produced, and probably a database design and process flow.
The target audience for the key documentation should be the business, so overtly technical solution descriptions should be avoided where possible.

Detailed design. This would involve converting the database design and process flow into a series of module specfications (regardless of the system being used, whether it's COBOL, C++ etc). Each of these specification documents should describe how each module should be built and the target audience should be a trained programmer.

Testing. This comes post built, although the test scenarios, conditions and scripts are likely to be written post detailed design.
A good test script will cover all of the key functional and technical elements of the software being used.
Testing should be completed at:
- Unit level. i.e. just the module in question
- System level. i.e. what happens when you plug all the modules together
- User testing level. i.e. what happens when you load the whole new system into a "production look a like environment".

Areas that testing should cover include:
- Does it do what it says on the tin (i.e. it's functional spec)
- Does it work, or break down regularly
- Can it be easily maintained (error messages and codes are useful)
- Will it meet the performance requirements (can it complete in the time window you have)
- Do the documents produced allow it to be maintained easily
- Have you trained the right people appropriately to use it

I won't go into the cost benefits to have good analysis and design, as previous posters have already done that rather well.

As you can see, testing bears no resemblance to analysis and design. I mean imagine, if you didn't have analysis and design, just what would you build?
Would you simply get 20 programmers in a room and say "build me a new stock control system". Consider what they'd do?


As already offered, if you have any more questions, drop me a line.
I'm an ex software developer and now work on system implementation design.

[Vez]

Exactly which analysis technique are you going to be using?

SSADM?
Rapid Prototype Development?

Arguements can be different depending which analysis technique you are using, more specifics please :)

I have a degree in Business Information Technology (BSc) which went major indepth with all this bull****e :)

[Ant]

Cheers guys - there is no specific methodology mentioned. Just gotta go away and research and report my findings. For my project though, I'm using Rapid Application Development.

[Mr_Sukebe]

From what I remember about a course I completed on RAD, the key points were:

- Don't go into massive levels of detail on analysis or design, just get the basics in there.
- Get on an build something that you can show off pretty quickly, so that you have something you can show as a prototype.
- Don't worry if the prototype is not reliable, the key thing is to show capabilities and functionality.
- Once you've gained feedback from the customer, go back and start again from the design phase until you've got something the customer feels really meets his wants.

The key issues with the above are:
The objective is NOT to create a finished product, rather a prototype that you can show to a client. You certainly wouldn't want to sell a product produced used RAD, as chances are that it would be full of bugs.
Because it's much cheaper and faster to complete the total production process, you can go through several iterations of development, which can have benefits, particularly when the customer is not really sure what they're after, or when the technology is very new and you're hunting around for the optimum solution.

So in the case of RAD, testing is far less important and sometimes ignored completely.

[Vez]

I used RAD (or prototyping whatever) to do my degree project, and the University is marketing the result, so RAD can develope bloody good systems for commercial appliations.

;)

[Mr_Sukebe]

Vez,

The course I went on was a theoretical view on how you should conduct RAD.
The view being that it's very good for building proof of concept software.

It's quite clear that if you have developed something that is saleable, that it does not conform to the methodology that was presented to myself on the subject.

If you've developed something that is fully tested and well designed, I'd suggest that you've followed normal development processes and not RAD in the strictest sense.

[Vez]

Errr......

I'll throw my degree in the bin then, didnt study system design for 4 years for nothing :P and as a result am perfectly aware of the theory of various methodologies. We chose RAD due to the time constraints given to us, yes one of the many strengths of the methodology is a quick prototype and indeed product life cycle.

If you go about RAD in the correct manor you can come up with a perfectly marketable product.

Admitedly we chucked the Prototype out in around 4 weeks, and then spent a further 15 odd weeks fine tuning this to Exactly what the customer wanted, as well as lots of useless bits which we stuck in to make the product look the nadgers!.

Oh can you clear up one miss-understanding, through out all the methodologies studied at great depth, i never came across one called 'Normal'.

[Mr_Sukebe]

Vez,

Nope that approach makes sense, so I'll buy that.

I guess the key differences there between traditional and RAD would be that:
- In RAD you'd have a prototype to show to customers and fiddle with a number of times whilst going through it's iterations.
When you've finished iterating, you'd then have a product that you can try to iron the bugs out of.
- In the more traditional approach, it would be designed up front after extensive analysis and show be theoretically a better design as you'll be building from the ground up, not developing from existing logic that might have changed.
Of course the traditional approach is much more reliant on the analysis being right in the first place (clearly not always the case).

I guess that this would infer that assuming you could get the analysis right, that the traditional approach should be more cost effective (less time re-building code), but will almost certainly take longer because you're reliant on completely finishing the analysis and design before build can even begin.

Having said all of the above, the last project I worked on consisted of 8 weeks of analysis and design (by two of us), and was built and tested in just 4 weeks (by a team of 6).

Still, thanks for giving more info ref RAD. I've always been curious to see how it would be used in practice, and it's good to have some pre-conceptions blown away. Nice one.

[Ant]

Once again, thanks guys. That has helped me. :)

[davidra]

- I have always found that putting all your code to one side and starting again 2 weeks before the deadline is a reliable way of getting things done on time! Reason is, as you try to fit in all those last features you usually have to bend everything out of shape whereas if you start over you already have knowledge of all the best bits and the worst pitfalls so that you can avoid them. Never copy-paste your old code, but you can look at it. This really works, I promise. It is called "refactoring". If you have time to start afresh 3 or 4 times your product will be excellent.
:)

[Ant]

Another question...How would you go about reducing the development costs without a necessary decrease is quality?

[Vez]

Pay the contractor less whos programming it :D

[davidra]

"Work smarter, not harder" - www.dilbert.com

[Mr_Sukebe]

Originally posted by Ant
Another question...How would you go about reducing the development costs without a necessary decrease is quality?

I've seen quite a lot of development that is completed in parallel, i.e. with final design completing whilst build is already underway with some components. This approach usually leads to wasted re-development and coding of components during build, which can be VERY wasteful.
Of course the benefits are that you can compress timescales for completion of the project.
The optimum way is to correctly:
Analyse the requirements
Create a functional design and have it signed off
Create a technical design based on the functional
Convert the technical design into specifications
Build code to specs
Unit Test
System Test
Implement

If you can do the above sequentially (i.e. have the luxury of sufficient time), total costs can be minimised because you're only ever doing a particular job once.

Another route is to simply sub-contract out sections of the above. e.g. India are now noted as having lots of very capable programmers. So, complete the design upfront, pass on the technical design and let them build it at a 10th of the cost it is here. If you do that, just make sure that you've requested all notes in code to be in english, and NOT in whatever dialect they typically use (not as though I talk from experience on this...).