Starting a software development project from a scratch - Process and steps for software development lifecycle Project Phases

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.

Concept phase

This phase sets the general outline of the application. All applications go through this phase, even though it isn’t always outlined.

• the clients determine the purpose of the application, the target audience, other applications that offer similar features
• the design team suggests possible applications based on trends, target audience, application tone and environment
• the developer team analyses the project and sets the limitations, because even though in most cases some features can be implemented, the amount of effort and time spent on them wouldn’t be justified
• the testing team ensures that the application functions in 99% percent of scenarios

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.

• users

-login

-register

-recover password

-update account

-view account

-relations

• messages

-text

-2 users

Extending the application

• users

-profile

-groups

-search

-suggestions

• messages

-images

-videos

-audio

-reactions

Design phase

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.

• the clients offer general outlines, feedback and suggestions on the design of the applications – this includes screens, partial flows
• the design team creates one or several prototypes, initial versions will contain general outlines for the application and details are added as the application progresses
• the developer team determine the platform specific details and give feedback

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.

• Quick access:

-side panels can be used on desktop and web

-slide-in menus are more user friendly on mobile, due to the screen size

• Chat:

-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

• Image Sharing and adding:

-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

Development phase

This step mostly involves the development and design teams. The clients’ role in this phase varies depending on the development process used.

• the clients offer specific flow changes and fill-in the details. In this phase, the general outline can be altered, because application development is a dynamic process influenced by many factors
• the design team offer support to the development team. This includes fine details which are not visible in the outline or prototype and they also finalize the details concerning specific scenarios.
• the developer team creates the application and does basic tests that ensure that 90% of the user
• the testing team will test the application features and report any flaws.

Changes in the application can be caused by:

• marketing – the target audience is provided with a new product that needs to be analysed
• technology – new devices and frameworks can require new features
• application progress – application outline might differ from the initial vision of the client

The changes can lead to the adding, modifying, removing or postponing of some of the features.

Release phase

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.

• the client runs the final tests and ensures that the application meets the specified requirements and that all third parties and marketing environments are prepared
• the developer team ensures that the application is ready for production, this includes removing all test data and switching all third party frameworks to production environment
• the design team prepares the application presentation
• the testing team will test the application on the production environment

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.

• the clients  – will provide an application description and offer feedback on the application presentation images and videos
• the developer – will setup the accounts in order to support various features like inApp purchase, third party configurations
• the design team will provide videos, images and banners that will highlight the application features. This will offer the users a first impression of the application.

End phase

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

• specifications – list of all features and their current state – initial features that were dropped should be removed, modifications should be included
• design – final application design and notes on the modifications from the initial versions
• source code – the application with comments and specifications, this ensures that the projects can be re-started at later dates or by other teams

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:

• audience changes – audience may request new features or may not be satisfied with the provided features
• new technologies – will require adding new features or may cause some features to become obsolete
• deprecation – some of the features may become unavailable, or must be re-developed
• unforeseen scenarios – the number of tests is limited, but the application may be used by an unknown number of people

Project Managing

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.

Waterfall

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:

• there are no loose ends and no unforeseen events – all details must be set during the initial phase
• the end product will contain all the features described in the initial phase
• development and testing will take less time

Cons:

• there is no way to adjust to changes
• if issues arise in later phases the entire process will be restarted
• concept and planning will take longer
• client will only be provided with a version at the end of the process, there are no intermediate steps

Agile

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:

• application value will increase on a regular basis, at the end of each cycle (one cycle can be as short as 1-2 weeks)
• application target may change, for example, features can be added in any cycle without any prior preparation

Cons:

• application evolution can cause initial cycle results to be obsolete
• application may require to be re-analysed and cleaned

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.

Feature driven development

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:

• overall planning – describe the application target, the general view of the application
• building feature list – list the major features of the application and identify the underlying ones
• plan the feature – at this stage, a list of features that can be developed within 2 weeks is selected
• design the feature – this phase contains the elements from the design and the development phase and refers to UI prototypes, overall architectures, integration with existing features
• build the feature – this phase contains elements from design, development and testing

Example:

In the chat application planning

Cycles

• text messaging, in this case mock users will be used
• user management – login and register
• user relation – find users – this will result in changing phase 1 features, since mock users differ from real users

This can be due to the fact that the main feature is the chat.

In the chat application planning

Cycles

• user management – login and register
• user relation – find users – this will result in changing phase 1 features, since mock users differ from real users
• text messaging

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

Test 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:

• overall planning – describe the application target, general view of the application
• add test – add a test for a feature, this ensures that the developer is familiar with the feature. The client must describe as detailed as possible the feature using use cases and user stories
• run all tests – the new test can already meet the conditions
• fulfill test requirements – write the code
• run all tests – the new test can already meet the conditions
• refactoring – additions can cause the code to be unorganised, as a result architectures may be altered

Example:

In the chat application planning.

Desired feature: user1 sends text to user2

Tests:

• user1 attempts to send an empty text
• user1 attempts to write a 201 character text – there should be an upper limit
• user1 attempts to send a text, without being connected to the internet
• user1 attempts to send a text, while connected to the internet

Project Planning and Architecture

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.

UI Architecture

In general, applications need to have a singular feeling, thus, some UI elements are very similar for several scenarios, resulting in 2 different approaches:

• build individual UI for each scenario, individual UI allows better separation between cycles, each element will take the same amount of effort to develop, and during a change in the UI, each component needs to be updated.
• build a single UI element that can be customised for all or most of the scenarios, the first cycle will require more effort and during a change only one component is updated.

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:

• search – all users of the app
• friends

The UI for a user list must contain:

• keyword field
• user cell: name, icon

There are several major options to develop the features:

• create the UI for each feature
• create individual UI for the keyword and list of items, but have a general cell that displays the user

Choosing the approach depends on:

• developer experience
• client-developer communication

Impact

• if at a later cycle the user cells result in different UI, the developer may need to switch to individual approach, resulting in extra effort compared to starting with individual cells. This is one of the major issues when using agile development
• if at a later cycle the user cells change but have the same aspect, the individual approach requires the developer to update both cells

Class Architecture

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.

Conclusion

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.