Our commitment to excellence is not just limited to the products we deliver, but extends to every aspect of our development process. This documentation is a testament to that commitment, providing a comprehensive overview of how we handle the integral stages of software development - from requirements gathering to planning and final delivery.
1. Requirements Handling: Every successful software starts with a clear understanding of its users' needs. Our approach emphasizes collaboration with clients to capture a detailed, holistic view of the requirements. Through interviews, user stories, and feedback loops, we ensure that no stone is left unturned.
2. Planning: Once we've grasped the requirements, meticulous planning commences. Our team breaks down the requirements into actionable tasks, estimates timelines, and allocates resources efficiently. This phase is characterized by strategic discussions, risk assessments, and setting up measurable milestones.
3. Software Development: Using the best practices, latest technologies, and continuous integration, we strive for robust, scalable, and efficient solutions. Regular code reviews, paired programming, and test-driven development ensure that our software meets the highest standards.
4. Quality Assurance: Quality is non-negotiable. Our QA team conducts thorough testing - including unit, integration, system, and user acceptance testing. Any detected flaws are swiftly addressed, ensuring that our software is not only functional but also reliable and secure.
5. Delivery: Our relationship with clients doesn't end post-development. We pride ourselves in smooth deployments and post-launch support. With a keen eye on feedback and a commitment to continuous improvement, we ensure the products delivered resonate with users and stakeholders alike.
Agile practices include requirements discovery and solutions development through the collaborative effort with the customer. Adaptive planning, evolutionary development, early delivery, continual improvement and flexible responses to changes in requirements are the key factors of Agile.
Continuity in terms of constantly communicating with the customer to discuss new requirements.
Continuity in terms of constantly releasing new versions of the product.
Product owner (PO)
Is the representative of the stakeholders and customers who use the software. He or she is a business strategist, designer, and user representative. He is in charge of explaining and sustaining the product's vision.\
Project Lead (Scrum Master)
To ensure seamless coordination of requirements, timelines, and releases, the Project Lead assumes direct responsibility for strategic planning and resource allocation. This central point of contact consistently liaises with clients and product owners, thus enabling the development team to concentrate on solving the technical challenges.\
Development Team (Dev)
A group of professionals with the necessary technical knowledge who realise the project jointly, carrying out the stories they commit to at the start of each release.
The Project Lead (Scrum Master) ensures that the project progresses smoothly, adheres to standards, remains within scope and budget, and ultimately fulfills its objectives, all while managing the various stakeholders involved.
For the PL this means continuous doing of:
A Team is usually staffed with this roles
Software Architect
Design and plan the architecture. In direct contact with the client for technical questions and support.
Cloud Application Engineer
Design and implement scalable, high performance cloud applications.
Mobile Application Engineer
Design and implement hybrid mobile applications; organize and manage AppStore deployments and updates.
DevOps
Manages your cloud applications resources and avaialibty, to provide a continues service and backup
Quality Assurance
Continously test and verify quality of the application.
This chapter provides a comprehensive overview of the entities and objects we have delineated to encompass all facets of software development and delivery, including the actual process itself.
In our methodology, "Features" are a crucial component that bridges the gap between basic tasks and the more intricate requirements of application development.
We identify and describe features early on in the planning phase. This helps us to ensure that we are all on the same page about what we are trying to achieve, and it also helps us to break down the project into smaller, more manageable tasks. In the end, features are a way of breaking down a complex project into smaller, more manageable pieces. This makes it easier to plan, track, and deliver a successful project.
Features are collaboratively authored by both clients and developers, ensuring a comprehensive and mutual understanding of each functionality and requirement. By detailing each feature extensively, we address the common problem of ambiguity in software development, enabling clearer communication and more accurate budgeting. This streamlines the workflow, leading to more efficient and effective project execution.
Features are also used to track the budget and resources that are allocated to each task. This helps us to make sure that we are not overspending on any one feature, and it also helps us to make sure that we have enough resources to complete all of the features that are identified.
Do you have any other questions?
Tasks are passing through a defined life-cycle of states, allowing us and the client to monitor their progress at any time.
Requirements & Planning
Open - Task was submitted and awaits Review.
Review - Currently in review by development team.
Feedback - Requires additional information from the client.
Hold - Currently not able to realise and for that not yet planable.
Pending - Awaiting assignment to an release.
Realisation
Planned - Assigned to an release and awaiting development.
Development - Currently in development.
Testing - In internal quality assurance phase.
Done - Task passed internal QA ready to be accepted by the client.
Quality Control
Accepted - Passed acceptance from the client and can be deployed on production.
Rejected - Failed acceptance and requires refinements.
Canceled - Canceled by the client.
We differentiate between 3 types of releases to further enhance the flexibility of implementing features while still maintaining the stability and continuity of the production application.
Contains stories and tasks which enhance the application with new features and functionalities. All of those require (as a rule of thumb) more then 4 hours to be implemented and are connected to a wider set of functionality. Those releases are generally longer in duration > 2 weeks as the complexity of tasks require the time to be implemented and tested. Tasks and delivery is planned in advance together with the client to control feature rollout timelines.
Refinements
Refinements discovered during acceptance phase will enhance the feature release with additional tasks that are collected separately in a release marked as "Refinements".
The agile counter part to our feature releases, short duration < 5 working days, issues and corrections which urgently need to be delivered to the client. This improves the stability and continuity of the current production application.
Used in case of a critical issue on any production application, containing one task solving the problem.
To monitor and track the current progress and state of a releases we defined following 8 states.
Every release (so called version) has predefinition numbering system so everyone can track progress.
Estimations can be done using various techniques such as expert judgment, analogy-based estimation, parametric estimation, Bottom-Up or Top-Down approaches, and using models like Function Point Analysis or COCOMO (Constructive Cost Model).
Accurate estimation is vital for project planning, setting client expectations, resource allocation, budgeting, and monitoring project progress. However, it is also challenging due to the uncertainty and variability of software development processes. Misestimation can lead to project delays, increased costs, and reduced quality, making it a crucial aspect of successful project management.
{% hint style="info" %} The calculated availability time per month is 120 hours per developer, 8h a day. {% endhint %}
Requirements (features, changes), issues are submitted via our service desk portal will be received in the form of a new task. According to their priority, they will be selected for review.
All received requirements and issues are internally reviewed by the development team, and the requirement realization time is estimated. If additional information is required, the client will receive a notification.
In this phase together with the client, task will be assigned to an appropriate type of release (as described in releases). This process is supported by the estimated implementation time of each task and also the available resources on each release, allowing us to plan the delivery time more precisely.
Actions when responding to sudden changes during Releases.
Every project lead, at some point, must face requirements changing within the on-going release. This can be a result of an impacting Bug, or urgent changes related to logical problems in the product.
Canceling the release and re-plan.
Find the balance without disturbing the flow of the release
(accept some changes, other move to next release, or cancel tasks).
Most importantly, in any case, the Project Lead (PL) first needs to communicate with the team to know what is or isn't possible. And then present the findings to the Client for finding an agreement
To provide a consistent delivery of features and maintain the stability of the application, we plan simultaneous releases.
The release containing new functionalities, estimated and assigned together with the client, has a delivery time of > 2 weeks.
Running parallel to the feature release, delivery every Thursday contains tasks, issues that require a quick reaction time and less effort.
Dynamically create when its required to fix a critical issue on production
{% hint style="warning" %} Production deployments between Monday and Thursday, for faster response related to issues that might occur. {% endhint %}
{% hint style="info" %} Continuously update the application (deploy production) to avoid a to big delta of functionality between the current production system and the latest available release. {% endhint %}
{% hint style="info" %} Tasks which require more then 2h for estimating the expected effort will need additional approval by the client. {% endhint %}
{% hint style="info" %} Tasks require a minimal set of information to be processed. {% endhint %}
{% hint style="info" %} Acceptance Test, should never fail for reasons of missing features that have not been planned in the Release. {% endhint %}
Quality over Quantity
Scrum development focuses on delivering a usable product to customers in every release. The focus is not on time and quantity rather on lunching well-tested and a fully functional product.
The release date is usually misled with end date of the product, but a releases are cycles that repeats itself and continue to extend the product.
The software lifecycle, often referred to as the Software Development Life Cycle (SDLC), describes the phases or stages a software system goes through, from its initial conception to its eventual retirement or replacement. It's a framework that describes the processes used to conceive, create, test, deploy, and maintain a software system.
Quality assurance (QA) is a way of preventing mistakes and defects in manufactured products which ISO 9000 defines as "part of quality management focused on providing confidence that quality requirements will be fulfilled.
During Quality Assurance, the Tester goes through all requirements and documentation to verify the correct function of the Product.
Functional
Every functionality of the system is tested by providing appropriate input, verifying the output, and comparing the actual results with the expected results.
White box testing
When we have all information about it and want to make code better.
Black box testing
When we test software from scratch, we don't have information or knowledge about the application, and we test it like a final customer.
Gray box testing
When we know something about — helpful to find o
bugs that user would not know about it.
Regression testing
Searching for bugs (with test documentation) — used mostly.
The primary goal of acceptance testing is to evaluate the system's compliance with the business requirements and assess whether it is acceptable for delivery. Acceptance is generally conductet on the staging system, prepared with the respective release. Our testing process is supporter and guided by our QA software.
Some key points about acceptance testing
Solving issues on staging during acceptance testing.
A TEST CASE is a set of actions executed to verify a particular feature or functionality of your software application. A Test Case contains test steps, test data, precondition, postcondition developed for specific test scenario to verify any requirement. The test case includes specific variables or conditions, using which a testing engineer can compare expected and actual results to determine whether a software product is functioning as per the requirements of the customer.
Critical — Very high Impact (Same day)
Customer facing service down, Privacy breached, data loss
Major - Significant Impact (24h)
Customer facing service down for a subset or functionality significantly impacted
Minor — Low Impact (24h / Next Release)
Minor inconvenience to customers, workaround available, Performance issuesIn other words, these are the problems that users of the software encounter during their normal operations after the software has been officially released and is live.
Its heart is a series of small behavior-preserving transformations.
The goal of refactoring is clear code that isn't copied, doesn't contain duplication, consists of only that code that's needed (less code), passes all test and it's easy to maintain.
Every 200 hours coding requires 20 hours of refactoring. Product features and deadlines should be planed accordingly.
Continues Integration
Continuous integration is the practice of constantly merging development work with a Master/Trunk/Main branch so that you can test changes and test that those changes work with other changes.
Continues Delivery
Continuous delivery is the continual delivery of code to an environment once the developer feels the code is ready to ship - The idea behind continuous delivery is that you're constantly delivering code to a user base, whether it be QA or directly to customers for continues "review and inspection.
Continues Deployment
Continuous deployment is the deployment or release of code to product on as soon as it's ready The production branch is always stable and ready to be deployed by an automated process
Refers to the environment where software developers write, test, and initially run the new code. It's the initial stage in the software lifecycle and is isolated from the production environment to ensure that ongoing development does not impact end-users or the live application. This structured progression ensures that potential issues are identified and rectified in controlled environments before reaching the final users.
(often just referred to as "staging") is an environment that closely mirrors the production system, allowing teams to simulate how changes will behave before they are released to the actual live environment.
Refers to the environment where software applications or systems are deployed, operated, and made available to end-users for actual use. It contrasts with other environments like development, testing, or staging. In the DevOps lifecycle, once code has been developed, tested, and approved through various stages, it's deployed to the production system, making it live.
Any changes or failures in the production system are critical since they directly affect the end-users, hence the emphasis on robust deployment and monitoring practices in DevOps to maintain the integrity and reliability of the production system.
Incident Support & Maintenance
Cloud and mobile applications, require constant maintenance and scheduled updates, for ensuring security and availability measures. Incidents reported via Service Desk interface are review during daily business hours. Resolving depends on incident level, measured by the overall systems availability.
Critical — Very high Impact (Same day)
Customer facing service down, Privacy breached, data loss
Major - Significant Impact (24h)
Customer facing service down for a subset or functionality significantly impacted
Minor — Low Impact (24h / Next Release)
Minor inconvenience to customers, workaround available, Performance issues