Development Process

Software Development Process

 

www.abac.software

Version [07.06.2025]

 

Disclaimer

 

This document describes the policies operated by abac.software for developing software solutions in favors of beneficiaries.

abac.software is operated by RED ABACUS DEVELOPMENT SRL, a Romanian company registered under nr. J12/2788/2016 in the Registry of Commerce, with unique business ID RO36345302, headquartered at 27 Gruia Street, 400171 Cluj-Napoca, Romania. Hereinafter referred to as “abac”, “we”, or other similar terms.

 

Introduction

 

Software solutions are developed by abac.software using two distinct collaboration models:

  • The Pipelined Development Model (or development performed in clearly defined phases)

  • The Flexible Development Model (or development performed continuously by an allocated team of experts)

 

 

Terminology

  • Beneficiary → The client or organization that contracts abac.software to deliver a software solution. Sometimes also referred to as the customer.

  • Deliverable → Any agreed output or milestone produced by abac.software in the course of a project. Examples include documentation (e.g. SRS, SDS), source code, binaries, configuration files, integrations, prototypes, or deployed environments.

  • Sources and Code → The human-readable programming code and associated assets used to build the software solution. Provided in formats suitable for maintenance, review, or further development.

  • Binaries → Compiled or packaged forms of the software that can be executed or deployed but are not intended for modification at the source level.

  • Environment → A configured software or hardware context in which the application runs. Examples include development, staging, or production environments. Environments typically include server setups, databases, and connected services necessary for the software to operate.

  • Iterations → Timeboxed development cycles (e.g. 2 weeks) used primarily in the Flexible Model. Each iteration includes planning, implementation, review, and delivery of specific functionality or improvements.

  • Work Order → A contractual document defining the scope, deliverables, timeline, and commercial terms for a specific phase or portion of work. Each work order is agreed and signed by both parties before work begins.

  • Scope → The set of requirements, features, and objectives agreed for a particular deliverable or phase. Clearly defining scope is essential to control costs, timelines, and acceptance criteria.

  • Acceptance → The formal confirmation by the Beneficiary that a deliverable or the complete project meets the agreed requirements. Acceptance triggers billing milestones and transitions (e.g. from development to warranty phase).

  • Integration → The process of connecting the developed software with external systems, services, or third-party APIs as specified in the project scope.

 

The Pipelined Model

The Pipelined Model is a structured, three-phase development strategy designed to move an idea from initial concept to working product in clear, contractual steps.

Each phase is contracted separately, with its own work order and deliverables. This approach ensures transparency, predictability, and freedom from vendor lock-in at every stage of the project.

Phase 1: Requirements Engineering

 

During this phase, we collaborate closely with the beneficiary to deeply understand the intended concept and document it clearly.

Key activities:

  • Defining both functional and non-functional requirements in a clear, standardised way

  • Aligning expectations on the core workflows of the application for each user type

  • Eliminating ambiguity before design or development begins

 

Key deliverables:

  • A Software Requirements Specification (SRS) document (in line with IEEE 29148)

  • A Functional Prototype (e.g. in Figma or Adobe XD) illustrating the look, feel, and behaviour of the product

Phase 2: Architecture Definition

This phase transforms the agreed SRS into a detailed technical design for the solution.

Key activities include:

  • Selecting the appropriate technologies

  • Defining system architecture and data structures

  • Designing integration points and technical components

Key deliverable:

  • A Software Design Specification (SDS) document (aligned with IEEE 42010:2022), serving as the blueprint for development

Phase 3: Development

In this final phase, we transform the agreed design into a working software product, ensuring all requirements are implemented to specification.

Key Activities:

  • Breaking down the system into incremental deliverables, typically aligned with billing milestones

  • Writing and testing source code based on the Software Design Specification

  • Configuring deployment environments and integrating with third-party services as required

  • Conducting internal quality assurance (QA) testing to verify each deliverable against agreed requirements

  • Collaborating with the client to review and validate each deliverable before moving to the next

Key Deliverables:

  • Technical assets: source code, binaries, documentation

  • Configuration setups: environments, third-party integrations

  • Incremental delivery packages: clearly scoped, reviewed, and accepted by the client at each step

  • Deployed solution: fully installed and configured on the client’s designated infrastructure, ready for acceptance testing

NOTE:

In most cases, development work is performed on abac.software’s own infrastructure. Deliverables are transferred to the beneficiary’s infrastructure (or accounts) only after all outstanding work orders are paid for and formally accepted. At that point, the intellectual property for the respective work order is transferred to the beneficiary.

Acceptance Process

Each deliverable produced during the development of each phase requires formal acceptance from the beneficiary. This structured approach ensures that both parties remain aligned throughout the project, reducing misunderstandings and keeping the work on track toward successful delivery.

How it works:

  • When a deliverable is ready, abac.software submits it to the client for review.

  • The client then has 10 working days to either:

    • Accept the deliverable, confirming it meets the agreed specifications, or

    • Submit a clear, consolidated list of specific reasons for non-acceptance.

If the client provides such a list within the 10-day window:

  • abac.software will evaluate the feedback and remedy the issues as quickly as possible.

  • The corrected deliverable is then resubmitted for acceptance.

  • This cycle (submission, review, remediation) continues until the deliverable is accepted or no new objections are raised within 5 working days, at which point the deliverable is deemed accepted automatically.

This is done in order to speed up the acceptance process and ensure that the development can proceed.

 

Once all individual deliverables have been formally accepted, abac.software will request final acceptance for the entire project.

This step confirms that the complete solution—as delivered, installed, and deployed on the client’s infrastructure—is approved and ready for operational use. Final acceptance is required to move the project into the warranty phase, during which qualifying defects will be remedied free of charge under our Warranty Policy.

The acceptance procedure for the final delivery works in the same structured way as for individual deliverables:

  • Upon requesting final acceptance, the client has 10 working days to either:

    • Formally accept the project, or

    • Submit a clear, consolidated list of specific issues preventing acceptance. 

  • If such a list is submitted within the 10-day window, abac.software will evaluate the feedback, address any valid issues, and resubmit for acceptance.

  • This cycle continues until acceptance is confirmed, or until 10 working days pass without new objections, at which point the project is automatically considered accepted.

 

NOTE: We kindly ask beneficiaries to conduct this review in good faith and avoid submitting claims that fall outside the project’s scope or requirements. The goal of this process is to ensure clarity, shared responsibility, and timely delivery—not to enable unnecessary delays or disputes. 

Transition to Warranty

Upon acceptance, the project enters its warranty period, during which certain types of defects identified in production use are remedied by abac.software free of charge (as defined in our Warranty Policy). During the Warranty period, submitted claims will be processed as stated in the Warranty Policy.

Advantages of the Pipelined Model

 

✅ Clear contractual structure with well-defined phases and deliverables

✅ Predictable costs and timelines, supporting effective budget planning

✅ Freedom from vendor lock-in, with the client able to evaluate continuation after each phase

Limitations of the Pipelined Model

 

⚠️ Less flexibility for major scope changes once phases have been agreed and contracted

⚠️ While small adjustments can often be accommodated (subject to abac.software’s agreement), significant changes may require revisiting earlier phases or issuing change orders

This model is best suited for projects where a high degree of planning, predictability, and cost control is required, and where the client is prepared to invest in clear specification work upfront to ensure development success.

2. The Flexible Model

The Flexible Model is a collaborative, adaptive development approach based on time-and-materials billing.

This model is designed for projects where requirements may evolve over time or where the client wants maximum control over priorities and capacity.

Instead of a fixed, contract-defined scope upfront, this approach enables continuous planning, iteration, and delivery, with the client directly shaping the work of the team.

Key Activities

  • Team Assembly: We assign qualified team members to the project in a time-and-material arrangement, tailored to the client’s needs.

  • Iteration Planning: Together with the client, we define development iterations of custom duration (typically 2 weeks), each with its own scope.

  • Scope Definition: At the start of each iteration, the client clearly specifies what should be delivered during that period.

  • Estimation and Planning: The team uses its known velocity (tasks achievable in a time frame) to help estimate, plan, and commit to the iteration scope.

  • Implementation: The team implements, tests, and prepares deliverables according to the agreed plan.

  • Demo Sessions: At the end of each iteration, we conduct a demo session with the client to review the work delivered and gather feedback.

  • Deployment: Deliverables are deployed to the client’s infrastructure at the end of each iteration.

  • Billing: The client pays for the actual cost of the team for each iteration.

Key Deliverables

  • Regular, incremental software features and improvements, delivered in alignment with the iteration goals

  • Demo sessions at the end of each iteration to review progress and outcomes

  • Deployed, tested functionality on the client’s infrastructure at the close of each cycle

  • Updated project backlog or task list, reprioritized as needed for the next iteration

Advantages of the Flexible Model

✅ High adaptability: Clients can adjust requirements, priorities, or scope at the start of any iteration

✅ Allows scaling team size or composition to meet evolving needs

✅ Promotes continuous feedback and alignment through regular demos

✅ Supports changing market or business conditions

Disadvantages of the Flexible Model

⚠️ No strict, fixed scope or deadline: It’s up to the client to monitor overall project trajectory

⚠️ Requires the client to actively participate in defining scope and priorities each iteration

⚠️ Without clear planning, there’s a risk of scope creep or inefficient use of capacity

⚠️ We recommend clients seek consulting support if they want help planning and managing a successful iterative process

 

This model is best suited for clients who value flexibility and control, and who are prepared to engage actively in shaping, prioritizing, and reviewing work throughout development.

3. Transitioning Between Models

We recognize that software projects often evolve in scope, complexity, and certainty over time. To support this, abac.software offers clients the flexibility to shift between our Pipelined Model and Flexible Model as the project demands.

How It Works

  • A beneficiary may opt to shift from one model to another after all in-progress deliverables have been delivered and formally accepted.

  • This ensures that work already underway is completed to spec and both sides have a clear, agreed baseline before changing approach.

  • A shift between models will typically involve reviewing and updating the scope, approach, and commercial terms in a new work order or agreement.

Why We Support This

Our goal is to grant customers maximum flexibility for building software solutions in a way that best matches their planning needs, budget constraints, and evolving understanding of requirements.

Examples of Shifting Models

✅ Starting with Pipelined, moving to Flexible:

  • Many projects begin with a structured, clearly specified phase (e.g. MVP development) using the Pipelined Model.

  • Once the core is stable, the client can shift to the Flexible Model for ongoing enhancements, iterations, or scaling.

✅ Starting or continuing in Flexible, then using Pipelined:

  • A client may want early exploration in a Flexible Model to define and refine features.

  • For particularly critical or high-impact modules, they may then switch to the Pipelined Model to ensure tight specification and control.

Key Principles

  • Clarity first: Each shift in model is formalized through clear agreements to ensure shared understanding and alignment.

  • No lock-in: Clients retain the freedom to choose the approach that suits them best at each stage.

  • Smooth transitions: abac.software supports clients in planning and managing these transitions effectively.

 

This approach ensures that each part of your project is built with the right level of flexibility, structure, and predictability, while maintaining professional discipline in delivery.