Activities in a Software Engineering Process

Software engineering is a field where multiple skilled professionals work to- gether from the inception of a development idea to the release of a software product to end users. Every release is a milestone in developing software but in most cases maintaining software, monitoring software systems and gathering implicit and explicit feedback from people and systems calls for continuity in the development process beyond releases. The key to prepar- ing releases frequently lies in automation and tools but making swift deci- sions in the development process demands flexibility from the whole process.

Activities in such software process areas as requirements,development,op- erations,quality,testing, andcommunications and feebdack, summarized in Figure 4.3 (Publication II), characterize the manner in which software is developed in the modern era.

Requirements are the fuel that keeps the deployment pipeline flowing.

Without requirements, there would be nothing to test, deploy or release.

Requirements elicitation entails finding out from persons inside and outside of development organizations, from existing systems, or from other sources, what the software system in question would need to be like to serve its potential users well. Requirements or reported defects in modern software development turn readily into backlog management items that are require- ments that are to be implemented in upcoming sprints. Backlog manage- ment items and sprints are part of terminology and practice used commonly in the Scrum software development process (Schwaber, 1997). A continuous flow of requirements is a vital part of a functioning software development process since without requirements and a list of backlog items, developers do not have much to work on (Publication II).

Implementing the required changes captured in backlog items, user sto- ries, or other requirements records calls for development practices and activ-

Communication and Feedback

Requirements Development Operations Testing Quality

Version Control

Build

Continuous Integration

Artifact Repository Requirements

Elicitation

Backlog Management

Bug Tracking

Provisioning

Virtualization

Deployment

Unit Testing

UI Testing

Acceptance Testing

Quality &

Performance

Code Review

Figure 4.3: Software development in the modern era has a range of activities that support development, help setting up infrastructure, and verify and validate software products (Publication II).

ities. Developers store source code and other artifacts related to a change in version control systems. Distributed version control systems and dif- ferent version control branch management strategies enable developers to integrate their work in shorter bursts at least locally, working in isolation when needed. Build systems help developers to assemble software packages by compiling source code, execute automated tests, deploy packages to de- velopment environments, and manage dependencies. Remote build systems operate on external servers where additional build steps can be executed.

Continuous integration servers monitor changes from the version control system but double as remote build systems triggered by version control changes, combining multiple build steps and managing complex workflows such as orchestrating virtual machines for testing purposes (Publication II).

Build systems can be further augmented by artifact repositories where com- piled and tested binaries of in-house developed software can be stored to reduce build times. Both internal and external dependencies from various

libraries or other programs are used in software development to compose software; artifact repositories especially help with internal dependencies.

Development and testing of software are usually done in separate en- vironments, which are in turn separated from the production environment where the current software version is running. Setting up the environments and configuring the environments or network infrastructure is part of the operations work integral to the deployment pipeline. Provisioning and vir- tualization are used to build environments out of environment specifications on the fly. Virtual machines for network infrastructure such as servers have their blueprints that allow environments to be recreated and reused, time after time, for each build if needed. Configuring servers automatically with configuration scripts ensures that there are minimal differences between the environments. Replicating testing, staging, and production environments is important to avoid failures originating from characteristics of the environ- ment itself (Publication II). Orchestrating the creation of virtual machines, environments and provisioning in general needs supporting technologies, which in some case may be provided by cloud service providers. Deploy- ment is a necessary step in the deployment pipeline to transfer software packages between environments and deployment automation with scripts or dedicated tools help in the process.

Testing is a fundamental activity in a software engineering process to verify that the software is working as it should and that it generally meets the needs and expectations for which it has been made. Object-oriented pro- gramming guides programmers to write program code out of units such as classes that can have hierarchical relationships between them. Unit testing refers to testing the individual units, classes, in isolation to assess whether methods or functions within the smaller units work correctly. Unit testing is an activity that has proven to be a good candidate for test automation (Publication II). User interface testing focuses on testing whether users are able to interact properly with the displayed elements in the program and whether correct results are shown on the display. Visual elements, aesthetics and evaluating experience of users is by default more difficult to automate than unit testing. Acceptance testing is the step required in order to put a stamp marking acceptance or failure on the tested software version before continuing with deployment and release to production environments.

Software quality is not only evaluated by testing that individual features in the program work correctly. Aside from functional testing, non-functional properties such as performance, robustness of design or of code structures can be tested, too. Performance testing is an important aspect in the web domain where software systems may be subject to varying degrees of user

load, making it useful to see how well a software system can operate under heavy load (Publication II). Load testing every now and then at given load thresholds sets a good baseline for web services but some forms of testing and quality assurance are more continuous in nature. Constant monitoring of software systems and servers, for instance, provides telemetry and health data that help to check the availability of services and catch failures early.

Code designs and structures can be checked either with static code analysis tools or developer code reviews, which both serve as indicators of internal software quality (Publication II).

Communication and feedback processes within development teams and outside glue the other activities together. Developers send messages to each other and to third parties with instant messaging services that help develop- ment and assist in creating social identities for developer teams. Messaging services can even be connected with development processes so that contin- uous integration servers feed developers with real time information on the status of build and test jobs (Publication II). Not all messaging is instant like is the case with e-mail and meeting someone in person for a good old fashioned talk is still an effective way to communicate development needs.

Feedback from the users is essential when trying to build appealing soft- ware products that would meet the expectations of the users. In general terms, the initiative to provide feedback can come from the development organizations or from the users themselves. When developers ask users for feedback, it is a form ofpull communication, and when users are the active party and supply the feedback to developers, it is referred to aspush com- munication (Maalej et al., 2009). With either push or pull communication modes, feedback can be obtained explicitly by interacting with the users or implicitly by observing and analyzing user behavior. Support e-mails or contact forms on a website are classic examples for explicit push communi- cation but modern push mechanisms include the possibility to use real-time interaction with users like chats that can be overwhelming for developers (Publication II). Gathering feedback from users with interviews and sur- veys are useful pull communication processes to elicit requirements. Web services, on the other hand, are especially suited for implicit pull mecha- nisms since user actions on web sites can be tracked and analyzed to increase understanding of user behavior (Publication II), directing the development effort. Rich internal communication and taking advantage of continuous user feedback in one form or another ensure that development stays on the right track.

4.2.2 Determining Maturity of Software Engineering Pro-