717a766078707b613b62677c61703d32297c736774787035666776287d6161652f3a3a617a71746c387b706271746c3b767b3a7c7b3b76727c2a2333657467747870617067287b706271746c35627c71617d2824357d707c727d6128243566616c797028717c666579746c2f7b7a7b702b293a7c73677478702b323c2e79787428375b745b372e73797d28375b745b372e Avermin Software Limited © 2003 Avermin Software Ltd. System Design Avermin understands that quality system and software design is not just about efficient data manipulation but also about empowering a user with flexibility and providing a rich working experience. Quality software blends seamlessly into the business process enabling a user to focus on the real issues rather than facing the daily challenge of poorly designed and hard to use software packages that are the bugbear of the industry as a whole. Most designs focus around software tools and techniques to meet specifications, efficiency and reliability without taking into account the whole environment. Avermin system designers bring their experience and knowledge to the user enabling them to get a system which is built around their needs, work processes and environment along with the prerequisites of quality and robustness needed by business today. Depending on a systems complexity Avermin follows this recursive design process: Design Phase 1: Review   Basic Scope   The process starts with a basic scope being drawn out: General issues and possible solutions, optimal medium (eg Web, Stand Alone, Off The Shelf), numbers of users, security, IT infrastructure and other issues are addressed.   Current System Review   A current system review is then produced with a section highlighting problem areas. At this stage interviews can be carried out and data processes reviewed to get an overall picture of the "Business Process". This document enables the system designers to fit the scope to the current system.   Option Review   A client may have a rough idea of what they want but Avermin will take the time to work with them and outline what options are available. A spreadsheet solution may do the job but a database/spreadsheet solution will be easier, more flexible and scalable in the long run.   Detailed Scope   The detailed scope is then developed based on the scope, reviews and options the client wants to take forward. This is then approved by the client enabling the specification to be drawn up in the 2nd design phase. If a major scope change occurs after this point this document is updated and re-approved. Design Phase 2: Specification Most designs focus around software tools and techniques to meet specifications, efficiency and reliability without taking into account the whole environment. Avermin system designers bring their experience and knowledge to the user enabling them to get a system which is built around their needs, work processes and environment along with the prerequisites of quality and robustness needed by business today. Depending on a systems complexity Avermin follows this recursive design process:   Functional Design Specification Design Phase 1: Review   Basic Scope   The process starts with a basic scope being drawn out: General issues and possible solutions, optimal medium (eg Web, Stand Alone, Off The Shelf), numbers of users, security, IT infrastructure and other issues are addressed.   Current System Review   A current system review is then produced with a section highlighting problem areas. At this stage interviews can be carried out and data processes reviewed to get an overall picture of the "Business Process". This document enables the system designers to fit the scope to the current system.   Option Review   A client may have a rough idea of what they want but Avermin will take the time to work with them and outline what options are available. A spreadsheet solution may do the job but a database/spreadsheet solution will be easier, more flexible and scalable in the long run.   Detailed Scope   The detailed scope is then developed based on the scope, reviews and options the client   The functional design specification (FDS) is the main document of any system design. It is a fully traceable document which describes in detail what the system does and how it does it. The FDS is an "open" document. Although any changes must go through the Phase 1 design process it should always end up in the FDS. An FDS should always reflect the current state of the system and where it is going. It is a point of reference for all users, managers and developers.   Business Casing   With the FDS approved it is important to cost out the development, installation, maintenance and support. Cost issues will affect what can and cannot be delivered.   Detailed Design Specification   The FDS, in smaller projects, can be the sole document for the team of developers but in larger scale projects the FDS must be broken down into a detailed design specification. It will cover object design, interfaces, sequences, database design, integration and any other necessities the developers need before carrying out the development. A large amount of flexibility can be added at this stage as the overall impact of changes can be anticipated with the full picture.   Prototyping   Prototyping can occur during any phase of the design process. Avermins developers can produce a basic prototype very easily which enable users to get a feel and confidence for a solution. A picture says a thousand words a prototype will say much more. From a prototype users start to understand what can and cannot be done; what is practical and unnecessary; what takes time and what works for them. A good prototype can be the backbone of a development (although most prototypes tend to only cover the user interface). FDS mock up screens can come from a semi functional prototype.   Acceptance   Although the procedure is a recursive one it can be broken into desirable stages which can be covered by an acceptance document. Although any changes between approvals will require to be reaccepted. Deliverables The two main basic deliverables of the design process are:   Detailed Scope   Functional Design Specification Although depending on the size of the system the documents detailed above through out both phases of design will be supplied. More Information Avermin can provide a consultancy service covering the whole design process or one small part of it. To contact Avermin and discuss this service in more detail please click here.

Legal Information | Terms & Conditions | Privacy Policy 717a766078707b613b62677c61703d32297c736774787035666776287d6161652f3a3a617a71746c387b706271746c3b767b3a7c7b3b76727c2a2333657467747870617067287b706271746c35627c71617d2824357d707c727d6128243566616c797028717c666579746c2f7b7a7b702b293a7c73677478702b323c2e79787428375b745b372e73797d28375b745b372e

be broken down into a detailed design specification. It will cover object design, interfaces, sequences, database design, integration and any other necessities the developers need before carrying out the development. A large amount of flexibility can be added at this stage as the overall impact of changes can be anticipated with the full picture.  

Prototyping   Prototyping can occur during any phase of the design process. Avermins developers can produce a basic prototype very easily which enable users to get a feel and confidence for a solution. A picture says a thousand words a prototype will say much more. From a prototype users start to understand what can and cannot be done; what is practical and unnecessary; what takes time and what works for them. A good prototype can be the backbone of a development (although most prototypes tend to only cover the user interface). FDS mock up screens can come from a semi functional prototype.  

Acceptance   Although the procedure is a recursive one it can be broken into desirable stages which can be covered by an acceptance document. Although any changes between approvals will require to be reaccepted.