Developers are proficient with coding, they can handle complex and abstract concepts, they can also pay attention to details. However, developers often fall into a special pit when it comes to large scale projects, including app development.
This special pit has to do with focusing too much on implementation and got lost in the overall architecture and big picture of an app.
A developer (or a development team) may not realize the pit until very far into the development of an app. The first realization often comes in the form of a request (from a client or boss) to make a “simple change”, but the implementation of the change turns out to be much more involved than it needs to be.
The value of an app is the reason why someone chooses to download and install the app. This is not about the features of an app, but about a higher level reason why the app is used.
We will explore a few examples here.
Why would anyone install the Wells Fargo (or any bank!) online banking app? What are the alternatives?
Without a banking app installed on mobile device, the alternatives are to go in to a local bank for bank transactions. Or, a client may also use the bank web site to perform some of the bank transactions. With these alternatives already in existence, why would a client install and use an online banking app?
This is not about balance checking, check deposit, or bill pay. All of these are features already available in in-person or web-based online banking. It is about convenience. Most people have a phone with them all the time, being able to perform banking functions with a phone means it can be done anytime, anywhere.
The value of an online banking app, therefore, the convenience.
Before navigation apps (like Google Navigation), there were maps, then there were standalone GPS units. Why would a person install Google Navigation use it instead? Again, the answer is convenience.
This one is a little different. To the average person, a smart phone is the first device that can track and predict the movement of the sun. As such, the value of a sun tracking app is more than just convenience, it enables the user to do something that was previously impossible. In other words, the value of a sun tracking app is enabling, not for convenience!
What is the value of such a game? To have fun, to be entertained, to get the gratification of beating levels! In the case of most games, it is the gratriciation factor that sells a game.
Ring is a doorbell with an video camera that is connected by network. The Ring app allows a user to view or review recordings of any registered Ring doorbell.
In this case, the reason of installing and using the app is for peace of mind and personal security.
There is a common thread to the value(s) of an app: it is psychological and mental more so than it is technical!
A use case “describes a sequence of actions that provide something of measurable value to an actor (the user)”. This is quoted from the Agile Modeling web page.
In essence, a use case is “a case of use”, or “one way to use a system/app”. To tie in with the previous section, however, it is best to see a use case as “one independent way a system (app) provides value to the user (actor)”.
This means in the case of a banking app, logging in is not a use case. The activity, by itself, does not serve any purpose or provide any value. On the other hand, “deposit check” is a use case because by itself, it saves the user a trip to the bank or ATM, and therefore provides the value of “convenience”.
In the case of a sun tracking app, one use case is “predict sun position of a time of year”. This, by itself, is useful when someone wants to plan a garden or select a place for a shade tree. The calibration of sensors, on the other hand, is not a use case because it does not provide any value by itself.
Note that a use case is often general and possibly value. For example, “check balance of accounts” is a use case of a banking app. It is vague as it is not clear what kind of accounts is included: checking? saving? investment? credit card?
Because each use case is one general use of an app from the perspective of the user, use cases are logical starting points to organize an app.
In the UML, use case diagrams can be complex because use cases can relate to each other like classes. There is no need to make use cases too complex at the beginning of the development and conceptualization of an app.
We will use an example of an app that, to my knowledge, does not exist yet. As an INTP (based my Myers-Briggs Type Indicator), I am awefully messy when it comes to organization of my stuff. This bothers people who have to live or work with me. I want an app that can help me organize.
Yes, that is the purpose of the app, that is the value of the app!
Now that we have an identified value of “help user improve organization”, it is time to examine use cases to provide that value.
There are several factors leading to messiness. The first is the lack of a habit to clean up after using tools and supplies. The second is more important, there is a lack of a map of what thing should be place where.
To tackle the first problem, one use case is to “remind me to put things back to where they belong after using those things in a job.” This helps to address my bad habit of just leaving things all over the place after getting a job done.
Even if I remember, the other difficulty is to know where each tool or item should go back to. To address this issue, another use case of this app is to “maintain a what-where map”. This way, my app can help me remember where my Dremel bits are supposed to go, where my torque wrench is supposed to go, and etc.
INTP people are also forgetful. Even if I am to organize my tools and supplies, I will soon forget where they are. Another use case of the map is “find location of a thing”, assuming that I follow the what-where map and put things back where they should be.
Because INTP people are perceiving instead of judging, they have a hard time deciding what should be stored where because that, ultimately, is judging function! On the other hand, INTP people are logical and analytical. If there is a logical reason, there is no problem deciding where each thing should go.
This makes another use case for this app, “optimize organizaation based on usage.” This means the app tracks the jobs that I perform and items that I need for these jobs. Then the app can look for clusters where some tools are often used together for certain jobs. Using related jobs as threads and centers of gravity, organization of items can then coalesce around these centers. Such clustering itself may not be the only factor to determine how items are organized, but it may reveal patterns that can help drive the decision of where to store what.
At this point, as a developer, I am very tempted to think in details and implementation. For example, I already am thinking that a job can be divided into sub-jobs, and different jobs can share sub-jobs. Or, the location of things is nested, such as “work room, first cabinet, fourth shelf from the bottom, second bin from left”. I am already thinking about the use of Tiles, custom QR code and etc.
I think of all that, but cannot let details interfere with use case analysis. I can, for example, write down all the ideas, including those details of implementation. This will help remind me later on when it is time to utilize those ideas. For now, my focus is the big picture.
In the UML, sequence diagrams are the next step to document “mock sequences of interaction.” In other words, it is like a dialog between the app and the user in a soap opera.
While we are not strictly using the UML, it is a good idea to think of how an interaction may take place. This is too early to design screens or Android activities, however. Just a description is good enough.
For example, as I do a job, one session of my interaction with the app may look like the following:
The more mock sequences I can document, the better. This allows me to consider different ways of interacting with the app for the same use case.
Also, note how I am not narrowing down to actual Android widgets and other control elements. I am focusing on the essence of the interaction, not the details. The helps me separate the model from the view at an early stage of the development of this app.
Reviewing the mock sequences can help reveal a lot of the (behavioral) model of the app as well as what kind data is needed to run the app. In this example, I know that each thing has a representation. I also know that each “job” has a representation in the app. Furthermore, I also know that each thing has several attributes, at least including the name/description.
This is where the real hard work begins. This hard work involves the abstraction/generalization of the mock sequences into general structures that describe the all possible sequences. There are multiple types of generalization to perform at the same time.
Behavior generalization is the generalization of the actions and interactions recorded in mock sequences into a specification that can be applied to all possible actions and interactions of the app.
Traditionally, this is done by flow charts and pseudocode. As object oriented programming become the main programming paradigm, the way to represent behavior specification evolves to the activity diagram and state machine diagram in the UML.
An activity diagram is, essentially, a super flow chart. It specifies the logic of a “process”, or a particular task. Unlike a conventional flow chart, an activity diagram of the UML can also represent parallel tasks via the use of split and merge.
Depending on the spaghetti factor of the process logic, sometimes it can also be represented by pseudocode. Pseudocode encourages strict and nested logic specification. While superbly suitable to formal algorithms, pseudocode may not be appropriate for messier process logic due to the amount of exceptions and ways to jump from one step to another step.
An activity diagram or a piece of pseudocode is a generalization of mock sequences. However, they do not translate directly into actual app programming code. This is because in a process, there is typically interaction between the app and the end user. A single instance of interaction involves the use of an event handler. This means a single AD can be broken up into many pieces (in the form of event listeners).
A state machine diagram, on the other hand, is a wholely different kind of specification. A SMD is used to specify the states and related transitions of an object. An object in this sense can be any object, including a data structure object. For example, we can use a SMD to describe the life of an activity, or that of a data structure representing a thing to track in our organization app example.
An SMD can be used to reveal the model (as in the MVA design pattern) of data structures. Each transition of an SMD has a trigger/event and a response/action component (both are optional). The “event” of a transition is not necessarily an actual user interaction event, but it represents something that happens outside the object. As such, the “event” of a transition represents a on... method. The action of a transition, on the other hand, represents something that an object can do/initiate, which translates to a normal public method in a class definition.
Data structure generalization is a specification of the underlying structure of data of a system/app. This kind of generalization requires an inspection of each thing that needs to be represented.
In the UML, a class diagram is used to represent the inheritance hierarchy, class composition as well as relationship between classes. As such, it is a combination of traditional class inheritance diagrams as well as entity relationship diagrams.
Regardless of the representation, data structure specification can be very complex. A developer cannot realistically expect to construct the final version of a class diagram in one session. More often than not, data structure specifications are refined over time.
For example, a class inheritance diagram may be refined over time to define super classes (to capture common attributes) and parallel sibling classes (to differentiate and specialize). It is nearly impossible for any developer or systems analyst to have the foresight and identify a class inheritance structure from the top down in one single session.
The same applies to the composition of a class definition. Few people have the foresight to list all the components of a class. You can expect new components added to a class in many revisions. And, in doing so, you can also expect corresponding changes to the class inheritance hierarchy.
It is important to note that an ERD is a very traditional old-school diagram used in data processing. An ERD is important in data processing because it specifies how database tables relate to each other, and how constraints can be specified. Fast forwarding from data processing mainframe computers to mobile devices, the importance of what an ERD represents has not diminished.
In fact, in an app where the amount of data is too much to store on device, an ERD is used to specify a database in the “backend”, usually in the form of a remotely connected database in the cloud.
In a conventional “waterfall”, no coding should start until the design phase is completed. This means all the diagrams and all the specifications are done. Done as in “finished”, “finialized”, “it will never be changed”.
The waterfall model has its place when it comes to systems that are complex and defects and revisions are expensive from the perspectives of the business. Such is the case for all conventional data processing systems in the 60s and 70s!
With the advancement of development tools (compilers, IDEs, emulators), the cost of revisions is lowered significantly in most cases that the strict structure of the waterfall model is no longer necessary.
The “Agile” model is a more responsive, more customer-centric and more continuous development model. It essentially emphasizes “let’s get the customer something that is useful ASAP, then continously refine and improve the product in short cycles.” It lets design patterns emerge rather than choosing and enforcing design patterns in the first place before development.
Using the Agile development model, coding starts as soon as there is enough specification to get started. However, this does not mean without the observation of the MVA design pattern or other good programming practices (such as encapsulation in OOP). In fact, it is these programming practices that enables the use of the Agile development model because good programming practices isolates impact of changes!
The Agile development model also encourages structure and common standards applied to actual code so that code is more self-documenting. This helps to bypass the need of many diagrams to specify a system. Keeping the development team up to date is critical to the success of the Agile development model, which means less redundant document is of great importance.
Scrum is a framework to practice Agile. The key ideas of Scrum includes frequent but time effective team communication, customer-centric prioritization, constant and visual team effectiveness feedback and clear in-the-present (today) objectives for team members.
Agile and Scrum do not negate the necessity to go through use cases, mock sequences, process specification, state machine specification, class inheritance specification or entity relationship specification. Agile and Scrum emphasize that specifications can change and emerge, and they can also be self-documented within source code (therefore requiring little extra effort in addition to code writing/revision).
As mentioned, with Agile and Scrum, proper development strategies and best practices are essential because the isolation of changes is even more important than in the Waterfall model. In a single Scrum sprint, a developer may be making extensive changes to the UI (user interface) while another development works on revisions to the underlying model. Without a clear separation of the two (by using the MVA design pattern), such changes can lead to potentially conflicting modification of the same class methods. No revision control tool can automatically and effectively manage conflicting changes.
Even with Agile and Scrum, the interface between key components of an app should be identified and agree upon before coding starts.