Achieving Software Quality During Implementation

Achieving Software Quality During Implementation

Achieving Software Quality During Implementation

Software quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given consideration at each and every point of the development lifecycle, from inception to implementation, and treated with a certain degree of priority.

Achieving high quality software doesn’t have to be complicated, and it certainly doesn’t have to be time consuming. During the implementation stage alone, you can find plenty of simple development processes and practices that will have a significant impact on software quality.

  Keep Consistency With Coding StandardsIt is important to remember that software applications do have a life following on from the final release. In some cases software is expected to last for at least 20 years before it is replaced. As you can imagine, over such a period of time development teams will change, some people will leave and others will come to fill the space. If you were to allow each developer to code in their own preferred format, it wouldn’t take long for code to become unreadable and conflicts to appear.

By taking the time to define the standard to which developers must write their code, you can ensure that all of your code will be both understandable and consistent across every aspect of a project. Furthermore, having this consistency will ensure that any developer will have the capacity to read your code and know what to expect, effectively improving the efficiency of other quality processes such as code reviews.

Allow The Comments To Explain – It may seem counterproductive to spend time writing clean and understandable code only to go and add in comments all over the place, yet they do have their uses. For example, a potential strategy to mitigate the risks of documentation becoming outdated or inaccurate over time is to embed it within code comments and utilise tools to extract it. The major downside to these comments is that they tend to make your code rather cluttered, noisy and generally hard to read for anyone actively maintaining it.

Alternatively, comments can be used as a means to provide clarifications on the intent and reasoning behind certain sections of code. Whilst these things can seem obvious during the present they tend to be forgotten with time, by adding in clarifications you allow developers to know that piece of code exists and avoid wasted man-hours trying to improve or ‘optimise’ code that does not need to be (or in some cases cannot be) optimised.

However, it is important to avoid adding comments in situations where they aren’t needed. If the code is simple and obvious, don’t add in a comment, as the example below shows.

/*
Set the value of the age integer to 32
*/
int age = 32;

Know Where You Stand With Version Control – As you develop and maintain software systems you will constantly be making changes. When you work alone it is a relatively simple task to keep on top of these changes, however as you add more people things become a little more complicated.

By implementing a version or change control system, such as git or subversion, you are given the means to manage changes with ease, with each change and the different versions that are created as a result all being logged in one place.

For example, should you have a team of three or four engineers working on the same piece of code all at once, having a version control system in place allows each individual to make changes as they see fit without the worry of overwriting another team members work. Organisations that utilise version control are also provided with an additional layer of security should major issues arise within your system, allowing you to roll back to a version where the code was known to be in working order.

Remember To Review The Code Too – Regardless of the type of development, the industry or how much you trust and respect your development team, there is always a value in performing reviews on your code. In every team you will have developers from all sorts of backgrounds and with a variety of strong suits. By having several people peer review code you not only spread understanding of the project at hand, you effectively offer the opportunity for someone to suggest an alternative solution or a way to reduce complexity and improve performance.

Of course, you also get the added benefit of reducing the risk of mistakes going unchecked and open bugs making it into the final release, however there are some things one should be cautious of. As with all things, by doing too much you begin to lose the benefits. Reviews take time and effort to do properly. If you spend too long reviewing and re-reviewing code repeatedly, you will quickly find yourself hindering your own progress.

Defend Against The Unexpected – The easiest way to distinguish an experienced programmer from a novice is the degree to which they write defensive code. It is unreasonable to expect end users, who have not been a part of the development process, to be aware of the exact ins and outs of how to interact with each feature and function. Therefore, unless you want users to experience unexpected errors, crashes and failures, you must attempt to defend against this possibility.

Defensive programming is a method of designing software in order to avoid failure due to unexpected circumstances, and as such aims to build software of better quality and provide a better user experience.

For example if you were to write software to control the temperature of a home or office building, you wouldn’t want users to be able to enter unreasonable values such as 200°C whether it be on purpose or by accident. In order to defend against such as possibility you could include a few lines of code to cap the maximum and minimum values that can be entered.

Have You Covered All The Code? – You should always test your code. If you don’t test you cannot be sure if your software actually solves the problem it is trying to solve, or if it does it reliably. But how can you be certain that you are managing to test everything? After all the larger and more complex software becomes the harder it becomes to test. One potential solution is to look into your code coverage.

By looking into how much of your code is covered during testing, you highlight areas that are continuously skipped over. Having access to this information offers up the opportunity to investigate the reasons why these areas go untested, such as redundant code, missing test cases or undocumented functionality. As a beneficial outcome of this process, hidden bugs can be brought to the surface, where they can be removed prior to the final release.

Don’t Leave It All To The QM – Whilst it is undoubtedly the role of the Quality Manager (QM) to encourage and enforce the adoption, improvement and following of a quality plan or process, they are not solely responsible. In order to reduce rework, improve user satisfaction and reduce the risk of untested non-functional requirements, quality has to be considered by the rest of the team and become integrated as part of the development lifecycle.

Furthermore, it should be remembered that the purpose of quality auditing is to check that quality has been achieved. Not used as a checklist to make sure that it will happen.

More From The Blog

Achieving Software Quality During Implementation

Achieving Software Quality During Implementation

Achieving Software Quality During ImplementationSoftware quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given...

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65...

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? - Top 5 Solutions To Turn It AroundKeeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it...

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take...

Developing A New Web Based System? Have You Considered…

Developing A New Web Based System? Have You Considered…

Developing A Web Based System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look...

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a...

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? - 6 Top ReasonsIt would be impossible to spend more than a month in the world of software development and never encounter requirements to some degree. Almost every project is centred around some form of requirements documentation, and...

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?

Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65 and 80% of projects failing to meet their objectives?

Seeing such startling statistics must make you begin to wonder if you would recognise your own development project turning sour. Let these top tips, on how to asses project performance, either put your mind at ease or give you some serious thinking material.

Have you considered the project objectives?

No matter the type of project its overall objective will always be to deliver results on time, within budget and of a good quality. As a means to assess progress towards achieving these objectives we tend to flood projects with Key Performance Indicators. It is all too easy to get caught up in the creation of indicators that you forget what it is you are actually trying to measure. Make yourself a list of the projects KPI’s and note down what they are actually measuring. This will allow you to determine if you can track the progress of the project as a whole, rather than just individual project stages.

  Check #1 – if you don’t know what your performance indicators are measuring now is the time to find out

Check #2 – go over all your indicators and ensure you can monitor the progress of your project as a whole or if you are limiting yourself to a short-term view

Are you making the right kind of progress?

Although KPI’s undoubtedly help drive productivity, they can ironically double up as a distraction and delay progress. Generalised KPI’s may lead to activity, but it may not lead to progress. For example, a KPI to run seven tests a day would spur action but are they the right seven tests that actually advance the project overall. As far as the indicator is concerned its requirements have been met therefore progress has been made, when in reality the amount of progress made is zero.

  Check #3 – double check that your performance indicators are allowing focus on the right kind of progress

Are you tracking your milestones?

A key staple of any development project is the use of delivery milestones. If you aren’t making use of them, you should. Milestones allow for the tracking of planned schedules. Consistently meeting project milestones is a sure sign that things are progressing nicely, but not having a perfect record is far from unusual. Having the odd blip in an otherwise perfect record isn’t much of a cause for concern, and could be the result of an unplanned absence, but if the trend of deviation is always for the worse you most certainly have a problem on your hands. However milestones are not an absolute measure of completeness, completing four out of five milestones does not mean you are 80% done.

  Check #4 – have a look in the rear view mirror at the trend over previous milestones, what is the general trend

Check #5 – looking forward make sure to take note of deadline failures and re-plan dates accordingly

Do you understand why you need more budget?

having to approach project stakeholders for an increase in budget is one of the most embarrassing moments you could ever experience. Decided at the beginning of a project, the budget is what dictates the volume and type of resources that can be utilised throughout a projects lifetime. In the best case scenario there should be no reason to exceed the limit. However as the saying goes the best laid plans of mice and men often go awry. It isn’t unexpected to ask for small increases to accommodate unavoidable circumstances, but if you repeatedly find yourself in front of the board there must be a cause.

  Check #6 – take a look at the factors the determined the original budget. Are they still the same, or have they become irrelevant as the project progresses?

Check #7 – have the resources being utilised changed from the original plan? If so are they worthy of the difference in cost?

Are you a defect away from disaster?

For a project to go from conception to completion without experiencing a single defect is very unusual. You could even go so far as to say that a handful of defects is normal. However, excessive levels are an undeniable proof that there is an unresolved issue somewhere in the development process. More often than not, defects are a result of rushing to meet a deadline and omitting important processes, such as testing, which raises the question why is there a need to rush. However, if you don’t know the norm for your development how can you tell if levels are bordering on extreme?

  Check #8 – if you aren’t recording each defect discovered, start now

  Check #9 – analyse you defects and look for a common source

Do you still have the support of the stakeholders?

Whether they realise it or not a projects stakeholders can provide a realistic insight into how it is progressing. Having stakeholders that are willing to participate in a projects tasks or events signifies that they believe in its value. If you were to experience a significant drop in these engagement levels you know that something is going wrong somewhere. It may be that they no longer see a use for the product or service, or they are losing confidence in the end value.

  Check #10are you regularly checking in with your stakeholders?

  Check #11 – are you getting their view of the project?

More From The Blog

Achieving Software Quality During Implementation

Achieving Software Quality During Implementation

Achieving Software Quality During ImplementationSoftware quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given...

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65...

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? - Top 5 Solutions To Turn It AroundKeeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it...

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take...

Developing A New Web Based System? Have You Considered…

Developing A New Web Based System? Have You Considered…

Developing A Web Based System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look...

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a...

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? - 6 Top ReasonsIt would be impossible to spend more than a month in the world of software development and never encounter requirements to some degree. Almost every project is centred around some form of requirements documentation, and...

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Keeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it really a surprise when projects drift away from best-laid plans?

Recognising and admitting that you have a problem is the first step. Now you need to work to get back on track before it is too late and your project is headed to the dustbin. Let these top tips on how to revive your project, help guide you to success.

1) Do you know what it is you are trying to deliver?

Unless you really know and understand the scope of your project then you can’t say for sure that it actually needs saving. Write yourself a list of requirements, whether that be using a formal requirements management tool, agile user stories or just a list of features. Having a list gives you the means to measure the amount of the project actually completed. Ideally this list is then used to create a bunch of tests that prove you’ve met the needs of the project. After all if you can’t prove something works, then how can you say it’s done?

  Check #1 – if you haven’t got your list then start now

Check #2 – if you don’t have a bunch of tests then stop development and put them in place immediately

2) Do you know what’s been done?

With your feature list in hand, asses what’s been done and what hasn’t. Use your tests to evaluate whether it actually works or not. Just because a developer says it’s done, until you can see it working and passing your tests then it’s not.

  Check #3 – if you don’t know which features have been actually been completed you need to find out now

  Check #4 – ensure that your developers know what they are expected to do to pass the features that remain on your list

3) What can you multi task?

Having established the planned features and exactly where you stand in their completion, you will know how desperate the situation is. It’s now time to get down to solving the problem. Look at your list of requirements, are they like building a house where the foundation must be finished before starting on the wall, or is it possible to develop multiple features at once?

Check #5 – challenge your existing dependencies and break as many connections as possible

4) Are you doing the important stuff?

When projects get into trouble there is a huge temptation to drop all of the things that help drive the quality of a project. This then leads to fire fighting and general panic, and later burnout and still no project finished. It’s imperative to still ensure testing and reviews take place to build a foundation of stable and reliable development.

  Check #6 – don’t fall to the temptation of ‘just write the code’, keep project quality alive and kicking

5) Are you putting a square peg in a round hole?

There is a gut reaction when projects begin to drift to simply throw more bodies at the problem. After all, more people working on a feature will mean it is finished faster. This could not be further from reality. All this will achieve is a mass of useless resources, maybe a fight over the best solution and a waste of time and money. Rather than try to brute force speed through numbers, it may be quicker and more cost effective to ensure that team members are allocated to tasks in areas where they are most productive.

  Check #7 – if you don’t know the capabilities of each of your team members, you should make it your top priority.

  Check #8 – have the capabilities of your team been matched to the development requirements of the remaining features?

More From The Blog

Achieving Software Quality During Implementation

Achieving Software Quality During Implementation

Achieving Software Quality During ImplementationSoftware quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given...

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65...

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? - Top 5 Solutions To Turn It AroundKeeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it...

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take...

Developing A New Web Based System? Have You Considered…

Developing A New Web Based System? Have You Considered…

Developing A Web Based System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look...

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a...

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? - 6 Top ReasonsIt would be impossible to spend more than a month in the world of software development and never encounter requirements to some degree. Almost every project is centred around some form of requirements documentation, and...

Struggling To Write Requirements Specifications? – Top 10 Things To Think About

Struggling To Write Requirements Specifications? – Top 10 Things To Think About

Struggling To Write Requirements Specifications? – Top 10 Things To Think About

If you cast your minds back, you may recall that we published an article looking into the reasons why having your requirements detailed in a Requirements Spec is so important. This month we thought that we would revisit this theme to look at some top tips on how to maintain quality and write requirements that are a dream to work with.

After all as the saying goes if something is worth doing, it’s worth doing well.

Can you utilise existing templates?

There is so much to remember when putting together substantial documents such as a requirements specification, it wouldn’t take a lot to accidentally forget to address an element. By utilising a pre-existing template, complete with important and required section headings you can ensure that all of the necessities will be addressed repeatedly. An additional benefit of utilising a standardised template is that it will promote consistency across your projects, carrying over sections such as formatting and traceability standards.

  Check #1does your company have a template that you can use as a baseline

Check #2 – are there any templates from an external source or online that meet your requirements

Is there room for interpretation?

The English language is packed full of words with more than one meaning, which can change depending on the context that they are used in, and if there is one thing to avoid in requirements documentation it is accidental misinterpretation. An easy way to reduce this risk is to dedicate a section right at the start of the specification to defining how terms will be used throughout the course of the document, and how they should be interpreted in documents referenced as part of the specification. By following the same standards across all of your projects, you can save yourself time when it comes to writing a new specification.

  Check #3 – will your requirements be interpreted by everyone in the same way

Can you tell one requirement from another?

Reading through a requirements document is hardly an enjoyable task at the best of times, but having to go through a document with no way to identify which requirements are being read makes the process even worse. Taking the time to tag each requirement with an identifier not only improves the ease of reading, but also allows for accurate and reliable referencing and traceability. Making it easier to clarify links between higher and lower level requirements and the specific tests to verify them.

  Check #4 – is your document easy to read and are specific requirements easy to find at a glance

Check #5 – can you trace your requirements throughout your requirements document

Is there a difference between shall and should?

As a follow on from the previous point it is easy to introduce confusion over requirements if imperative words, such as shall, should, must and will, end up having multiple uses. For most, the word ‘shall’ indicates that the requirement it is attached to must be implemented, whereas the word ‘should’ has a tendency to indicate goals to be addressed. No matter which terms you decide to use in your own documentation, make sure to only use one provision or declaration of purpose for each requirement and that they are used consistently across all of your requirements.

  Check #6 – is there an agreement on the imperative terms to be used in your documentation

Check #7 – has the agreed usage been documented within the specification template

Can you prove it works?

The only way to confirm that a requirement has been successfully implemented is to test the software solution and see if the expectations of the requirement have been met. However, this becomes quite problematic if no provisions for verification were included at the time the requirements were written. A good example of how you can ensure requirement testability is to specify reaction time frames for any output event the software must produce in response to specific inputs, as this gives you what is being tested and the criteria to define a success or a failure.

  Check #8 – is it easy to prove either success or failure to meet your requirements

Will you remember the reason why?

There is only a small proportion of the people on this earth that have the means to remember every little detail, so the chances of you remembering the reasons behind each and every requirement is next to none. Rather than bury your nice, clean, single sentence requirements in words of explanation and justification, you can include the additional information in a rationale statement. Keeping these two things separate still allows for speedy comprehension, whilst also making your reasoning more evident and removing the chance for ambiguity and re-rationalisation further down the line.

  Check #9 – do you have the means to be able to recall the reasons behind each of your requirements

Will everyone who reads it be able to understand it?

Believe it or not, there will come a point where someone will have to read your requirements document. The chances of that someone being the person who wrote the requirements in the first place are minimal, especially when it comes to safety related systems. As a means to keep your requirements clean and concise, it is always beneficial to follow sentence formats where possible. For example, Requirement ID, Object and Provision, Action, Condition followed by the optional Declaration of Purpose/Expected Occurrence.

  Check #10 – how easy is it to comprehend and understand your requirements

Have you been defining compatibility?

It is not unusual for there to be a requirement describing compatibility between an old and new system. Yet this is often an area that requirements specifications fail to address in adequate detail. If your software is to be compatible with other systems or components, don’t leave it up to the software engineers to decide what will make your system compatible, all the while hoping the V&V team will make the same determination. Explicitly state in your specification how you want these different aspects to interact with each other.

  Check #11 – is the manner in which different components are to interact with each other clearly stated or open for interpretation

Are you focusing on ‘it shall’ or ‘it shall not’?

If you can guarantee one thing, it will be that there are more things that your software shall not do than things it shall. It is very rarely worth stating requirements in the negative, as it tends to calls into question other things the system shall not do and introduce confusion or lack of focus on the actual end target. However, there are exceptions particularly when dealing with safety requirements.

  Check #12 – can you justify your ‘shall not’ requirements

Are you falling into the vagueness trap?

It may sound like stating the obvious, but the purpose of a requirements specification is to specify the expected behaviours and properties of a software system. So it stands to reason that requirements contained within these documents should be specific rather than vague. However, it is a nasty habit of both customers and engineers to allow vagueness to creep in. Customers like the feeling that they can refine their requirements further down the line when they have a better idea of what they want. Whereas engineers like that a slack requirement gives them more leeway in their implementation. Unfortunately, this is almost never the reality and results in extensive rework, missed milestones and avoidable expenses.

  Check #13 – be specific in your terminology, avoiding weak words such as intuitive, reliable or compatible

Check #14 – ensure you are defining precisely what the system needs to be or what it needs to do

Check #15 – don’t allow others to persuade you into keeping your requirements vague

More From The Blog

Achieving Software Quality During Implementation

Achieving Software Quality During Implementation

Achieving Software Quality During ImplementationSoftware quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given...

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?

Do You Know If Your Project Failing?Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65...

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

Is Your Project In A Mess? - Top 5 Solutions To Turn It AroundKeeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it...

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take...

Developing A New Web Based System? Have You Considered…

Developing A New Web Based System? Have You Considered…

Developing A Web Based System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look...

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…

Developing A New Embedded System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a...

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? – 6 Top Reasons

Why Do You Need Requirements? - 6 Top ReasonsIt would be impossible to spend more than a month in the world of software development and never encounter requirements to some degree. Almost every project is centred around some form of requirements documentation, and...

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…

Developing A New Desktop Application? Have You Considered…

There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look at these guidelines on what to consider when developing new desktop applications.

      Does your hardware have the man power?

    When developing new desktop applications one of the first points you should consider will be the demands on hardware. A system that will be handling high volumes of data will most likely have quite a high performance demand, and as such will require a high power CPU to meet the demand. Although unlikely in this day and age, should you find yourself in the position where you are unable to source suitable hardware it may be necessary to re-evaluate the system design.

     

    Have you limited yourself with your language?

    Choosing a programming language for your project will not be as simple as it sounds as there is never a magic ‘one glove fits all’ when it comes to developing software. When selecting your language there is a variety of things that need to be considered:

    For applications where there will be a large demand on the User Interface, languages such as C#, Java, & Python are always a good choice. Large savings can also be made on development time due to the large number of function libraries that are available. However, there are issues that should be taken into account. For example, whilst there is reasonable support for C# on other Operating Systems it is generally more suited for use with Microsoft Windows.

    When it comes to Multi-platform or embedded systems languages such as C or C++ are typically a better choice. You will find that there is a wealth of development tools available for different processor based architectures, however they tend to be expensive and vary greatly in the functionality that they provide.

    In terms of safety critical systems, languages such as ADA or SPARK would be a better choice. The downside to these languages is that the development tools available are generally very limited and in cases where they are available, they are generally very expensive to use.

    For organisations that have a limited internal software resource the choice of language will almost certainly be biased by the skillset of their workforce.

     

    It isn’t just Linux vs Microsoft?

    Choosing the Operating System to run your desktop system is more than the never-ending Windows vs Linux supremacy battle. Factors such as familiarity and cost should be taken into consideration. For example where Linux is typically free to use, Windows requires the payment of a license fee. However, if your resources are more familiar with the development environment for Windows, is it really worth trying to work with Linux? The end user and the suitability of each operating system is also an important point to consider. When developing applications for other businesses you may find that they have a preference as to which operating system is chosen.

     

    Did you stop to think about the extras?

    The term supporting applications is typically applied to applications either provided as part of the ‘Native’ Operating System (i.e. Notepad) or available as either COTS (i.e. Microsoft Office) or Freeware (i.e. Apache OpenOffice) software. The uses of supporting applications can vary considerably however the main benefit comes from time saved in product development. However supporting applications also bring additional issues that need to be considered:

    • Licensing – whilst ‘Freeware’ maybe free for home users it often isn’t free when used in a commercial context so consideration needs to be given in determining how potential licencing fees may affect cost savings against development. However, some open source licences will require your application to also be open source.
    • Interface – the interface to supporting applications can vary considerably from spawning and application via a command line style interface to communicating with the application via an application program interface (API). A good application program interface (API) can save a considerable amount of development time but only if it is well documented.

     

    How will you maintain security?

    When it comes to desktop applications and security the first thing you should consider is whether there is need for your system to be on the internet. By isolating your system from the internet, hackers will need to have physical access to the system in order to steal or modify data, which is easier to protect. System security should be considered at every point of the development lifecycle and be tested thoroughly upon completion. Even after the final release, security should be considered as part of ongoing application maintenance to ensure it remains robust to new and emerging threats.

     

    Remember there will be an end user

    In most cases, a desktop application will require some form of user interface to enable interaction with its various features and functions, and often the end user does not have extensive software experience. So surely, it makes sense that the end user should be involved in the design process. Prototyping is a perfect example of how the end user can be included in the development and ensure that the final user interface will behave as they expect.

     

    Is there an expiration date?

    Have you stopped to consider just how long your system will need to operational before it is to be replaced? For example, systems for use in the rail industry are expected to last for at least 25 years before being updated or replaced. As you can imagine a long lifetime demand will have a direct impact on the decision making process and even limit the choice of operating systems and programming language.

    More From The Blog

    Achieving Software Quality During Implementation

    Achieving Software Quality During Implementation

    Achieving Software Quality During ImplementationSoftware quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given...

    Do You Know If Your Project Failing?

    Do You Know If Your Project Failing?

    Do You Know If Your Project Failing?Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65...

    Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

    Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

    Is Your Project In A Mess? - Top 5 Solutions To Turn It AroundKeeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it...

    Developing A New Desktop Application? Have You Considered…

    Developing A New Desktop Application? Have You Considered…

    Developing A New Desktop Application? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take...

    Developing A New Web Based System? Have You Considered…

    Developing A New Web Based System? Have You Considered…

    Developing A Web Based System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look...

    Developing A New Embedded System? Have You Considered…

    Developing A New Embedded System? Have You Considered…

    Developing A New Embedded System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a...

    Why Do You Need Requirements? – 6 Top Reasons

    Why Do You Need Requirements? – 6 Top Reasons

    Why Do You Need Requirements? - 6 Top ReasonsIt would be impossible to spend more than a month in the world of software development and never encounter requirements to some degree. Almost every project is centred around some form of requirements documentation, and...

    Developing A New Web Based System? Have You Considered…

    Developing A New Web Based System? Have You Considered…

    Developing A Web Based System? Have You Considered…

    There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look at these guidelines on what to consider when developing new web based systems.

        How will you maintain security?

      In a world where the technology available is in a constant state of advancement, the level of online threats and susceptibility will only continue to grow. As a result, the security of any web based system is arguably one of the most important areas to consider during the development process to prevent the disclosure or even the loss of confidential information. The security of the system has to be considered throughout the whole development lifecycle and thoroughly tested on completion. Security will also need to be considered as part of the ongoing maintenance of the system, to ensure that the system remains robust to new and emerging threats.

       

      Do you need a framework?

      It isn’t essential to use a framework when developing web based systems, however they can significantly speed up and simplify development. Frameworks can also help with creating a secure system, although regular security patching is required as off the shelf frameworks can be subject to high profile vulnerabilities. The most suitable framework for each development depends on:

      • The target devices, i.e. mobile support, desktop support, tablet support.
      • The type of content, i.e. pages of information, versus more dynamic content such as graphing and data analysis with dashboards etc.
      • The future maintenance and use, i.e. how the site is populated with data/information.

       

      Will you need to scale to increase or reduce demand?

      In a select number of cases a system can have a very well-known user base that is unlikely to change during the course of the system’s life. In these cases, a system and its hosting platform can be designed that meets this in a cost effective way. However, for other systems it may be difficult to predict what the demand will be and how it will change with the life system or you may know that the user base or demand on system resources is going to increase dramatically with time. In these cases, the scalability of the system has to be considered. Failure to do so could result in a degraded user experience or even worse loss of service. Using a scalable design and platform, such as a cloud service, enables the system resources to scale to match the demand as it changes rather than having to re-platform or make significant architectural changes during the operational life of the system.

      What is the best Platform?

      As with many aspects of software development there is no quick and easy answer to this question. Your choice of platform will very much depend on a number of different factors, such as:

      • How much you think the system is likely to need to scale – Use of a cloud based platform such as Amazon AWS or Microsoft Azure, offer quick and easy solutions to scaling, allowing the available bandwidth, performance and capacity of the web based system to be quickly adjusted to meet the demand. This allows more cost effective hosting, and confidence that if demand significantly increases the resources can be increase to match so that the users do not experience a degrade in system performance.
      • Security Requirements of the data – Use of a cloud system may not be appropriate if the data being stored has to be kept within a certain geographical area (kept on-site) or meet strict data security standards. Use of a dedicated server(s) may be more appropriate in this case as it is then easier to define the location and management of the data and its access.

       

      Did you prepare for failure?

      Losing data is never an ideal position to find yourself in, and when it comes to web based systems the loss of just a single server can have serious repercussions. A frequent solution to this problem is to create multiple, or redundant, copies of any data at risk of being lost to be stored on hardware ideally in a separate geographical location. This assures that even in the event of catastrophes such as flooding and fire at the main data centre, your data is recoverable. Consideration should also be given for introducing redundancies to services as a way to secure against the failure of a single node. Running multiple copies of a service simultaneously provides the capability for a system to failover to the ‘healthy’ service should the other fail or degrade over time.

      More From The Blog

      Achieving Software Quality During Implementation

      Achieving Software Quality During Implementation

      Achieving Software Quality During ImplementationSoftware quality is not something you can introduce to a system during the final moments before a release, nor should it be something to sacrifice simply to increase the speed of development. Rather it should be given...

      Do You Know If Your Project Failing?

      Do You Know If Your Project Failing?

      Do You Know If Your Project Failing?Did you know that a study by IBM found that only 40% of software projects successfully meet schedule, budget or quality targets? Or that a separate study by the Portland Journal found similarly concerning results, with between 65...

      Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

      Is Your Project In A Mess? – Top 5 Solutions To Turn It Around

      Is Your Project In A Mess? - Top 5 Solutions To Turn It AroundKeeping a project on track is far from a simple task. The mere act of bringing together a group of individuals with unique thoughts and opinions is bound to introduce a whole mix of problems. So is it...

      Developing A New Desktop Application? Have You Considered…

      Developing A New Desktop Application? Have You Considered…

      Developing A New Desktop Application? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take...

      Developing A New Web Based System? Have You Considered…

      Developing A New Web Based System? Have You Considered…

      Developing A Web Based System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a look...

      Developing A New Embedded System? Have You Considered…

      Developing A New Embedded System? Have You Considered…

      Developing A New Embedded System? Have You Considered…There is always a great number of things to remember when you embark on a new system development, meaning it can be quite easy to overlook some rather important points. To give yourself some piece of mind take a...

      Why Do You Need Requirements? – 6 Top Reasons

      Why Do You Need Requirements? – 6 Top Reasons

      Why Do You Need Requirements? - 6 Top ReasonsIt would be impossible to spend more than a month in the world of software development and never encounter requirements to some degree. Almost every project is centred around some form of requirements documentation, and...