Software Life Cycle

Abstract

This chapter valuates popular software engineering practices by gauging their impact on the life cycle of mobile apps. Section 1.1 provides an overview of process models that are widely recognized by the software industry and have been extensively adopted. This groundwork forms the basis for assessing the suitability of these process models in structuring the development of mobile apps in the subsequent sections. Adoption of process models and applications of key software engineering practices are demonstrated using example mobile apps conceived specifically for this experimentation.

For any adopted process model to be effective, a clear understanding, by all stakeholders, of the purpose of the mobile app under consideration for development is a necessity. In essence, this boils down to capturing specifications of a mobile app in a way that not only ensures clarity but also maintains objectivity. Keeping this in mind, groups and organizations, mandated to create software engineering standards, over the years have come up with a variety of formats and styles meant to help capture software system specifications from the perspectives of every involved stakeholder and hence with different needed levels of understanding because of their varying vested interests in the software. In Sects. 1.2 and 1.3, some of these standards are detailed and utilized in specifying the functionality and representing the quality of an example mobile app to highlight the clarity versus objectivity tradeoffs resulting from corresponding representations. This is followed by a demonstration of the adoption of Agile philosophy in the development of the example mobile app. Sections 1.4 and 1.5 step through the initial iterations of behavior-driven development (BDD) of the example mobile app supplemented by engineering practices of continuous integration and delivery.

The intent herein is neither to propose a new process model for mobile apps nor rationalize an existing one but simply to establish a reference point for comparisons with existing or emerging alternatives, as the software quality takes prominence further-on in this book. By exposing the rooted influences of the popular engineering practices, the chapter aims to help shape process models for mobile apps that impel success in their development, distribution, and acceptance as they continue to progressively assume prominent roles in the critical systems and infrastructures.

Exercises

1.1.1 Review Questions

• 1.1 Recommend a suitable process model for each of the following categories of mobile apps. Provide justification and any accompanying conditions for the recommended process model to be successful:

  • (a) Personal safety apps

  • (b) Mobile calendaring apps for business use

  • (c) Mobile banking apps

  • (d) Mobile social networking apps

  • (e) Mobile entertainment apps such as mobile games

• 1.2 Graphical user interface is a prominent component of any mobile app. Discuss when, during the life cycle, the activities related to its design and development are scheduled under Agile methodology in comparison to conventional process models.

• 1.3 Iterative process models recommend implementing products in increments. Compare the criteria used by different iterative process models such as agile and spiral when prioritizing the requirements and selecting them for earlier or later iterations.

• 1.4 How is a user story different from an epic? List common characteristics of good user stories.

• 1.5 Discuss the criteria for identifying user roles when writing user stories for an app. Should photographer and blogger, identified as user roles in the user stories of the Photo Gallery app presented in this chapter, be generalized and referred to simply as the “user” in all the user stories?

• 1.6 Update the UML Use Case Diagram of the Photo Gallery to include the following use cases:

  • (a) The app allows a blogger to authenticate to a website. Authenticated, i.e., signed-in, blogger can upload the photos to the website.

  • (b) The blogger can authorize the app using an OAuth server (refer to the chapter on security for a quick overview of OAuth). The app can then upload photos to the website on blogger’s behalf even if the blogger is not signed in to the website.

  • (c) Discuss the use of “extend” or “include” relationship between the UploadPhoto and the new Authenticate or Authorize use cases due to parts (a) and (b). In other words, does UploadPhoto include Authenticate or Authorize, or does it extend from these use cases with the condition that (i.e., “if”) Authentication or Authorization succeeds?

• 1.7 Provide arguments against using UML Use Case Diagrams to present non-functional requirements.

• 1.8 Consider the following enhancements to the Photo Gallery app. Identify the ones that could be classified as non-functional requirements aimed at enhancing the usability of the app. Represent the remaining ones, i.e., the ones that translate to use cases, into the UML Use Case Diagram of the Photo Gallery app:

  • (a) Provide user an option to display a Google Map with markers indicating locations where Photos were taken.

  • (b) Allow user to specify the name of a city instead of a search area. The app performs necessary geocoding and searches for photos taken in that city.

  • (c) Instead of cluttering the gallery screen (i.e., the layout of the MainActivity) with a number of buttons, provide a navigation drawer to facilitate navigation to other screens of the app.

• 1.9 Suppose focus group sessions that were organized with a group of seniors to elicit requirements for a personal safety mobile app revealed the following needs:

  “As a senior living independently, when in distress, I would like to alert my care givers conveniently and quickly so that care could be provided in a timely fashion.”

  • (a) Derive user stories from the above epic.

  • (b) Draw a UML Use Case Diagram to capture the key user roles and the associated use cases. In particular, illustrate the following desired functionality:

    • (a) A user, when in distress, can utter “HELP” to send an alert to the caregiver for assistance. The smartphone beeps periodically in the meantime to indicate that the help is on the way.

    • (b) The app continuously monitors host smartphone’s accelerometer and gyroscope sensors for the purposes of fall detection. Upon sensing a fall, the app sends the above panic alert autonomously.

    • (c) Upon receiving the panic alert, the caregiver is presented with user’s name, underlying medical conditions if any, and a button that the caregiver can click to call back the user.

    Use stereotypes and suggest any custom symbols if the UML standard appears limited in capturing the above functionality clearly and comprehensively.

• 1.10 Suppose the focus group involved home care nurses and the elicitation of requirements for a mobile Care Calendar app for business use revealed the following need:

  “As a home care nurse providing care to seniors living independently at home, I would like my Calendar to organize my duty roster based on time as well as location so that I am able to complete my tasks on schedule; and allows me to update an assigned task’s status and report conveniently so that I am able to focus more on providing care and less on data entry.”

  • (a) Derive user stories from the above epic.

  • (b) Draw a UML Use Case Diagram to capture the key user roles and the associated use cases. In particular, illustrate the following desired functionality:

    • (a) Users or their family members can register for care services and set a schedule.

    • (b) Home care nurse can access the daily roster of tasks organized based on location and time.

    • (c) Home care nurse can also set location- and time-based reminders.

    • (d) Home care nurse is alerted to when the current location and time meets the criteria for one of the reminders set by the home care nurse.

    Use stereotypes and suggest any custom symbols if the UML standard appears limited in capturing the above functionality clearly and comprehensively.

• 1.11 Compare the effectuality of defining a personal productivity mobile app as a set of user stories as per the Agile manifesto versus ISO/IEC/IEEE 29148 (previously IEEE 830)-based software requirements specifications.

• 1.12 An unambiguous, complete, and correct requirements specification is also the one which is testable. Are the following requirements statements testable? Rewrite the statement so that an objective test of the underlying requirement is conceivable if, as such, the requirements statement appears to be not testable:

  • (a) “Upon pressing the update button, the Care Calendar app shall update the corresponding fields of the database record with the values retrieved from the text boxes on the form”

  • (b) “Upon detecting an emergency situation, the personal safety app shall broadcast the alert to the emergency contacts of the user”.

• 1.13 Compare TDD, ATDD, and BDD development processes.

• 1.14 Suppose a tester ran the Search Photos acceptance test of Listing 1.1 but the test failed indicating the following error. List the bug(s) that the programmer may have inadvertently created in the Photo Gallery code in Listing 1.1 that obviously couldn’t be caught at the compilation time but result in this error at run time.

  “androidx.test.espresso.NoMatchingViewException: No views in hierarchy found matching: with id is <com.example.photogallery:id/etFromDateTime>”

• 1.15 A call to the onView() method of the ViewMatcher component of Espresso may not work if the test requires locating a view in a RecyclerView of Android. Describe how such views could be located when doing automated testing of Android apps.

• 1.16 Among the view matchers supported by Espresso is withClassName(..) matcher. Suggest a UI test example where this matcher is useful over others.

• 1.17 Suppose the photos in the Photo Gallery app are presented as a list with each list item containing the photo along with its timestamp and the caption. Revise the Search Photos test of Listing 1.1 based on this assumption about the gallery view of the app.

• 1.18 Among the common reasons that can cause builds to fail are developers checking in code that failed to compile due to missing files or developers checking in code that broke unit tests. What practices the developers can include in their CI automation strategy to prevent such errors?

• 1.19 List benefits of atomic commits as supported by Git.

• 1.20 Assuming that the version control system being employed is Git, list all the git commands, in the correct order, that will result in the creation of the version control tree pattern similar to the one discussed in this chapter.

• 1.21 What are the benefits and disadvantages of developers doing fewer check-ins of their code in the code repositories?

• 1.22 Other than pulling the code from the repository and building it frequently, what other activities shall be automated as part of continuous integration?

• 1.23 Suggest software configuration management strategies including the version control tree structure as well as the CI workflow for the following development goals involving the Photo Gallery app:

  • (a) Supporting Photo Gallery app across all major Android versions

  • (b) Photo Gallery app developed natively for iOS in addition to Android

  • (c) Photo Gallery app developed by cross-platform technologies such as React Native or Xamarin for Android as well as iOS

• 1.24 Identify performance indicators that could be collected during the life cycle of mobile apps for the post-analysis of process model.

1.1.2 Lab Assignments

• 1.1 Use Cucumber and Calabash to produce the acceptance tests for the Photo Gallery app using the acceptance criteria written in Gherkins GWT format.

• 1.2 One of the reported benefits of Espresso is in its ability to time synchronize the test activities with the GUI thread of the app. Experimentally determine if an increased latency between the prev/next button being pressed and the ImageView being updated with the next/previous photo (perhaps simulated by calling Thread.Sleep() in the code) along with updates to the time, location, and caption fields would impact the correctness of the tests.

• 1.3 Using Espresso’s IntentTestRule, create an alternative to the Take Photo acceptance test of Listing 1.1 to contrast it with UIAutomator.

• 1.4 Enhance the Find Photos acceptance test of Listing 1.1 to verify that correct photos are found even when a longer time window is specified that may fetch more than one photo.

• 1.5 Enhance the Find Photos acceptance test of Listing 1.1 to include the verification of keyword-based search as offered by the current implementation the app.

• 1.6 Enhance the unit testing of the findPhotos() method of the FileStorage helper class by specifying a time window that may fetch multiple photos and verifying that correct photos are returned.

• 1.7 Enhance the unit testing of the findPhotos() method of the FileStorage helper class by including the verification of keyword-based search.

• 1.8 Associate date pickers to the EditViews of the SearchActivity of the Photo Gallery app, and rewrite the Espresso test so that these date pickers are utilized to pick the start and end dates of the time window for the search.

• 1.9 Implement the version control tree structure proposed for the Photo Gallery app in this chapter. Provide visual verification by generating a graph of the resulting Git topology.

• 1.10 Configure Jenkins and Android Studio to perform a debug build each time a feature branch is merged into the develop branch and a release build each time a release branch is merged into the master branch. All the unit tests and UI tests developed in this chapter must automatically run as part of the build.

• 1.11 Enhance the YAML file, presented in Sect. 1.5, to build the Photo Gallery, using GitHub Actions, to also include Lint checks during the build.

• 1.12 Implement continuous app update workflow utilizing Android’s PackageInstaller API. [Hint: Review the chapter on development fundamentals to understand the relevant Android concepts, e.g., Intents, permissions, Services, Broadcast Receivers and Activities, etc. For Android versions greater than or equal to Build.VERSION_CODES.N, an Intent Intent.ACTION_INSTALL_PACKAGE with flag Intent.FLAG_GRANT_READ_URI_PERMISSION could be used to install the APK file retrieved by the download manager. For lower versions Intent.ACTION_VIEW with flag Intent.FLAG_ACTIVITY_NEW_TASK set. For Android 10 and higher, the PackageInstaller API is recommended.]