We strive to make our software slot seamlessly into place. This can only be achieved through careful project management and diligent planning. Without proper planning and design, no system will fit the environment it is designed to. Whether you have a full system to develop, an idea that you need prototyped or simply advice on systems design, then we are the team to talk to.

Software Engineering is a strategy. The process requires proper design, readability, maintainability, scalability, reliability, function ability and testing. Writing software requires the same discipline as designing a car but on a smaller scale. Software Engineering is an academic approach to educate software professionals in the same way as any other form of engineering.

A typical software project must follow the following life cycle.

System Requirements Specification (SRS) and Analysis

System Design Specification (SDS) and Review

Unit Development and Review

Unit Testing

System Testing and Review

System Handover and Installation

As you can understand from the above headings there is a big emphasis on the word Review. This is probably the most important aspect of any project. At every stage it is important for not only a team of Engineers to review the stage but also the project owner to be involved.

For example if two engineers wrote a SDS based on the SRS without reviewing the manual with the client, then the biggest mistake would have been made. The client would be the one person to understand that the engineers had got it right or wrong. If the mistake is found at this point then not much harm is done. If the mistake is found at System Handover then the entire process will need to be reiterated costing both the customer and the development company time and money.

Costing

This initial document will be used as the focal point for the project costing. If the requirements are too complex then the costing may not be possible at this stage in which case it maybe necessary for the company and client to agree on development of the SDS

Content

The SRS will tell companies bidding for a tender exactly what the customer requires. If you as the client sit down with potential suppliers and verbally tell them what you want then you are in fact describing your SRS.

A SRS must include the following aspects ;

What is the current process?

If you currently have 10 members of staff all creating web pages that are based on a template then this needs to be spelled out

Why are you changing it?

Do you simply want to save money or is speed and customer satisfaction important points? The most important reasons need to be clarified here. A good way to do this is to place the importance in order.

The designer will see what is important to you and ensure that the solution adopts these points

What do you want to replace it with?

Do you have any idea what you want? The more idea you have the better the results will be for you. If you have no idea then you will end up paying for a designers flair which may result in a poor project.

This is not designed to make you the customer do all the work, far from it. This point means that you the customer have thought about the solution and articulated this into words.

What is your time frame and your budget?

A software project can go on indefinitely and cost an infinite amount of money. You must guide the tender company with some idea as to your budget and required time frame. If you really don’t have a clue on your budget then the companies will quote the project based on the requirements alone.

If you do manage to articulate a financial model then the company will be able to breakdown what you can get for that money. It may turn out that you can only get 60% of what you are asking for with your current budget and this needs to be found out prior to you spending a Dollar, Pound or Yen !

What constraints do you have?

Do you wish for the company to develop using certain tools or languages?

The specification needs to be in English. The document needs to have pictures where necessary, however crude they maybe. The document needs to be clearly sectioned and paragraphed and must be easy to read. Remember that interpretation is the mother of all cock-ups when it comes to Software Development!

Paying Someone To Analyse Your Process

Paying somebody to write a SRS for you may save you more money in the long run as it will reduce the risk of interpretation. The role is given the name Systems Analysis and is a highly skilled role. You not only need a professional that can write a good document but also need someone on site to study what you do. This person will need to have the freedom of talking to all your staff and given the time to complete their job.

In general, small business does not need this section of the loop. The bigger the project then the more likely a Systems Analysis is required.

An SDS takes the SRS and breaks it down into sections of a puzzle. The puzzle includes the following steps;

Top Level Design

Usually this is a series of diagrams that link sections of the puzzle together. The diagrams show the flow of data and how one module links with another but they do not show detail such as iteration or specifics such as “customer name”

The above process shows the basic process of making a cup of coffee. Clearly the process shows a black coffee and a white coffee but has a very obvious mistake. Can you spot it?

The mistake is no hot water or sugar! A minor point if you want a hot cup of coffee with one sugar and not a cup with milk and coffee powder.

The above example is a trivial example of how the design process breaks down. Used correctly it becomes a powerful medium to describe what it is the client wants to achieve.

Module Design

Each bubble in the above diagram represents a module. A module is a semi process. Something that needs to happen.

In our example, the module “Make a Coffee” breaks down into three minor modules. Each are important processes in making a coffee.

Once the system as an entity has been broken down far enough into modules, then these modules can be designed. For example “Milk” cannot be broken down any further and describes clearly what it does. Maybe “Insert Milk” would have been better.

Module Testing Strategy

Once we know the modules and what they do we can design a test strategy for them. For example “Coffee Powder”. What happens if we run out of coffee? What happens if there is more than one choice of coffee? These test conditions will ensure that the software developer has adequate conditions in place when developing the software.

Integration Testing Strategy

When all the modules are brought together there is a problem. They need to be tested. For example, what if we have tested the modules individually for one cup of coffee and the system must make many? We need to test that the kettle has enough water for all the coffees we wish to make.

Integration is the connection of more than one module and is a complex operation. The test strategy must ensure that as many problems have been ironed out as possible before a single line of code has been written.

Project Plan

Each module will represent a time-scale for completion. The integration and unit testing will represent a time-scale. The designer will know what manpower they have available for the project and so all this information can be used to plan the project.

The project plan should show when a module will be developed based on a project start time and based on preceding modules. For example developing the module “Inserting Coffee” cannot take place until “Get A Cup” is complete otherwise the coffee will be spilt on the floor.

System Test Strategy

The system test strategy is how the company plans to test the finished article without using live data. For example, if we use actual coffee for our testing then it could become quite expensive. A better way to go maybe to use a cheaper alternative.

The STS should detail how the system will be tested to mimic the actual live system. This will usually involve copies of test data in a test harness.

Once the SDS has been finished, then the document must be reviewed by the client and project peers internally by the company. Mistakes found here will be cheaper to fix than if found at a more advanced stage of development.

The process must be reviewed against the SDS all the way through the development process. Failure to do so by the company will result in a poor product and possible costs for the development company to fix any pending problems.

Unit development can use a variety of RAD applications. This is unimportant except for the fact that if the SRS has requested certain development tools be used then these tools and methods must be used. After all maintenance is more than likely going to be done by the purchaser and not the supplier.

If a developer sees a problem with the design then they must regress and seek clarification from their superiors and or the client. If a problem is found here then it may result in extra costs for the client. The client may choose to ignore the problem or the provider may choose to swallow the extra costs.

Once the company is satisfied that all aspects have been met, then the client should be invited to perform their own testing.

Two things can go wrong here. Firstly the client may find a bug that has been missed by the provider. Secondly the client may find an omission from the original SRS or SDS.

The bug should be fixed free of charge by the provider provided that the testing and reporting of such bugs has met the criteria of the terms and conditions of the contract.

If an omission has been found then there are grounds for the company to ask for more money. Why ? Simply because they would have signed off all aspects of the development as each section gets developed thus understanding that what they are getting is laid down in document form to which the client has signed that they understand.

If the mistake is the fault of the provider then clearly the provider should be liable for the changes assuming they fall into the guidelines laid down in the terms and conditions.

Clearly then, there is an extreme emphasis that the client reads and understands every piece of documentation that the company send them. Clearly the revue stage is not designed to show progress but a step for the client to find out if the company understands the requirements.

At this point the company may have paid for help installing the new system. If this is the case then strategic planning of installation will be required. If not then the company will be responsible for installing the system and planning such an exercise.

Normally at this stage the company will continue to have warranty for bugs for a negotiated period of time ensuring that the system still works properly under release conditions.

An example of this type of failure is database access. A problem can occur whereby two customers go for the same record at the same time. This may never show up during testing but may show up under strained real-time conditions.

Why then do software projects cost considerable money to develop? The answer is simply that RAD means Software Engineers do not have to spend time designing forms and can instead concentrate on providing a better quality service. This is achieved by ensuring that each piece of the puzzle is carefully designed and reviewed meaning mistakes can be found prior to installation and handover.

Some examples of RAD are;

Microsoft .NET Development Environment
Microsoft Enterprise Manager
Dreamweaver

Client – Server

The client server architecture is where many client applications query data sitting on a server database. The database must follow certain rules but typically can cope with multiple requests at the same time. Deadlock must be avoided at all costs.

Whereas most modern databases cope with deadlock it requires thought and design to avoid one client amending data when another is removing it. Therefore the key to any good database is a good design. Poorly written, a database can cause any company major headaches.

Open Database Connectivity (ODBC)

ODBC is the term given to database programming that is non specific. In short it allows the design of a system around a generic database. What this means is that a system can be easily scaled dependent upon the requirements at the time.

The reality of this is that a company may choose an ACCESS Database (which is not a client-server system) to start with and scale upwards to a fully laden SQL Server or MYSQL. The code should not, if designed properly, change.

Deadlock

Deadlock is where two clients want the same piece of data at the same time. The database gets stuck as it doesn’t know what to do first and therefore may either return an error or worse still require a reboot to clear the problem.

Object-oriented development is much more than developing a class model - it now embraces the full lifecycle of system development - business process analysis, use case requirements, dynamic models, component and deployment, system management, non-functional requirements, user interface design, testing, maintenance etc.

Feature Rich System Design

Enterprise Architect is a comprehensive UML analysis and design tool, covering software development from requirements gathering, thru the analysis stages, design models, testing and maintenance. EA is a multi-user,Windows based, graphical tool designed to help you build robust and maintainable software. It features flexible and high quality documentation output. The user manual is available online.

The Unified Modelling Language provides significant benefits in helping to build rigorous, traceable models of software systems in a consistent manner. Enterprise Architect supports this process in an easy to use, fast and flexible environment. For a quick look at UML modelling in Enterprise Architect see our UML tutorials and white papers.

UML design and construction

• Use Case, Logical, Dynamic and Physical models
• Custom extensions for process modelling and more
• High quality MS Word compatible documentation
• Intuitive and simple to use
• Low license cost
• Data Modelling, Forward Database Engineering to DDL and Reverse Database Engineering from ODBC
• Multi-user (Professional and Corporate editions only)
• Forward and Reverse Code Engineering (Professional and Corporate editions only) - Support for Java, C#, C++, VB.Net, Delphi, Visual Basic and PHP
• XMI import/export facility
• Spell checker

Generic Solutions is a preferred reseller and solutions provider of EA. Please contact us today for a great product at a great price.

Click Here to view Enterprise Architect resources.

It seems to me that the entire process is designed to look attractive whilst making it difficult to redeem the voucher for the money.

I bought a new Acer laptop for basic email and surfing around the house. Not a bad little laptop to be honest for the money. However, when I went to redeem the paperwork I had one day left to apply for the refund. If I had remembered one day later then I wouldn’t have got the refund. We are talking about $150 here so it’s quite sizeable.

Another cash back I applied for was a Microsoft Mouse/Keyboard combination. I’m still waiting on the money to hit my bank account from about 8 weeks ago.

During the process of applying for the cash back (via the web) Acer tried to sell us extended warranty for about the same value as the cash back. Therefore a cynic could say that other vendors give you three years however this is just a sales gimmick intended to confuse you by making it look like a great deal.

The reality is, if you stick to your guns and really know what it is you are buying, remain vigilant as to the terms and conditions of the offer, then cash back can actually work. However if you don’t then you will get stung.

The final thing to note, is that the ATO will soon stop this process because the purchase price ($650) Includes GST. However the refund can go into any bank account meaning a scammer could easily dupe the tax office out of a lot of revenue.