Читать книгу Software Developer - Jill Clarke - Страница 14

The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.

Seymour Cray

The SFIA framework specifically mentions context, so this chapter is a broad introduction to the practice of software development and where the developer role belongs in the greater context of systems and solution development. It considers what a developer produces and examines the broad range of products and industries that need developers. It also looks at where development output and developers fit into a system life cycle (that is, the lifetime of a product/system, from conception to eventual decommissioning).

WHAT IS DEVELOPMENT?

In the context of this book I am using ‘development’ to mean the creation of a program or part of a program, intended to run on a computer or other electronic device. Rather than saying all that every time, I will simply refer to what a developer produces as a product or program.

THE BUSINESS CONTEXT

The role of developer requires a set of skills, used across a very wide and varied range of businesses, sectors and industries. Developers produce a wide range of products; these can be platform- (what type of system it runs on), sector- (what type of industry it is used in) or use- (what its intended purpose is) specific.

In the SFIA framework the role of software developer belongs in a group of roles entitled ‘systems development’; on the skills webpage at the time of writing, systems development belongs in the solution development and implementation category.

Let’s consider the terms ‘systems development’ and ‘solution development’ for a moment. A system is defined as a set of things working together as part of a complex whole; in an IT context, systems development is the process of creating (analysing, designing, building, testing and implementing) a new software application or program. A solution is a means of dealing with a problem and in the business context, when you undertake solution development you are trying to provide something that will fulfil a need (or perceived need) or resolve a problem. These two terms, ‘solution’ and ‘system’ help us to understand why we develop software; we have a business problem and software systems provide the solution (or part of the solution) to that problem.

That problem or need could be any number of things; some example problems with potential solutions could include:

 Problem – delivering medication to patients takes up a disproportionate amount of time for nursing staff; these highly trained individuals could be better utilised in doing other things.

 Solution – a means of automating medication delivery for the health centre.

 Problem – people who post images to a social media site do not always post appropriate images.

 Solution – a social media platform with AI-based image filtering.

A developer could create part or all of the system that provides the solution to these problems or needs.

APPLICATIONS, APPS, WEBSITES, EMBEDDED SOFTWARE, OPERATING SYSTEMS

In the previous chapter I mentioned some of the types of software a developer may create, such as operating systems, applications, mobile apps, games and websites. The type of software you develop is dependent on the type of business or industry sector you are working in. Let’s look at that in a little more detail.

Systems programming

This tends to be a more specialised type of software development where developers create operating systems and software that controls the general running of a system. This type of software tends to interface with hardware or other pieces of software by providing services, for example writing to a hard disk or printing capability. Examples of this type of software include Microsoft Windows, Apple’s iOS, Android and Linux. End users can access the capabilities of this type of software via applications that have been written to use the interfaces made available by the system software. Examples of applications that use the capabilities of the system’s software include Microsoft’s Windows Explorer and Apple’s Finder, both of which give the end user access to the file system which is managed by their respective operating system.

Companies that employ developers to write this type of software tend to be specialist IT or computer-focused industries, the majority of which will be large companies or organisations.

To work as a developer in this area you will generally need a good understanding of hardware and how hardware and software interact, plus an understanding of file systems and interfaces for input/output and data exchange. Working in this area you would be more likely to have formal degree-level education in hardware, software and systems engineering.

Enterprise programming

This type of software is written with a business or organisation in mind; it is designed to help run the business or organisation or to support the business goals. This type of software tends to be aimed at large businesses, sectors or organisations such as government or education.

The type of product created in enterprise programming targets areas such as accounting, payroll, human resources and project management. There are many other types of enterprise software; the key thing they all have in common is that they are not aimed at helping individuals, but organisations more generally.

Companies that employ enterprise developers may be general software development companies or companies that specialise in a particular sector, for example education, and produce software specifically for that sector. In some cases, it could be a large company that has its own IT services department which includes developers who produce software for that company. This could be company-specific or could be sold to other companies in the same sector.

There are also some products in this area that are aimed at small to medium-sized enterprises or companies, which provide some business support software, for example SAGE, which provides accounting software. It sells software with different capabilities and prices based on the size of company it can support.

To work in this area you would often need some knowledge (or need to gain some knowledge) of how these enterprise-level applications work, although you may be able to join a company in a junior development role and learn the business skills on the job depending on the sector.

Application programming

The line between enterprise programming and application programming can be a little blurred because enterprise programs are often considered applications themselves. This definition uses the term ‘application programming’ to try to differentiate development in terms of scale and use. Where enterprise software is designed to help to run a business or to support business goals, application software is designed to support the needs of individuals, which may or may not be work-related. You will doubtless see a crossover with these two types of software, for example social media, originally designed to help individuals stay in touch but now also used by some businesses particularly for things like marketing.

The range of applications is very broad and can encompass products such as games, music players, word processors, social media, fitness trackers and browsers.

This category includes apps that are designed to run on mobile phones or other mobile platforms, such as tablets or watches. These apps are often referred to as ‘native apps’ and are available via an app store, for example, iOS App Store or Google Play.

A very wide variety of companies provide application software; they can be huge corporates with hundreds of employees right down to one-person companies. This can encompass start-ups which will have one or two people with a great idea and that may then grow into larger companies.

Application programming: games

One specialist type of application development is games, which is almost an industry in its own right. All of the skills and knowledge mentioned in this book are still relevant for the games developer but with the addition of imagination and often artistic or graphical flair.

Games can run on many platforms from specialist games consoles to computers running a variety of hardware and operating systems. The games can be single or multi-player and may run over networks or on an individual device.

Specialist games development companies will employ this type of developer for the large gaming platforms such as games consoles, while other companies may employ games developers for educational games or games that may be embedded in a webpage.

Website development

This is where the number of modern development roles has really increased in the past few years. With the advent of the internet, companies (and individuals) have the ability to reach a much wider audience; all they need is some form of web presence. Website developers can give them that web presence, and have the capability to make web-based apps, ecommerce sites and social media sites, plus sites that can leverage mobile device hardware capabilities, for example GPS for mapping and a camera for uploading images.

The developer products described in this section have included software that could be one program, or a system comprising several programs running on a computer that provide a solution or capability. Website development is slightly different in that the product (the website) is designed to run over the internet (or intranet, a company-only network).

When you use a website you usually use a browser, for example Chrome, Edge or Firefox to get the website using a URL (the web address you type in). There could be different code running on the server-side (the computer the URL gets the website from, also known as a web host) and the client-side (that’s the browser on your device). For website developers this gives rise to (at least) three possible roles: client-side (also known as front-end) developer, server-side (also known as back-end) developer and full-stack developer (does both client-side and server-side development). You may also hear about a role called UX (user experience) developer or UX engineer; they specialise in making the user interface (the front-end) of the website better for the user, for example by making the design very easy to use. UX engineers generally differ from front-end developers based on their additional training in UX design and accessibility plus the fact that they may develop components (parts) of a front-end rather than the whole front-end application.

There is no typical type of company that employs web developers; company size could be anything from one person working at home to vast corporations that employ thousands of people. Company type could be in-house developers for a specific company, an agency employing contractors, a software house or other organisation. The location options are equally diverse: developers could work remotely on a freelance basis, from home as either a full-time or part-time employee, on site at a customer’s office or, more traditionally, in a company site or offices.

Embedded, real-time or firmware programming

Embedded, real-time or firmware are all specialist types of software that are used to control hardware in some way. Types of hardware could include, but are not limited to, domestic appliances, mechanical sensors, medical equipment and robots.

Software is described as being embedded when it is effectively installed on the hardware it controls; real-time and firmware are types of embedded software. Embedded software also has a wider description in that it is used to control (run) a specific machine or piece of hardware; for example, you will find embedded software in washing machines and central heating systems.

Real-time software runs within specific time limits, this is important in devices that are timing-specific. Common examples of devices that have real-time software control are heart pacemakers, anti-lock braking systems and fly-by-wire aircraft control systems.

Firmware is embedded software that is permanently stored on a hardware component. It is not generally expected that this type of software will change (hence the name ‘firmware’ is between hardware and software, software will change, firmware could change, hardware won’t change). The firmware will run from its storage location and is very seldom updated or upgraded, if 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.

 Install (deployment)This is the installation of the software to its desired platform. This may be done via a tool to bundle the product and make an installation file which may be deployed by a USB drive or similar media, or, more commonly, via a network, for example, by download from the internet.

 Maintain or supportThis could involve fixing errors found after the product has been deployed, or it could involve enhancements or improvements to the product that can be added incrementally after deployment.Other aspects of support may be compatibility-related, ensuring the product works on the latest operating system for its platform and fixing and issuing updates as necessary.

The benefits of a Waterfall approach are as follows:

 There are structured stages, in a specific order.

 The Waterfall model is familiar to many, it has been around for a long time.

 The Waterfall model is sequential, one stage is completed before moving to the next, and there are often gatekeepers at each stage.

 Documentation is produced at every stage of the product’s development.

 Developers and customers agree on what will be delivered early in the life cycle which should make planning, monitoring and design easier.

 Progress should be more easily measured, as the scope of the work is known in advance.

Disadvantages of a Waterfall approach include the following:

 Requirements should be fixed and complete before production begins; this could involve a lot of time spent up front before any lines of code are written. This could be problematic for systems that have a specific delivery date, time limit or fixed price contract.

 Rigidity of requirements and therefore of the product being built. Because the requirements are gathered ‘up front’ any changes needed may be difficult to add later.

 Changes to requirements may cause confusion, wasted effort or a project restart.

 The working software can only be seen at the end of the process. This means that if there is a change in business practices or a fundamental change needed in the way the product works it may not be spotted until right at the end.

 The product is unknown to the customer until it is delivered at the end. This means that feedback from the customer is not received until the product has been built, meaning that changes will be more expensive to add.

 There can be a lack of visibility – teams don’t realise they are behind schedule until later in the life cycle.

 The amount of time given to the later stages (e.g. testing) is often squeezed by overrunning timescales in earlier stages.

 Emphasis on getting information right up front, which puts pressure on people to decide early and to remember ‘everything’ they want in the new product in the beginning.

Waterfall life cycles are best suited for:

 Projects that require fixed stages and deadlines, accountability or legal auditing.

 Short, simple projects where theoretically, little can go wrong.

 Projects with changing project teams that depend on extensive documentation.

 Projects with stable, known requirements, for example, projects that may have been done before, where chances of surprises or changes during the development process are relatively low.

 Projects where change is complex and expensive: this could be because a change may result in a large amount of wasted time, work or money or because a change of direction would not be possible, for example if the hardware had already been bought and installed. This is distinct from Agile projects which are designed to deal with changing requirements. If change is complex or expensive the project will not allow deviations from the original plan, requirements or design.

Agile

In February 2001, at a meeting of software developers, several of those developers got together and discussed their different approaches to development with a view to trying to come up with an approach that worked well for both creators and consumers of a product. The outcome of this meeting was the Manifesto for Agile Software Development (Beck et al., 2001). Several participants from that meeting went on to found the Agile Alliance (2001).

The Agile Alliance website describes Agile as:

an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it.

This is a summary of those 12 principles from the Agile Manifesto (see the original list in Beck et al., 2001):

 Early and continuous delivery of valuable software.

 Welcoming changing requirements, even late in development.

 Delivering working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

 Business people and developers working together daily throughout the project.

 Building projects around motivated individuals. Giving them the environment and support they need, and trusting them to get the job done.

 Conducting face-to-face conversation as the most efficient and effective method of communication.

 Using working software as the primary measure of progress.

 Sponsors, developers and users maintaining a constant pace indefinitely.

 Continuously paying attention to technical excellence and good design, which enhances agility.

 Working with simplicity in mind – the art of maximising the amount of work not done.

 Utilising self-organising teams, from where the best architectures, requirements and designs emerge.

 The team reflecting, at regular intervals, on how to become more effective, then tuning and adjusting its behaviour accordingly.

Agile practices promote adaptive planning, evolutionary development, early delivery and continuous improvement of both the product under construction and the process being used to construct the product. It also encourages:

 Rapid and flexible response to change. In a dynamically changing business world, being able to change direction or deliver products before your competitors may be the difference between survival and closure.

 Timely and regular delivery of business value through short sprints (these are the time-boxes in which development takes place).

 Feedback from stakeholders and the team developing the system.

 Collaboration among stakeholders and system development team.

 Prioritised functionality, meaning the features that are most important are delivered first. This can be particularly helpful if the product is part of a trial or a prototype.

Agile does not tell you how to implement the ideas listed in the manifesto. People who use Agile use a set of common practices and often use a methodology too. Among the most commonly used methodologies are:

 Adaptive software development (ASD), created by Jim Highsmith.

 Agile modelling, created by Scott Ambler.

 Dynamic systems development method (DSDM), created by the DSDM Consortium.

 Extreme programming (XP), created by Kent Beck, Ward Cunningham and Ron Jeffries.

 Feature-driven development (FDD), created by Jeff De Luca.

 Kanban (development), created by David J. Anderson.

 Lean software development, created by Mary and Tom Poppendieck.

 Scrum, created by Jeff Sutherland, Mike Beedle and Ken Schwaber.

Of these, probably the most widely used is Scrum.

Scrum

Scrum is a product development methodology used to produce complex products (it is not just used for software). It has a ‘to do’ list (the product backlog) and it completes items from the list, in priority order, in short time-boxes (sprints). Each item in the sprint is done to completion. This could encompass design, building, testing, documenting, deploying or whatever is deemed necessary to complete that item.

It has Roles (what you do) + Events/Ceremonies (when you do it) + Artefacts (what you produce).

The roles are:

Product owner – all about the product: the what and why. The product owner will identify stakeholders and create an overview of the product, what it is and who it is aimed at. They will also create and manage the product backlog so that the product is built in the best way possible.

Development team member – all about the build; everything that is needed in order to complete the work selected for the sprint. The mix of people inside the development team can change from one sprint to another but does not change during a sprint. The team is multi-disciplined and self-organising.

Scrum Master – all about the process (a Scrum expert and champion). This person is the enabler for the team; they ensure the Scrum process is understood and enacted and they help to sort out problems that may be hindering progress.

The events/ceremonies are:

The Sprint – this is a container for all other events in Scrum including (but not only) production; it lasts up to one month. It lets the Scrum team break the development work down into tasks ensuring the most important items are completed early on.

Sprint planning – a meeting where the Scrum team decide what is to be done in the sprint, including estimates and planning. Various techniques are used for estimation, such as Planning Poker or Affinity Estimation.

Planning Poker and Affinity Estimation are two of the most popular estimation techniques. They help developers estimate effort in ‘story points’, which indicate how difficult something is to build compared with other items they are building for the product. An example could be when building a website, a search feature would be more difficult to build than a paragraph of text which includes a picture, and therefore the search feature would have an estimate with a higher number of ‘story points’ than the paragraph of text with the image.

Both techniques use number values (in the form of either paper or electronic ‘playing’ cards) to estimate a features value. The difference between the two styles is that Planning Poker gives a value to each feature, one at a time, whereas Affinity Estimation groups the features into ‘like difficulty’ first then decides on a value that will be applied to each of the features. (Affinity Estimation is a better technique to use if the team is new to Agile development or unfamiliar with Agile estimation techniques.)

Daily Scrum (also known as a daily stand-up) – a 15-minute meeting where each member of the development team states what they have done in the previous day, what they will be doing on that day and any blockers (problems) they have that may hinder progress.

Sprint review – a consideration (and possible demonstration) of the work completed during the sprint where the Scrum team can get feedback from any stakeholders that may be present. They can discuss what went well, what didn’t go well and revise the product backlog.

Sprint retrospective – a consideration of how the Scrum process itself worked, where attendees consider possible improvements for the next sprint and create a plan for improvements. The Scrum Master may introduce and demonstrate new tools that have been identified for use in the next sprint in order to help the development team.

The artefacts are:

Product backlog – the to-do list, this is an ordered or prioritised list of product requirements, features, functions, dependency needs, enhancements (change requests) and bug fixes.

Sprint backlog – the to-do list for the time-box, the product backlog items selected for the sprint, plus the plan for delivery.

If multiple teams are working on the same product there is a shared product backlog but each team will have its own sprint backlog.

Progress monitoring – Scrum prescribes that you should keep track of progress so that you know where the project is at any given time. This is often done via burn down charts (a diagramming method used to chart effort or time remaining; when done well they show at a glance whether you are on target to achieve your projected product development).

For full details on the Scrum methodology see the Scrum guide: https://www.scrum.org/resources/scrum-guide

To see the whole Scrum process summarised (by Neon Rain, 2019) see Figure 2.5.

Agile advantages and disadvantages

Advantages for the business of using an Agile approach are:

 Faster delivery of business benefit, by phased delivery or demonstrably working product early in the life cycle.

 Higher quality deliverables as each deliverable is completed (this could mean designed, built, tested and documented or whatever the team deems is ‘complete’ for the purpose of that project).

 Reduced risk – early detection of failing projects (due to earlier feedback). With work being done in small increments, if something is wrong you have only lost a small amount of time, relatively speaking.

 Increased flexibility, being able to adapt to changing business needs or requirements.

Figure 2.5 Agile Scrum framework at a glance (Source: Reproduced (with no changes made) by kind permission of Neon Rain (2019). Licence: https://creativecommons.org/licenses/by-nd/3.0/nz/)

 Greater project visibility. I find this methodology helps people understand the development process better, as they are more involved in it.

 Improved teamwork and cooperation (which may lead to improved morale).

 Continuous improvement of the product.

 Iterative planning, as time is not spent up front gathering every detail about everything (some of which may not be implemented in the new system).

 Improved communication and collaboration.

The benefits for a developer of using an Agile approach are as follows:

 Clear expectations set and communicated frequently for each sprint.

 Success is clearly defined and a clear definition of complete is provided (known as the definition of ‘Done’).

 Issues are raised early on (and escalated or dealt with by the Scrum Master).

 New skills for the team, broader skill base.

 Team support.

 Collaboration within the team and with the stakeholders.

 Project visibility, as one of the requirements of working in an Agile way is to make all the information relating to the build visible. One example of this are ‘Scrum boards’ (see Figure 2.6).

Possible disadvantages of using an Agile approach include the following:

 It takes practice to do it well: some companies or teams give up too soon.

 It can seem chaotic to people outside the Agile/Scrum process.

Figure 2.6 An example Scrum board

 It relies on close collaboration with the customer.

 It is not suitable for all products. Agile is a favoured style for projects which meet the following criteria:poorly defined or incomplete requirements;shorter timescales;the customer wants to use iterative features during the build process (features that are added a bit at a time as the product evolves);the development team is not too large;customer involvement is possible.

 While you still create documentation in Agile projects it is typically not as comprehensive as that created in projects managed with more traditional techniques. This might be a problem for companies that need extensive audit trails or specifications for legal reasons.

Beyond programming: deployment, maintenance and support

Some developers will spend a percentage of their time involved in bug fixing and amending or maintaining older (known as legacy) code. These tasks, along with post-deployment support, are considered to be a normal part of the developer role.

SUMMARY

This chapter looked at the context for development including where development is used, and where and when development fits into a software or systems life cycle. It also began to look at what developers do in the context of systems development. The next chapter will look at the role in more detail, including what skills are necessary to fulfil the role plus the types of responsibility you should expect to have as a software developer.