Acism carries out outsourced software development using the “X-SDLC” approach, often in the agile iterative way.

X-SDLC

X-SDLC stands for Xsemble-powered Software Development Life Cycle. It is granular, and allows you to put in better checks and balances to achieve success. The activities and various artifacts of X-SDLC can be seen in the following process flow diagram.

X-SDLC Process flow diagram
X-SDLC

Implications

  1. Aid in Planning and Tracking: Each activity in X-SDLC is a measurable goal, and hence a WBS (Work Breakdown Structure) can be created for a project for planning and tracking.
  2. Visibility into Working: The X-flowchart is an accurate and up-to-date visual model of how the software works. Because of that, it becomes a great visual reference for many stakeholders, such as the domain experts, the QA team and the support team.
  3. Flexibility: At Acism, we derive flexibility of three kinds through X-SDLC:
    1. Team Flexibility: Ability to quickly scale up and down the team. Acism maintains a community of freelancers who could contribute to parts of a project.
    2. Work Flexibility:
      1. Planning stage: Ability to let the client choose which activities they want to do
      2. Execution stage: Assigning and re-assigning tasks easily
    3. Budget Flexibility: Ability to let the client do a trade off between budget and other factors such as coordination effort.

Iterative “Agile” Development Process

A hallmark of Agile processes is the quick iterations (also called as sprints) in which work is delivered incrementally. X-SDLC being granular, it delivers a better model to run the various activities in parallel.

  • As an example, suppose your component development is being done for sprint 15.
  • In parallel, Xsemble design may be happening for sprint 16, so that it is ready for the development team by the time they complete the sprint 15 development.
  • Similarly, wireframes may be getting created for sprint 17, and requirements for sprint 18 may be getting finalized at the same time.
  • The downstream testing team may be testing the functionality released in sprint 14 release at this time.

Such parallelism delivers maximum efficiency.

Apart from the iterative approach, we have adopted other agile practices too, such as the scrum meeting, sprint planning, retrospective. It may be worth mentioning that a ready-made Kanban chart concerning components can be obtained from Xsemble.

Acism has the required process maturity and it is supported by adequate infrastructure (defect tracking, configuration management etc). For project collaboration, Acism uses an inhouse developed tool, Kommbox.

Billing models

  1. Fixed bid: Fixed charges are quoted against fixed scope of work. If the work changes, then the charges will also change.
  2. Time and Material: The manpower charges are fixed. You are billed as per the actual effort incurred, which could be (and in many cases, is) different from estimate.
  3. Retainer: Your monthly outgo is fixed against a reserved bandwidth of resources.
  4. Value based: The charges are defined upfront based on the value perceived by the customer.

The model that is most popular with the customers is fixed bid. However, some times it is not possible because the requirements are not captured clearly, or there are some technology risks that make the estimation difficult. In such cases, an extra phase to capture the requirements, or a study phase to build a technology Proof of Concept is inserted upfront before the estimate for the full software development can be given. Fixed bid structuring of an engagement also creates friction with parallelism.