Anyone who tries to make a cake simply by guessing the recipe and method will very quickly discover that the outcome may not be a good cake. Most of us will reach for a recipe book. In the same way, when embarking on a software development project, using a methodology to provide a framework and sense of direction will ensure a better outcome. This chapter explores a range of possible approaches.

DEVELOPMENTAL APPROACHES

At the heart of a new software development project is the need to solve an identified problem. But what is the best way to tackle this and communicate ideas?

Unfortunately, there isn’t a single ‘one size fits all’ framework, methodology or technique that will solve all your problems – that would be too easy! Moreover, different organisations adopt different methods and tactics to solve their problems. However, there is a reasonable starting point and that is the software development lifecycle (SDLC).

The software development lifecycle

A software development project usually follows a set process with a series of defined (and predictable) steps. This is known as the SDLC. It usually begins with the identification of an internal problem or aspiration, often in the form of a brief. Reviewing the product at the end of the lifecycle can trigger a new development.

The lifecycle contains a series of phases, each one of which contributes a process to the development (see Figure 4.1).

The length of a SDLC varies greatly depending on the size and complexity of the problem it is attempting to solve. Despite this, the lengths of each stage generally remain proportionate – for example, the coding phase is longer (potentially many months) compared to a shorter design and architecting period (perhaps several weeks).

The basic components of the lifecycle (up to the point of roll-out) are as follows.

Brief

This triggers the development process. It could be based on a problem with an existing system or process, something new that is necessary to meet a business requirement, or simply a response to an emerging opportunity based on a new idea. It may occur as the result of an organisation’s aspiration to provide a better customer experience, improve its processes or reduce costs (or all three!).

Feasibility

This is a top-level investigation into the brief which essentially considers the problem to be solved and investigates potential solutions. These solutions can include:

• An off-the-shelf solution: an existing product or application that can be purchased and used without modification.
• A tailored solution: a generic application is used to build an appropriate solution (such as a spreadsheet or a database package), or an off-the-shelf solution is adapted with additional functionality to meet the organisation’s needs.
• A bespoke solution: a solution that is written from scratch with a full process of investigation, design, development and testing before implementation.
• No change: there are times when the costs of a development project would far outweigh the organisational benefits that would be achieved. This is often measured financially in terms of the potential return on investment (ROI). ROI is calculated to evaluate how well a particular investment will perform (or has performed). A low ROI would suggest that the software development might not in fact be feasible.

See ‘How the Client Brief Affects the Development Process’ later in this chapter for more on potential solutions.

Analysis

Once it has been established that a development is required, a full analysis of the problem and the existing system (and how it could contribute to the solution) is undertaken. This is documented to ensure that subsequent decisions can be justified.

Planning

This is a very necessary, formal part of the process which can sometimes be overlooked. It is where expected activities and processes needed to achieve the solution are identified, along with anticipated timeframes. Available resources are then established and allocated to the tasks that will need to be undertaken.

Design

The completion of the analysis leads to the design of the new system. This may or may not be formally documented (depending on the nature of the development and the methodology being used to focus activities).

Development

This phase involves the actual coding of the new solution, system or service.

Testing

A range of testing strategies may be applied in software development. Some are undertaken during development, others when the development is considered relatively complete, and others during a period of final testing before the developed system is handed over to the client.

Roll-out/implementation

Once the code has passed testing, it will work flawlessly in a staging environment and be ready to go ‘live’ and into production. At this point, the system is deployed (installed and prepared) for use by internal and/or external customers.

The client will look to the developers for advice about the implementation of the software or system so that it can be integrated appropriately into the business (often called a ‘changeover strategy’). There is no single right answer to the question of how the solution should be implemented, which is why the development team must consider the needs of the client, the risk factors, and the amount of additional work that will be incurred through the implementation activity in the advice they give.

Common to every changeover strategy is the need for the organisation’s data to be added to the new system so that when it goes live it has something to work with. This may require changes to the data to prepare it for integration, such as converting data formats or reorganising the data to prepare it for transfer. The data itself will usually be moved to the new system at a time when normal business transactions are suspended because the organisation is closed. This can be more challenging if the business operates online.

Table 4.1 explores the most commonly used changeover strategies, the risk factors and additional considerations related to them.

Considering a soft launch

A common tactic employed in the IT sector is the use of a so-called soft launch. Prevalent in software releases and commercial websites, in a soft launch the product is made available to a selected audience without any fanfare or marketing.

For a software product this can be used as a form of beta testing, allowing the organisation to test its product ‘in the wild’ without its reputation being affected if the results are not favourable. In addition, it will receive useful bug reports and usage statistics that will help it to resolve identified issues or further improve the product’s performance before full release.

Commercial websites often use such soft launches to roll out new features or make modifications of the user interface. Again, user feedback is invaluable in shaping the next stage of development.

Maintenance

Designed. Coded. Tested. Implementation complete. The new solution is in production and the client appears to be happy. The next step is to ensure ongoing maintenance. Once development is complete and the system has been implemented, a maintenance strategy is put in place to support the system going forward.

Once it is operational, the system is examined for any issues that have arisen as a result of its use and identified errors are fixed. For example, a user might complain about tabbing errors, which is where input boxes are not presented to the user in the right order and the user finds themselves jumping around the screen. This does not indicate that the product is faulty; it is essentially an irritation that really should be eradicated but which probably will have a low priority. If, however, a user discovers that sales records are not being correctly committed to the sales database (for instance), this would be a high-priority issue that would need to be resolved quickly.

Maintenance activities usually fall into one of the following three categories.

Corrective maintenance

Corrective maintenance is reactive. It is usually prioritised because it aims to resolve significant problems with the system that have emerged during its use. Bugs and other defects need to be eradicated quickly for two reasons: firstly, because the product will not be working as it should until these are resolved, and secondly, because users may well view the product with increasing negativity if bugs persist.

Typical bugs include calculations not outputting accurate answers, and button clicks or hyperlinks not working.

Perfective maintenance

Perfective maintenance is also reactive. Following corrective maintenance, perfective maintenance resolves other issues. These issues do not prevent the system working but are known to be irritating to users.

Tabbing errors (as mentioned above) are one example of an issue that would be addressed during perfective maintenance. Another example could be the slow loading of a web application, caused by too many extraneous HTTP (Hypertext Transfer Protocol) requests during initial loading. In such cases a developer will use specialised tools to review and improve the design. For example, a pipeline profiler might be used to analyse the performance of a web page while it loads. This type of activity can often be the developmental equivalent of diving down a very dark and deep rabbit hole, and it may lead to the unearthing of graver concerns, such as CPU load issues and memory usage inefficiencies. Perfective maintenance is time-consuming but it may not garner the same amount of resources as corrective maintenance, which is perceived to be more critical; in other words, perfective maintenance is a ‘nice to have’ but not essential.

From a purist’s point of view (and in an ideal world), anything that negatively impacts a user’s experience of a software product should be considered critical. However, time and money are always at a premium in any development project, so higher-priority issues will typically win out.

Adaptive maintenance

This is a longer-term form of maintenance and is usually a response to the organisation’s ever-changing environment or its future aspirations. New technologies could emerge which the business would like to exploit. The organisation may have expansion plans, such as selling new product lines or services which will mean higher transaction volumes or larger numbers of users. In some cases, adaptive maintenance may even be required in response to the activities of business rivals and the need to be more competitive.

Adaptive maintenance is proactive because the organisation is able to plan the maintenance activities that will be needed to prepare for its future plans.

It is certain that your organisation will be involved in corrective maintenance, and it is likely that it will also be involved in perfective maintenance. Adaptive maintenance may well initiate another development project and the SDLC will start again.

Review

At the end of the SDLC, a review is undertaken which not only examines the success (or failure) of the product but also examines the development process (from the receipt of the client brief through to the implementation of the software), decisions taken and so on. Usually involving a range of stakeholders, this activity provides the development team with an overview of their activities and what went well or badly. It also provides an opportunity to consider how future developments could be improved based on lessons learned.

A good project manager will produce a checklist that covers all of the development activities so that they can be individually inspected. This will provide a useful focus for the evaluation process and a framework for evaluation, enabling subsequent development activities to be examined in the same way. In this way, it can prove or disprove whether lessons learned have really affected the organisation’s development processes.

Here is a very basic checklist of what could or should be considered under each phase:

1. Brief
   • How well was the client brief understood at the start of the development?
   • How much additional information had to be sought?
   • Did this change the nature of the client brief or reinforce what was originally known?
   • Was a requirements specification formally produced and agreed between the client and the development team?
   • Were constraints and limitations correctly identified?
   • How well were the client’s agreed instructions communicated to the development team?
2. Feasibility/analysis
   • Was a feasibility study undertaken?
   • Would a feasibility study have provided a wider range of potential solutions?
   • Was the analysis suitably executed?
   • Were appropriate investigative techniques used?
   • Was any information overlooked which would have benefited the development?
3. Planning/design
   • Was a plan produced?
   • Was it sufficiently detailed?
   • Was enough recovery time built in to accommodate problems experienced along the way?
   • Was the design comprehensive?
     • Did it cover all functional requirements?
     • Did it cover all non-functional requirements?
     • Did it sufficiently cover the user interface design?
   • Were the techniques used to articulate the design appropriate?
   • Were the coders able to interpret the requirements from the design documentation?
4. Development
   • Was enough time given to coding activity?
   • Was the right guidance given to individual coders or coding teams?
   • How well did the teams work together to produce the solution?
   • Was the right language used to produce the solution?
   • Did the coders have sufficient skills or was additional support needed?
5. Testing
   • Was the testing suitably planned?
   • Was sufficient time given to the testing activities?
   • Was appropriate test data generated for each testing phase?
   • Were the outcomes of the testing analysed to produce a comprehensive plan for corrective action?
   • Was sufficient user testing undertaken to be confident of future user acceptance?
6. Roll-out/implementation
   • Was the changeover strategy adopted right for the context?
   • Were the implementation risks correctly identified and was action taken to mitigate the identified risks?
   • What difficulties were experienced?
   • What could have been done differently to smooth the transition process?
7. Review
   • How should the product be supported and maintained going forward?
   • What will we as an organisation offer in terms of support?
   • Is there a particular process that should be set out to ensure that the product is effectively maintained?
   • Has the review considered the views of all stakeholders and stakeholder groups?
   • Did the differing needs of the groups impact on the success of the development project?
   • Did the development team have sufficient access to information to be able to identify what went well and what went badly?
   • How should future development activities be modified to ensure similar mistakes are not repeated?
8. General
   • Was the right methodology adopted to support the development?
   • Were any aspects of the methodology less than helpful in supporting the development activity?
   • If the project were repeated, would the same methodology be chosen?

The review phase of the development should be extensive and the activity should be undertaken with commitment, particularly as there may be a tendency to want to end the current development project so that the next one can begin. Understanding what went well and where improvements could have been made will be invaluable experience for the next development.

HOW DEVELOPMENTS GO WRONG

A suspicious but worldly wise project manager once said, ‘What could possibly go wrong?’ Given the long gestation time of many projects, the answer is likely to be, ‘Quite a lot.’ (For example, see Maughan 2010.)

Here are a few things to think about – always remember, forewarned is forearmed!

The perils of scope creep

We previously discussed the importance of formally agreeing the boundaries and requirements of a project at the outset to manage the client’s expectations and to focus the activities of the development team.

In an effort to keep the client happy, it is very common for developers to try to accommodate requests from the client that emerge during development. Unfortunately, the client often has little or no understanding of the impact of the request they are making in terms of additional work – and even, in extreme cases, how what might appear to be a relatively minor change may have a detrimental impact on other aspects of the development.

For example, adding an additional data field to customer details may not seem particularly problematic. The reality, however, could be that doing so would affect data structures far beyond this entity. For example, on every form and screen where the data was displayed, the code that drew the detail from the customer file would need to be modified, and the code that generated any reports might also need to be changed to accommodate the additional values.

Accommodating these changes would be an example of scope creep. This in itself is not an issue, particularly when you remember that methodologies such as Agile and Scrum (covered later in this chapter) are built on this concept as part of normal development activities. However, the reality is that if the level of scope creep is not carefully managed, there will be two potential outcomes:

• The deadline may not be achieved (unhappy client).
• Your profit will be reduced because you are doing more work for the same money (unhappy senior managers).

To avoid scope creep, all team members involved in a development project should be alert to ensure that additional client requests do not derail the project. However, this does not mean that you should immediately dismiss any additional requests made by the client. Ideally, as a development team, you will have discussed at the outset how you would respond to any client requests that are not specifically included in the requirements specification.

One well-used strategy is to raise an invoice for all but the most minor requests. This outlines the additional cost that would be incurred by the client for the inclusion of the requested changes, together with a revised delivery date for the project. It is then up to the client whether they want the amendments to go ahead or not. If not, the organisation simply raises a credit note to cover the invoice.

On a positive note, accommodating scope creep can be one way to produce extra revenue! The outcomes are then:

• The client gets the changes they want (happy client).
• The organisation invoices for the additional work (happy senior managers).

The conflicting demands of stakeholders

Never underestimate the impact that the conflicting demands of stakeholders can have on the outcome of a development project. It is essential that any conflict is eradicated as early as possible in the project. This may not be easy and may require a number of meetings involving heated debate before agreement is reached. The stakeholders should not only agree the requirements and boundaries but also the priority of the components, timelines and so on of a project.

As a software developer, you should not attempt to influence this process. However, you should be available to answer any questions and provide technical clarification about what is or is not possible so as to help the stakeholders to reach a consensus.

Missing deadlines and the ramifications of late delivery

Missing deadlines not only impacts the client but can also affect the team members by increasing the amount of stress they experience when they realise that the project is falling behind. This is particularly the case because missed deadlines tend to create a domino effect where one late project reduces the time available for the next project. This applies additional pressure and may ultimately cause instances of team member sickness.

The outcome could be staff cutting corners, producing a poor development outcome which damages the organisation’s reputation. This could affect revenue going forward – not only the remuneration expected at the end of the project but also by reducing the organisation’s chance of securing further work if the failure is made public.

An equally significant potential ramification comes in the form of financial penalties, which may eliminate profit or even result in the organisation delivering the project at a loss. There are certainly documented cases of organisations being destroyed by penalties they have been unable to pay, leading to their demise.

Monitoring the development project is essential to ensure that it stays on track. The activity schedule should be revisited regularly to check milestones are being met, adjusting timelines if required and keeping the client informed if relevant. This is why it is essential to build recovery points into the plan to ensure that there is wiggle room if needed.

Other scheduling issues

In addition to the key issues already mentioned, projects can be impacted by many other less predictable issues, such as:

• Tasks were significantly more complex than originally predicted. This also includes the notion of ‘gold plating’, which is where developers spend too much time adding flourishes or enhancements to components which were neither requested nor expected by the client.
• Planning was incomplete or ineffective, leading to a lack of co-ordination.
• Estimators were inaccurate in relation to budgets, skills needed or timeframes. The most commonly encountered issue in this area is overly optimistic schedules. In addition, there will be times when you are required to use personnel whom you may feel are less qualified or experienced than you would like due to resource restrictions.
• Team members may be unexpectedly unavailable due to illness or bereavement. While annual leave can be considered in the planning and scheduling of activities, it is impossible to predict many other events. Furthermore, key project members may leave to go to other jobs, taking their skills and experience with them.
• Team co-operation, motivation and/or communication may break down. This may be caused by the introduction (or removal) of team members, which can negatively influence the team dynamic, or by tension or conflict between team members.
• Team member performance will vary over the course of the project and some individuals may let all or part of the team down.
• Initial design issues may be overlooked or ignored, and this can have an impact on coding. This is often the result of a failure to produce documentation which adequately records decisions made, leading to mistakes occurring later in the process which then require revisions further down the line.
• The project team could be let down by third-party tools which change between the start of the project and the point when they are integrated, or by promised technologies not being available when required.
• Commitments to other equally or even more important clients may mean the organisation needs to pull team members off projects. This is the most difficult event to manage, particularly if those team members have become deeply entrenched in the project and do not want to leave it.
• Poor quality control in terms of inadequate testing can lead to an underwhelming user or customer experience.

Not monitoring these issues, or simply identifying them too late, can lead to failure.

Regular team meetings will help with the monitoring process, although the frequency of meetings will be dependent on the level and complexity of the project at any particular point in its activities. When meetings are held, you have the option of involving stakeholders, particularly if some ad hoc decisions need to be taken along the way which require their involvement. This is a more attractive option than sending and receiving endless emails.

The importance of the client journey

It is essential to keep the client informed throughout the development process. Why? Because apart from the fact that they are paying the development costs and it’s great customer service to keep them informed, managing the client’s expectations is crucial.

A good manager of a software development project manages the client’s expectations actively rather than reactively. Anticipating problems helps in preparing appropriate responses and planning how to communicate them.

Keeping the client informed throughout the development process reduces the chance of having to be the bearer of unpleasant (‘we can’t solve the problem’) or unexpected (‘we can solve the problem but it’s going to take much longer’) news.

Things to consider as part of your project delivery include the following:

• Report project progress and status on a regular basis.
• Involve the client in feature reviews, particularly within an Agile flow, so that the client is fully apprised of the progress and overall quality of the project.
• Document and explain the known risks that could impact delivery – then they won’t be a nasty surprise (if the worst should happen).
• Encourage the client to ask questions.
• Be honest in your dealings and explanations (e.g. identified bugs and known issues).

KEY DESIGN METHODOLOGIES AND LIMITATIONS

A methodology is a set of predefined rules, methods or approaches that can be followed to deliver a desired outcome. Think of it as a recipe. All of the ingredients are gathered together and then the steps are followed to produce the final dish.

Some organisations select and apply a methodology in its entirety. Others choose to loosely follow a methodology, selecting only the most relevant rules and processes to suit the project in hand. In addition, you may well find an organisation has a house methodology which draws on a range of other considerations (e.g. the personal preferences of key staff in a project team).

It would be unusual for a new employee in a development context to ask which methodology was being used as this can look somewhat naive. It might therefore be helpful to know some of the key features and uses of some of them so that you can recognise them when you encounter them.

Methodologies are usually categorised as sequential, incremental or iterative, in relation to their phases and how they are conducted. Additionally, the Agile methodology combines elements of iterative and incremental methodologies.

Bear in mind that, in principle, the SDLC (see above) provides a framework which is recognised as the basis for most of the current methodologies, but the amounts of emphasis on the different components may not be the same, and in some methodologies some parts are largely informal or missing altogether.

Sequential methodologies

Sequential methodologies require each phase of the development to have been fully completed (reviewed and essentially signed off) before the next phase begins. The best known (and most commonly used) sequential model is the Waterfall methodology. Just as a waterfall cannot flow backwards, each of the phases in the Waterfall model must be completed before the next phase begins (see Figure 4.2).

Benefits of the Waterfall methodology include the following:

• Separate, highly defined phases.
• Easy to understand.
• Easy to manage because setting milestones is straightforward.
• Good for predictable developments, particularly where the intended outcome is known in advance.

Drawbacks of the Waterfall methodology include the following:

• Errors in earlier phases are difficult to correct.
• Phases may not overlap.
• The first working version of the software comes late in the development process.
• Clients can feel disconnected from the activity as in the early stages there is little to see.
• Not suitable for complex projects or where innovation would be desirable.

Incremental methodologies

Incremental methodologies support development projects where the requirements of the new system can be broken down into a number of modules where each will become a part of the final working system (see Figure 4.3).

Once each module is complete, it can be released to users.

Benefits of the incremental methodology include the following:

• Each phase or increment can be carried out by a separate team, so development can occur in parallel.
• The client will be able to experience the product during development and users will be able to provide feedback.
• It is possible to generate systems quite quickly.
• Any errors will often be found (and resolved) in hours or days, which means that they will not have had the chance to impact too heavily on the development as a whole.
• It can easily accommodate less experienced developers.

Drawbacks of the incremental methodology include the following:

• The ultimate outcomes of the system need to be well understood in advance.
• It needs a good team with a wide range of skills.
• The teams must communicate regularly to ensure that the modules in development will work together when the system is finally pulled together.

Iterative methodologies

Iterative methodologies are based on the quick development of a basic working model: a minimum viable product (MVP) that does the job but that would benefit from refinements either through added functionality or through the incorporation of emerging technologies which provide new possibilities (see Figure 4.4).

This methodology is ideal where a project may require a significant number of refinements during the development process. This is likely to be because the general direction of travel is known but the specifics of the final solution are less well known.

Benefits of the iterative methodology include the following:

• It allows for innovation.
• It can easily accommodate changes in requirements.
• It is a responsive model, as any client requests can be considered (although it is important to be careful that the project does not become derailed by scope creep; see earlier in this chapter).
• The client is able to feel involved as they can be invited to give feedback.

Drawbacks of the iterative methodology include the following:

• It requires a high level of team interaction at all times.
• The team must be fully committed to ensure success.
• Members of the team must be experienced.
• It can suffer from scope creep.
• It requires a high level of regular interaction with the client and users to check everybody has a shared understanding of what has been agreed.

Agile

Agile, and its derivative Scrum, are classified as both iterative and incremental. These are the approaches that are most commonly used in the IT industry. To be involved in this type of development, it is essential to understand the terminology used. The key elements are as follows:

• Story: a story is a top-level overview of a user requirement. It is sufficiently detailed to enable a group of developers to produce an estimate in relation to time and cost.
• Story points: these are used to measure the complexity of the story in terms of effort, risk and difficulty (see Chapter 13 for more on these).
• Epic: this term describes a larger section of work, usually made up of a number of stories around a particular component or function in the development project.
• Scrum: drawn from rugby, this term is used to describe the participants (or team) who will contribute to the development process. The Scrum is made up of a group of individuals who have the required range of skills, such as coding, analysis and testing. Each Scrum has a Scrum master, who essentially leads the activity.
• Sprint: an intense (but usually short) period of activity usually lasting about two weeks. The activity is iterative.
• Sprint planning: in order to use sprint time effectively, the stories are broken down into specific activities and tasks during sprint planning.
• Scrum board: this is used to map and monitor the progress or status of the tasks in the sprint. Some development teams use physical boards to represent the activity, whereas others do this electronically.
• Sprint demo or review: this follows a sprint and provides an opportunity for developers to share what they worked on during the sprint, raising the level of awareness among the whole team about the status of the development project.
• Stand-up: this is a daily event where the development team gather around the Scrum board (or access an electronic version on a PC or other device) to report back individually on the previous day’s work and the plans for the day’s activity. The idea is that standing up ensures that this is a relatively short activity lasting only 10 to 15 minutes.
• Retrospective: this follows a sprint and provides an opportunity for the Scrum members to evaluate the sprint, its activities and its outcomes. Furthermore, lessons learned from the sprint can carry forward into the next.

The Agile Manifesto

Written in 2001 by 17 software developers, the Agile Manifesto is centred around four key values:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

(Agile Manifesto Authors 2001)

For each statement, the item on the left has more intrinsic value than that on the right. For further information on Agile, refer to Agile Foundations (Measey et al. 2015).

HOW IS A DEVELOPMENT METHODOLOGY CHOSEN?

Deciding on the right methodology to use in a development project depends on the type of development being undertaken. Take the example of a new stock system for an online retailer. You would have to decide which model is likely to be the most suitable and beneficial when applied to the development. Would Scrum be a suitable model? Should a sequential model be used instead?

You may find it useful to employ a series of established criteria to help you make the decision. Examples of potential selection criteria are detailed in Table 4.2.

When it comes to choosing the methodology to support a development project, there is not always a clear winner – just some obvious wrong answers. As suggested earlier in this chapter, it can also come down to the personal preferences of the manager (what they know) or other key stakeholders (what they have experienced), or even just the preferred in-house approach (what they do).

HOW THE CLIENT BRIEF AFFECTS THE DEVELOPMENT PROCESS

Each project has unique features, sculpted by the needs of the client and the technical challenges these needs present. It is important to know the required outcome, the timescales involved, the potential risks to the project, the accessibility needs of clients and users, the stability of the requirements and any constraints (see Table 4.2) before you can even begin to understand the problem itself. You can then begin to ask, ‘What type of problem are we facing and which skills will be needed to solve it effectively?'

Assume from this point that almost everything that follows applies whether your client is internal or external. This is because an internal client should be treated in much the same way as an external client.

All software development projects are triggered by one or more of the following, which give the development a context:

• identified problem or problems with an existing system;
• changing needs of the organisation;
• business drivers such as reducing costs or improving efficiency;
• the availability of new technologies;
• activities of competitors;
• identification of emerging markets.

In terms of development, the solution or solutions could fall into any one of the following categories or could even need a combination of the solutions detailed below:

• Off-the-shelf (OTS): a solution you can simply buy, install and use – for example, an accountancy package or creative software for editing photographs or video.
• Bespoke: software that is created completely from scratch to meet a client’s needs. This is often necessary when there is no similar product on the market. Bespoke software is often created for a specific context.
• Tailored: a solution where an existing product is adapted to include additional functionality so as to make it more suitable for the client.
• Apps: essentially, these are software applications which are designed to perform limited or specific tasks. For example, entertainment apps allow users to access services such as Netflix or YouTube, or wider media services such as IMDb, where they can view an online database of TV, film and video game information.
• Games: computer and video games are developed for PCs and for devices such as tablets and phones, or they can be played online via a web browser.
• Hosted services: those where a third party is paid to provide and manage a range of services.

Let’s explore that last one in a little more detail.

Hosted services

There are many types of hosted service, all of which have software products at their core. At the top level, these hosted services fall into one of four categories, as shown in Figure 4.5.

Software as a service (SaaS)

SaaS is where an application is distributed and licensed for use over the internet. This means that the software is not downloaded or installed onto the user’s machine and both the software and the files created on it can be accessed and used from any computer, providing there is an internet connection.

SaaS provides hosting for applications and development tools and provides a level of database management and business analytics. Examples of SaaS include services such as Dropbox, GoToMeeting, Google Apps, Google Docs and OneDrive. These are useful services for small organisations with limited resources. They also provide opportunities for sharing content during short-term collaborations, particularly where applications may need to be accessed using both web and mobile interfaces.

Platform as a service (PaaS)

Built on virtualisation technology, PaaS provides customers with the services that enable them to develop and run their own software without needing to buy and maintain the usual infrastructure associated with these activities. The customer provides the applications and the data while all of the other services are provided by the third party (including servers, storage, networking, run-time libraries and even the operating system). Examples of PaaS include Google App Engine, Apache Stratos and Windows Azure.

Infrastructure as a service (IaaS)

IaaS allows customers to provide almost all of the software components of the system, with the third party providing the hardware, networking, servers and storage. Examples of IaaS include Google Compute Engine, Amazon Web Services and Rackspace.

Amazon and Google both offer extensive cloud computing services that provide an increasingly wide range of services and technologies to customers, including:

• business applications;
• customer engagement;
• relational databases;
• developer tools;
• IoT (Internet of Things);
• networking and content delivery;
• storage (short-term and long-term, i.e. cheaper ‘deep freeze’);
• streaming game technology;
• additional cloud-based game processing;
• streaming media services;
• migration and transfer;
• APIs (application programming interfaces).

System definition

Once the client brief has been understood and the reasons for the software development project have been identified, a system specification is generated which defines key aspects of the development. Typical activities include:

• Identifying key deliverables: these are the expected goals or outcomes of the development project. The key deliverables will become the criteria for success against which the completed development will be judged.
• Confirming scope: this is an essential part of the system definition process as it sets the boundaries for the development project, confirming what will not be included in development as much as what will be.
• Agreeing timelines: it is important to always ensure that timelines are realistic. Over-promising and under-delivering can have a whole set of consequences from financial penalties to loss of reputation.
• Agreeing other milestones: depending on the development project and the needs of the client, there may be some additional milestones which will need to be observed, such as the delivery of a prototype.
• Confirming available resources: the development team must establish the resources they will have at their disposal for the project. This should include consideration of:
  • time;
  • budget;
  • hardware;
  • software;
  • team skills and team availability – in this regard, some mitigating actions may be taken if time allows, such as sending a team member on a relevant course to improve their skills.
• Understanding constraints: many people confuse the term ‘constraints’ with the boundaries or scope of the development project and/or the availability of resources. Instead, in this context, constraints are factors which influence the development and which are essentially non-negotiable, such as complying with particular legislation, having to create a system which will work with an organisational process that cannot be changed, or having to work with existing data capture methods.

Matching client needs with team skills: a team leader’s responsibility

It is highly unlikely that an entire development team will be involved in the discussions with the client. In fact, it is possible that some of the team members will never meet the client at all.

The team leader will have had significant contact with the client in the early stages and will have been responsible for producing the system specification. This will have been agreed and signed off by the client as a true and accurate reflection of the requirements of the development. This document is used to focus the activity and is frequently employed as a reference point to ensure that the development project is proceeding in the right direction.

It is important to ensure that the right skills are there when needed. To do this, it is essential for the team leader to know what skills are available to them and what to do if any skills are lacking (e.g. buy in additional expertise or ask team members to undertake training or mentoring, which grow the organisation’s future talent).

Very few organisations have the skills they need at their disposal all of the time. If they did, then there would be no need for training or continuing professional development programmes (in which staff are encouraged or required to improve their existing skills or develop new ones).

Understanding development requirements and best practice

Once the client brief has been crafted as a requirements specification, the nuts and bolts required to support the development should be put in place. When it comes to software development, there are several key requirements:

• Availability of appropriate resources, such as hardware, software, diagramming tools and development platforms, as required by the project.
• Selection of team members, making sure that there is the right mixture of skills and experience. The team should usually include some less experienced team members so that they can be given an opportunity to develop.
• An extensive plan that allows for all activities required for the project, allocated to team members as needed.
• Identification of milestones to ensure that the project can be suitably monitored.
• Identification of recovery points, which build in flexibility and make it more likely that the deadlines will be met.
• Agreements about the version control system that will be used to manage the documentation (including the code).
• Agreement on the naming of functions, variables and so on.
• Standard coding conventions (e.g. bracing styles, if required).

SUMMARY

In this chapter we have examined various software development methodologies and situations that can arise during the SDLC (both good and bad). We have considered the client brief and how this is fashioned into a requirements specification which will form the basis for the development.

In the next chapter we will examine the various commercial software languages available.