Software Developer. Jill Clarke

ever. An example of firmware would be the BIOS (basic input/output system) on a PC which is used in booting the system up when the PC is switched on.

      Developers for this type of programming would tend to be employed by companies that develop electronic products, for example, wireless consumer products such as headphones, automatic (robotic) lawn mowers or medical devices.

THE WORLD OF SOFTWARE DEVELOPMENT

      So far this chapter has introduced the overall business context for development and the types of product produced by developers. This next section looks at where development fits into a system life cycle.

      Software development life cycles

      A software or systems development life cycle (see Figure 2.1), as its name suggests, covers the lifetime of a product/system, from conception to eventual decommissioning. The types of task within these life cycles are generally similar across the industry; that is to say, there are nearly always these stages:

       an initial idea or requirement;

       an analysis of what is needed to produce this;

       the design for the new product;

       the production of the product;

       its deployment when it is complete;

       post-deployment support and maintenance.

      You would generally use some form of methodology, management system or approach in order to manage the stages within the life cycle of a product. The difference in these approaches is the way the software development life cycle (SDLC) stages and tasks within the stages are arranged and carried out. While all these things may not strictly be part of coding, they are part of the context in which systems development is carried out and you may be asked to do some or parts of all of them in your role as a developer. It is therefore important to have an understanding, at least at an overview level, of what they involve.

Figure 2.1 Software or system life cycle

      Many different methodologies are available; the choice of which one to use may be dependent on industry sector, experience, legal requirements, the product under construction or common practice in your sector. Whichever one you use it is important to remember that there is not a one-size-fits-all methodology; selection should depend on the problem domain. A developer will need to understand the SDLC and methodology for the product or system they are working on; they should understand the stages and what their role is within those stages. As a developer you will generally work within the production stage of a SDLC; however as your career progresses you may work in other areas and as you gain experience as a developer you will probably help to influence what methodology is used to manage the stages within your product’s SDLC.

      Many methodologies and techniques are available to help a company or individual manage their system’s life cycle. Each methodology or technique has benefits and drawbacks and should be considered in the context of the system under construction. Methodologies you might want to look into include, but are not limited to, SSADM (Structured Systems Analysis Design Method), PRINCE2 (Projects IN Controlled Environments) Agile, Kanban and Agile/Scrum.

      Formal qualifications are available for some management systems and methodologies, see the following websites for more information:

       Agile/Scrum: https://www.scrum.org/

       PRINCE2 Agile: https://www.axelos.com/certifications/prince2-agile

       BCS has an extensive range of qualifications and certificates: https://www.bcs.org/get-qualified/

      Waterfall and Agile

      The two SDLC approaches I have chosen to cover in this book are Waterfall, an example of an older style of software development, and Agile, a modern style.

      The Spiral model (Boehm, 2014), V model, Unified Process and Incremental model might also be of interest to you and are worth looking up.

      Agile is described as an adaptive approach, while Waterfall is a predictive approach.

      Waterfall

      The first example, shown in Figure 2.2, is a very traditional life cycle model known as Waterfall. While it is no longer considered the default choice for development it is still appropriate in some cases.

Figure 2.2 Waterfall life cycle

      The idea behind the Waterfall life cycle is that it is a predictive approach; that is, the linear style suggests specific stages in the process, each stage having tasks and activities to complete before the next stage can start. Quite often, each stage is ‘signed off’ by the key stakeholders before work on the project continues.

      You may also wish to add, after the Test stage, ‘Install’ and ‘Maintain/support’ to these activities (see Figure 2.3). These stages would occur after production with ongoing maintenance until the product is eventually decommissioned.

Figure 2.3 Additional, post-production stages in a Waterfall life cycle

      The Waterfall model illustrated in Figure 2.2 is sometimes modernised to give the design shown in Figure 2.4. This shows a cyclical life cycle where each phase can feed back into a previous stage for improvements and ongoing increments.

Figure 2.4 Modernised Waterfall life cycle

      In order to understand the types of activity covered in each of the stages in the Waterfall life cycle I have provided a brief list below. Note that this is not a complete list, just a summary of the main activities typically carried out.

       AnalysisInvestigating the problem domain, learning about the product that is needed to solve a given problem or requirement.Possibly also investigating other potential solutions and considering why the solution proposed is the best choice.Defining the scope for the product, what it may and may not do (its features and boundaries). This analysis provides the requirements for the product which can produce a requirements specification.

       DesignThis can include the design for the whole system as well as for distinct parts of the system including the data, functionality, screen layouts, reports, security and architecture.The design might be expressed using diagrams, text documents, models or prototypes (simple mock-ups of part of the proposed product, which might go on to be part of the product itself).

       Build – the main area of focus for the developerThe production of the code for the product. A developer may write anything from a complete system, to small parts of that system.May be done individually or as part of a team.May include creating screen layouts and report design.Includes debugging and some testing.Usually involves some form of documentation.The language used to write the code depends on the domain, the platform that the product is intended for and the company employing the developer.

       TestVarious levels and types of testing are expected within software production.A developer is usually expected to test the components they have built.Other testing levels may be required depending on the developers’ organisation or sector.