During the development of projects there are several phases that can be identified. In practice, these phases may intertwine and some tasks can expand across several phases.
In the project lifecycle there are several roles that must be fulfilled. While dedicated teams can be used, in most cases, other teams can undertake some tasks with the purpose of filling in for a dedicated team. This is a common occurrence for small teams.
This phase sets the general outline of the application. All applications go through this phase, even though it isn’t always outlined.
At this point, the client is the most important actor. If any of the teams are excluded from this step, their roles can be assumed by others.
Clients have the role of outlining functionalities they consider to be necessary for the application scope. These functionalities are filtered based on priority, then grouped based on use. There are 2 principal ways of building applications: start from the basics and add features or start from a pool of features and gradually remove or postpone some of them.
Example:
Chat applications require users and messages, but they contain underlying functions that usually don’t surface until the teams begin the breakdown of the application. This happens because users are overly familiar with them.
-login
-register
-recover password
-update account
-view account
-relations
-text
-2 users
Extending the application
-profile
-groups
-search
-suggestions
-images
-videos
-audio
-reactions
Very few applications target specific users and even then the application aspect is important. Applications generally have to be easy to use and intuitive and follow the current user preferences.
While applications that offer services across several platforms are common, the application itself is customised for the platform. Mobile and web use different flows and attempting to use the same flow on all platforms can have negative impacts on the project development and on the audience.
Example:
In the chat application how will the users access a given feature.
-side panels can be used on desktop and web
-slide-in menus are more user friendly on mobile, due to the screen size
-a website can have several chat conversations visible at the same time
-on a mobile device a single chat conversation can be visible at one time
-on the web this can be done with drag and drop or by opening the explorer
-on mobile devices the native camera and gallery can to be used or custom screens can be constructed
-custom screens will take longer to implement and increase the costs
-iOS and Android do not react in the same way when using native functionality. For example, on iOS, the camera and gallery need to be accessed separately so the user has to choose which to use at each point of the flow
This step mostly involves the development and design teams. The clients’ role in this phase varies depending on the development process used.
Changes in the application can be caused by:
The changes can lead to the adding, modifying, removing or postponing of some of the features.
Having reached this phase, in which the application is ready for use, a final test phase is required prior to releasing the application.
The final test is done by the testing team and the client and additionally, the application can be released to a limited number of users, who are usually part of the targeted audience.
Mobile applications will require access to the store and will need to be configured. This responsibility lies with the clients, the developers and the design team.
Example:
If the chat application is released on iOS and Android.
When the application is completed all relevant data should be stored and made available to the client, assuring him that at any point he can continue the application development. Applications are never meant to be static, but the current application version needs to be frozen, and stept need to be taken to ensure that at any given point it can be reverted to this point with minimal changes.
The application version must contain
This process is followed by maintenance and improvement, applications have to be supervised after release in case the need for modifications should arise.
Modification causes:
While in theory, the development phases are clearly delimited and the role of each actor is clear, in practice the separation is never so clear, teams may merge or some of the teams might not exist at all. In practice, teams are not clearly separated, tasks can be covered my members of different teams. Having a single team play multiple roles can lead to gaps in development, while dedicated teams require longer to transfer information.
Interactions between the teams and having members who can migrate between teams improves the project stability and reduces the development time by removing unnecessary steps.
Example: If there is no testing team and only the development team tests, untreated scenarios may arise, due mostly to the team’s over familiarity with the proper application use scenarios.
Example: If there is no communication between the design and development team, some information might not be viewed from the same perspective, resulting in application changes later in the development process.
There are several methodologies that are used when developing the application.
One of the most rigid methodologies with clearly delimited phases. It is mostly used for high risk projects. Each phase requires highly detailed planning and once completed, the results are set in stone and can’t be altered by the following phases.
General overview: https://en.wikipedia.org/wiki/Waterfall_model
Pros:
Cons:
One of the most flexible methodologies allowing features to be added, modified and removed at any point.
Agile offers a more flexible planning solution, overcoming one of the biggest inconveniences of Waterfall, the all or nothing policy. This policy can result, after months of development, through a flaw in the initial phases in major issues in the final phase.
Using Agile, the application will be broken down according to different factors (features, scenarios, tests, etc) and each development cycle will add value to the application.
General overview: https://en.wikipedia.org/wiki/Agile_software_development
Pros:
Cons:
In practice, before the agile planning can begin, there is a general planning, application conceptualization and design phase. ]n this phase, the overall application is described and a development target is set, but changes can be made with each cycle.
The application design is broken down, overall design is done during the initial planning – this will give the application a compact feel, but each change can be accompanied by design changes or additions.
The planning starts according to a list of major features which is usually provided by the client provide. These features are then separated based on value and dependence.
At the beginning of each cycle, a list of features is selected,which will be available at the end of the cycle.
The features must be as independent as possible, but they will always interact to some degree. This interaction can be solved by – preparing for the new feature, allowing the development to be flexible or re-structuring previous features to support the new ones.
Planning structure:
Example:
In the chat application planning
Cycles
This can be due to the fact that the main feature is the chat.
In the chat application planning
Cycles
This will leave the main feature to be implemented later in the project lifecycle.
The end of a cycle doesn’t necessarily mean the application will be released to production, releasing the application will lead to future cycles that require compatibility.
General overview: https://en.wikipedia.org/wiki/Feature-driven_development
At the beginning of each cycle, a test list is compiled. Each test corresponds to a user scenario, and at the end of each cycle the application must pass all tests, including tests from previous cycles.
On each cycle the tests from previous scenarios can be dropped or altered.
Planning structure:
Example:
In the chat application planning.
Desired feature: user1 sends text to user2
Tests:
Planning the project, whether overall, or cycle planning has the role of limiting the amount of time it takes to refactor the code and the developer team to re-sync.
All projects require a starting architecture, this includes projects developed using Agile. The difference between Agile and Waterfall is the timing of the architecture plan.
While Waterfall contains the entire architecture planning in one phase, in Agile the architecture is broken down.
In general, applications need to have a singular feeling, thus, some UI elements are very similar for several scenarios, resulting in 2 different approaches:
The decision concerning the best solution lies with the application future development.
Example:
In a chat application user lists have to be displayed in several scenarios:
The UI for a user list must contain:
There are several major options to develop the features:
Choosing the approach depends on:
Impact
Class Architecture describes each object and the public methods without details on implementation and private elements. It requires the developers to have experience and understand OOP (https://en.wikipedia.org/wiki/Object-oriented_programming), in order to limmit the number of exposed functions and properties. While all public elements must be described and can only be altered with the consent of the team, private elements can be changed at any point.
In Waterfall, the entire architecture is envisioned during the initial stages, in the development phase when there are strict rules to be followed, while Agile only dictates that architecture must contain the communication points.
Example:
In the chat application there must be structures for users and messages and in order to register, the user must have a valid email. The structure will need the developer to create a isPasswordValid function that must return true or false, but will not specify how the password should be validated(length, character type). This allows another developer to create the registration screen, and check that the password entered is valid, without knowing the rules.
The same principles are extended for Framework architecture and Platform communication.
While each component can be constructed individually, it is best for the entire team to discuss major elements and use similar structures.
Building solid, long lasting applications starts with cooperation between different teams and different individuals and requires attentive planning. Methodologies dictate how major phases are distributed during the development process and how the development reacts to changes within the application specifications.
Selecting the best choice for the development process will reduce the amount of effort required to finalise the application. Each member must have a clear understanding of the role he will play in the process, while some of the members have to understand several roles, in order to ensure there are no miscommunications.