Enhancements

We classify any modification or change to an existing software product as an enhancement. This includes any change in the scope of functionality supported by the current (or contractually defined) version of the software.

Enhancements include both minor and major changes. Major changes can be completely new functions or processes within existing modules, while minor changes might be adjustments to existing features.

Major changes tend to focus on supported processes and data flows, while minor changes tend to focus on user interface features, such as data entry fields, buttons and shortcuts.

New Products

We classify as new products both new applications that we build from scratch. These include both standalone applications, as well as new modules of an existing system that contains its own set of features, functions, and behavior.

From time to time, enhancement requests lead to the development of new products. This happens when a change request requires more than an improvement in an existing part of the system, but rather an entirely new functionality.

In such cases, that functionality is scoped as a new product, and we apply all of the development steps we use for new products, from requirements scoping and analysis to product design, implementation, integration, validation and release.

How We Process Requirements

We use a system called “Gemini” for all of our project management. Gemini is a web-based, third-party application for requirement and planning. It offers comprehensive ticketing and issue management features, and allows us to collect and process all types of requests from our customers and partners, as well as within D3S internally.

We divide Gemini into projects, one for each customer, and one for each of D3S’s internal projects. We create separate Gemini issues for each requirement, where we classify them according to their type, dependencies, and priority. Gemini automatically assigns each issue a unique number (ticket ID), which we use to track development progress.

How We Structure Requirements

Whether a requirement stems from market demands, business needs, customer requests, technological advances, legal/regulatory changes, or social changes, it ultimately needs to be translated into a task we can perform.

When formulated properly, requirements are:

• Cohesive (specifies only one thing at a time)Complete (self-contained, defining all situations that can be encountered and the appropriate response for each)
• Consistent (should not contradict other requirements and should not be repeated elsewhere
• Correct (mistakes in a requirement definition will result in a defective solution)
• Feasible (must be possible given system and project constraints)
• Mandatory (although requirements can have relative priority, they must all be “required”)
• Modifiable (if a change to a requirement is necessary, it should be expressed such that it is traceable)
• Unambiguous (avoid words like “more”, “less”, “fast”, “slow”)
• Testable (should be possible to design a test to determine if requirement has been met)

Types of Requirements

Requirements need to be clearly defined before we can analyse them. The main types of requirements include:

• Business requirements (provides a high-level, measurable statements of goals)
• Stakeholder requirements (states the needs or particular stakeholder or class of stakeholders)
• Solution Requirements (describes the characteristics of a solution, including functional and non-functional requirements)
• Transition requirements (describes what’s needed to transition from an old to a new system)

Project Vision

Requirements scoping starts with the project vision. The project vision expresses the purpose of the project. It provides a framework through which we understand the intention and needs.

The project vision is typically formulated as a list of statements. These statements summarize both the high-level business requirements (i.e. measurable statements of goals), as well as stakeholder requirements (statements of the needs of particular stakeholder or class of stakeholders).

Since requirements have many different sources, we work with customers to translate these statements into concrete, deliverable goals. When creating new products, we express these goals within a detailed User Requirements Specification. For enhancements, we may produce a Simplified Requirement Specification instead.

User Requirements Specification

The User Requirements Specification provides a detailed list of all the customer’s concrete needs. These details remove uncertainty as to how a system or application will accomplish its specific goals.

The URS includes all types of requirements but focuses in specific detail on the Solution Requirements. Solution Requirements describe the specific features and functions of a software product. And it breaks these down into two main categories:

• Functional Requirements (describing the behavior of the solution, as well as the information the solution will manage)
• Non-Functional Requirements (describing the environmental conditions under which the solution must remain effective, as well as the qualities the system must have – speed, security, availability, etc.)

The URS also describes the Transition Requirements. Transition requirements specify the capabilities needed to facilitate the transition from the current, actual state to a desired future state. Typically, this means managing the migration of data and users from an old system to a new system.

Since new systems often introduce new processes as well as new features and functions, transition requirements cover everything from data conversion to skill gaps and training. For this reason, a URS includes details current business processes.

Documenting the specification can be very complex. We provide clarity by including use case diagrams, which describe each operation a user might perform within the system, as well as data flow diagrams, which describe the data model and how information will flow from one part of the system to another.

Simplified Requirements Specification

An SRS is used exclusively for enhancements, and specifically for minor changes to an existing product. Because its scope is more limited, it focuses specifically on the Functional, Non-Functional, and Transition Requirements relevant to the change. High-level statements aren’t needed, in such cases, as the change typically falls within the scope of the existing project (and product) vision.

The post How We Manage Requirements appeared first on Inception CRM.

Requirements Analysis

Prior to designing any new software, or even changes to existing software products, we analyse all known requirements. We then create a “User Requirements Specification” to describe these requirements in as much detail as possible. The URS includes Business Requirements, Stakeholder Requirements, Functional and Non-Functional Solution Requirements, and Transition Requirements.

To learn more about how we manage requirements, click here.

Solution Design

By analysing requirements, we get a clear picture of what to develop. The solution design covers many areas, from the technical architecture to the technologies and components we use to build a solution.

It contains:

• Conceptual use cases
• Architecture of the solution
• Components
• Services
• Data Model
• Deployment model
• Management model

We formalize our understanding of the solution in a document known as a “Functional and Design Specification.”

Design Specification

The Functional and Design Specification provides a complete and highly-detailed description of the product that we plan to develop.

But where the Functional Specification addresses the Functional Requirements of the product, the Design Specification addresses the non-functional requirements. In this way, focuses on the overall solution design.

The Design Specification provides detailed information about the solution architecture, data model, supporting services, and the components that we will use to build the product. It clarifies what technical interfaces and services are needed to support the required its data flows.

The data model, in particular, accounts for all data flows within the application as well as to and from other systems. When a solution is connected to a separate system, the specification includes integration services.

Both the solution architecture, data model, and required services influence (and are influenced by) the required deployment model. The deployment model addresses such questions as:

• Will the solution be delivered as native applications or accessed via web browsers?
• For native applications, on which devices and operating systems do they need to run?
• Do its features need to be available offline, or delivered as service via the internet?
• If offline use is required, what scope of data and which features need to be available?
• What security measures are needed to protect data on the devices, and in transit?
• What type of personal data is being handled and how does it impact data privacy?

All of these considerations impact the deployment model that we design. They also impact the management model, which describes how the product will be managed (on a technical level) and administered (on user and data level).

Functional Specification

Unlike the Design Specification, the Functional Specification responds to the Functional Requirements contained in the URS. It describes all features and functions of the product itself, detailing not just what features the product will have, but also how they will behave.

As such, the Functional Specification covers everything from from navigation options to data operations, and describes all of the fields and interactions that need to be supported by the user interface.

The Functional Specification is informed by the Design Specification in that its features need to be consistent with the solution architecture, as well as the data, deployment and management models. At the same time, the Functional Specification informs design decisions by way of the functional requirements it supports.

Finally, the Functional Specification clarifies how the technologies and components described in the Design Specification will be implemented and behave. In this way, the Functional Specification is a cornerstone of the development plan in that it describes how the product itself will be implemented.

While the Functional Specification includes various “design” elements, such as user interface feature (GUI designs) and the features that support the user experience (UX designs), it is more focused the product’s look and feel rather than the overall design of the solution.

Traceability to Requirements

To support complete traceability from requirements to the delivered product, each part of the Functional and Design Specification provides clear references to each corresponding requirement in the User Requirements Specification (URS). By this way, we guarantee that the solutions we deliver fully satisfy their requirements.

The post How We Design New Software Products appeared first on Inception CRM.

Application Services

Application Development involves a complex set of services, which we generally refer to as “Application Services.”

Our first step, when developing new applications or new features within an existing application, is to collect requirements. Based on our analysis of these requirements, we prepare a development plan, which guides our design and implementation of the product.

At each stage of development, we test our work thoroughly to make sure our work meets the quality standards we’ve set. Once the development work is complete, we test the entire product (all features together) and validate according to defined acceptance criteria.

We approve a product for release only after it has been fully validated. Validation involves complete testing and qualification of the product. It also results in a comprehensive set of product documentation.

We support our customers’ key business functions by providing complete documentation in support of compliance, IT, and risk management.

Our app development and post-release support processes can be summarized as follows:

• Analysis of User Requirements Specifications (URS)
• Consultation with customers about the best way to achieve required functional fit
• Creation of Functional Specifications (FS) including data operations and the UI layer
• Creation of Design Specifications (DS)
• Design and Development (implementation of FS and DS)
• Parameterization (customization according to FS)
• Configuration (settings according to the URS)
• Application and Systems Integration (based on URS and FS)
• Testing and Validation
• Versioning and Release
• Support (entire lifecycle)
• Enhancements (continuous improvement)

Documentation and Regulatory Controls

We document the entire Software Lifecycle (URS > FS > DS > Development > Testing > Validation > Release) as part of our application services. However, since we develop applications in partnership with our customers, direction comes from the business areas who will use them.

As data stewards, our customers not only govern access for their users, they also help manage the policies and processes relating to the applications for their companies.

For higher-risk projects that fall under GAMP5 and/or GxP controls, we prepare special qualification documentation. These include installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ).

We prepare each of these qualification documents with reference to URS and FS, with traceability to the specific requirements contained within each, resulting in a fully-validated product.

Key Deliverables

As soon as a complete and detailed URS is prepared and signed-off, D3S prepares the following:

1. Functional Specifications (FS) detailing all functional requirements that must be developed in addition to the established or out-of-the-box software functions already in place
2. Design Specifications (DS) detailing the technologies and methodologies used to develop the various features described in the FS. This includes a description of the entire solution architecture, as well as the frontend features that determine the way an application looks and feels.
3. Functional Risk Assessment detailing the areas of high and low risk within the FS.
4. Validation Policy detailing all of the application functions or components that must be tested and validated (including how often, and according to which standards, validation must be performed; how validation is identified; and responsible persons, etc.)
5. Validation Protocols detailing the various validation activities / steps, including test cases (IQ, OQ, PQ / UAT).
6. Validation Reports summarizing the results of validation tests, once development is complete.

The post How We Develop New Products appeared first on Inception CRM.

D3S takes direct responsibility for its projects, even when employing the support of partners and subcontractors. We make sure our staff are available as needed for face-to-face meetings and discussions, either in person or remotely.

Each member of the project management team has clearly defined roles and responsibilities. Key management roles include:

• Sponsor (typically an executive staff member)
• Supervisor (typically a business director)
• Project Manager (typically a development director)
• Requirements Manager (typically an account manager)

For less complex projects, Account Managers might serve as both the project and requirements manager, with the development director responsible solely for assignment and delivery of technical work packages.

What We Deliver

1. Software product meeting all of a customer’s requirements for “functional fit” — resulting from development, customization, configuration and set up
2. User documentation including manuals and guides
3. End-to-end data migration covering data import and issue resolution
4. End-to-end interface service covering all critical 3rd-party systems
5. Integration testing covering all integrated components and services
6. User acceptance testing (usability tests)
7. User training and mentoring
8. Project Management (guidance, consultancy, project leadership and execution)

What We Expect From Our Customers

Ideally, our customers will always give us complete and detailed descriptions of their requirements. How, we know it’s not always possible for a customer to do this, so we work with them to get as much detail as we can.

Based on a rigorous needs assessment, we try to get as clear a picture as possible of the following:

• Business and End-user Requirements describing all known requirements. These include both high-level business requirements as well as detailed user requirements. High-level requirements often include the company’s security requirements and the business processes that need to be supported. User requirements mostly address the features and workflows required for “functional fit.”
  
• Core (or “common”) Data Structures including but not limited to core build definitions for activities, transactions and data processes. These data structures should be easily replicable with only minor modification/adjustment for individual installation instances.
  
• Clear Rules for all defined processes to be implemented as part of the core and within installation instances (e.g. country-level deployments). These can be delivered in the form of policies and SOPs reflecting company rules and expectations, or other forms of written guidance. They can also be provided orally by responsible business managers during scoping discussions and project meetings.
  
• Human Guidance throughout the lifecycle of the project. We hope our customers will be actively involved in our running projects. We depend on clients to answer questions, provide clarifications and data, and facilitate 3rd-party cooperation when needed.
  
• 1st Level Support for end users in local markets (however, if customer-internal 1st-level support is not available D3S can provide this for additional charge in markets where D3S resources are available).

The post How We Manage Projects appeared first on Inception CRM.

Integration Services provide integration from authoritative customer systems to internally- or externally-hosted systems. These services typically include the building of interfaces between a primary software system (such as Inception CRM) and external 3rd-party and internal back office systems, as well as apps that our customers to support their business functions and processes.

Integration requires many steps. The first of these is analysis of the systems that must be integrated and the data that must be exchanged. We create a URS that includes user interface requirements as well as the required data exchange. The latter specifies the data flows from and into the primary system.

After that, we map the data flows between all entities (data sources as well as consumers), and prepare the Functional Specification. The FS covers everything from interfaces to data operations and the UI layer. A Design Specification addresses the technical architecture of the solution and how all of the interface components will work together.

Finally, we prepare an implementation plan (usually with phases), and based on this, we get to work. The implementation phase includes data cleaning and validation, and is followed by integration testing and validation. Validation typically focuses on the technical interfaces and data operations.

The last step is the documentation, specifically, the preparation (and/or updating) of interface documentation. With working with external third-parties, like wholesalers and distributors (for example, to streamline order taking), the documentation serves as an important reference for troubleshooting and quality control throughout the life cycle of the project.

Importing Historical Data

We typically import historical data when customers are using our software to replace a legacy system, but want to keep all of their old records. Importing historical data from one system to another is a complex task with many steps and maintaining the integrity of transferred data is paramount.

Before we start importing data, we fully analyse the historical data we have to work with. This includes classifying each dataset in terms of its type, format, structure. Once that’s done, we can start mapping the data from the source system to its destination.

Once the mapping is complete, we design a data migration procedure and begin preparing import bridges. We import a sample of the data first in order to validate the procedure, and once we’re confident the data is being properly transfered, we import the full set of historical data.

Additional validation tasks are then performed to ensure that the transfered records are complete, consistent, and available for consumption. The last step is prepare and/or updating the interface documentation to make sure it is accurate, complete, and current.

Validating End User Environments

End user environment validation is a service we performed in order to confirm the suitability of end user devices for prior to software installation. It involves making sure the hardware, operating systems, and software components are able to support to the installed system. It also involves performance testing the software on the devices to make sure it runs smoothly.

In some cases, we recommend optimizing the environments. Optimizations can be as simple as updating deprecated components or clearing space to allow the software to perform better. For directly installed software (usually on Windows devices), we also prepare user images and pre-install supporting software that the system needs to run effectively.

The post How We Integrate Services appeared first on Inception CRM.

For each development project or version, we create a test plan that specifies:

• what need to be tested (issues)
• how it should be tested (which test types and test cases)
• which environments it should be tested in
• the number of test iterations to be performed

When results are ok, the version can go live. Otherwise, the issue is returned to the developer and new test iteration is planned.

Test protocols are always bound to a specific version and build; only failed test cases are retested.

Test Execution

D3S software developers perform the following tests prior to the release of any new software application or new software version (major or minor):

Unit Testing

Unit testing examines the individual functions of software components or modules, or the methods by which they are implemented, usually within a CI/CD process. Its goal to make sure that the functions both perform correctly, and that they were implemented properly.

Unit tests are written and executed by developers to test designed source code behavior they have written. We employ the following guidelines for all new code:

1. Always write a unit test for new code
2. Store unit test code in the source control as well as all the test data
3. Execute existing unit tests after performing change in the code covered by unit tests

Regression Testing

Regression testing looks at a subsystem, or part of an existing application, that was affected by recent changes in the version. Its goal is to confirm that the functionality hasn’t been adversely affected by the implemented changes.

System Testing

System testing focuses on an entire system or application. It mainly looks for bugs, but also for any conflicts that might be generated by new features, some of which may have been compiled together for the first time.

Integration Testing

Integration tests check the interoperability of all systems that either communicate together or exchange data with each other. These include 3rd-party APIs, as well custom-built data exchanges.

UX Testing

UX (or “user experience”) testing evaluates the usability of an app. Its goal is to make sure the app is comfortable to use per the defined use cases and workflows. UX testing is usually done for brand new app, new modules within an existing system of application, and for new features that include a new UI element. UX Testing includes GUI Testing.

GUI Testing

GUI (or “graphic user interface”) testing focuses on the UI to make sure fonts, styles and layouts (all visual elements) are properly displayed. GUI testing is especially important when new features are added, or when a new device needs to be supported that has a different screen size or resolution.

Load and Performance Testing

Load and Performance testing measures load performance of web-based or client-server applications. It focuses on how well the system/app perform in a live scenario. Performance testing is usually done in the alpha or beta testing phases (or both, depending on the type of app) as a final check before final production release / go-live.

Acceptance Testing

Acceptance testing (often referred to as “UAT” or user acceptance testing) is usually the last part of the application development process. It ensures that the application or delivered software product meets the customer’s expectations by performing as expected in the field. Acceptance testing is usually conducted by the customer as part of UAT sign-off before the application is released live.

Security Testing

Security testing focuses on the security of the application and its data. Security testing covers a wide range of objectives and employs many different methods, depending on its obectives. Pen tests are used to evaluate network security, while OWASP tests check the security of web applications, IPA files (for iOS/iPadOS app), and APK file (for Android apps).

Most security tests are performed via automated checks, using advanced security testing software dedicated to that purpose. For business apps, final security testing is usually done by mobile app deployment teams on the customer side prior to production release.

The post How We Test Our Products appeared first on Inception CRM.

For existing products, we collect requirements and assign them into product versions. We assign enhancement requirements to “major” release versions, and we assign bug fixes to “minor” (patch) versions, usually in support of a Service Level Agreement (SLA). We resolve critical bugs through hotfixes.

Types of Versions

When planning a new version of an existing software product (for example, Inception CRM), we focus on two main types of version: Major and Minor. A third type of version is the “Hotfix” or emergency release, which focuses on solving a specific critical problem.

Major Version

Major versions focus on major releases and typically introduce new features to a solution. A major version means that the impacts of changes (additions, modifications, deletions of named functions) affect the entire software system, or at least a significant part of it.

While the code level change may be limited to a specific function, the interrelation of functions within the system (especially in terms of hierarchy of objects, from simple to complex) requires us to thoroughly test the whole application.

For Inception CRM, we produce three major versions per year. These major versions introduce many new features and functions and often significantly upgrade previously implemented functions according to new technology standards and practices.

Minor Version

Minor versions focus on small changes to existing features. A minor version means that the impacts of changes affect only the specification function(s) being modified or changed, or have limited extended impact to surrounding or integrally related functions and dependent functions.

When testing changes in a minor version, we test the modified function along with any dependent functions. Since a minor version is usually a patch version, it contains rarely enhancements.

Hotfix

When we assign a hotfix to a developer, the developer resolves the problem immediately, and if necessary, creates a new issue with a requirement for a systematic change that will prevent the problem from reappearing.

The Steps for Planning a Version

Version planning includes:

• agreement on release date of new version
• agreement on priority of issues (critical to low) in regards to their importance to customers/stakeholders and their urgency
• assessment of available capacity (by the Project Manager)
• selection of customer issues based on priority/urgency within the limit of available capacity during the defined time plan
• linking of selected customer issues to version issue
• assignment of customer issues to development team leaders
• assignment of customer issues to individual developers
• informing developers of their assigned duties related to the version (automatic, from Gemini via email)
• evaluation of progress in weekly meetings
• during planning meetings, agreement is reached concerning:
  • which customer issues will be included in the version
  • time plan for version testing and release (testing performed by different role groups)
  • commenting on the progress of each issue linked to the version
  • updating of issue status based on progress
  • commenting on the issue (may require adjustment of URS/ITS)

We do not include issues that have not been analyzed in any planned version.

Versioning schema

The version number follows Best Practices for .NET Assembly Versioning:

Major Version: Manually incremented for major releases, such as adding many new features to the solution. Major versions are named by years of the version release.

Minor Version: Manually incremented for minor releases, such as introducing small changes to existing features. Minor versions have the order number of the release within a year.

Build Number: Typically incremented automatically as part of every build performed on the Build Server. This allows each build to be tracked and tested.

Revision: Incremented for QFEs (a.k.a. “hotfixes” or patches) to builds released into the Production environment (PROD). This is set to zero for the initial release of any major/minor version of the solution.

For example, major version is 2020.3.0.0, minor version is 2020.3.2.5.

Deployment

Deployment is driven by a project/version Release Plan. The deployment manager knows

• time schedule for testing (i.e. when the version should be deployed to the test environment)
• release date
• environments (customers) to deploy
• applications to deploy
• deployment procedure (how to, including if there is planned downtime of the services)

All applications are built using the automated build procedure that creates deployment packages. D3S uses a tailored in-house deployment application (called ServerDeployer) that enables automatic deployment (distribution) of application packages to the defined environments of selected customers.

General deployment steps include:

• configuring which builds of which application should be deployed
• [optional] downtime of services (for production environment)
• launching the ServerDeployer application
• starting the deployment
• when it finishes, checking for possible deployment errors
• fixing any problems (in case of severe problems, we rollback the deployment)
• [optional] end downtime of service (for production environment)
• fill the Release protocol

The post How We Manage Versions appeared first on Inception CRM.

We store all source codes in professional source control systems. These systems are located in a secure, professional hosting environment. We use Git Lab as our primary source control system. We manage access rights separately for each project, and access to the source control system is excusively via a configured VPN. External developers have only limited access to source codes.

Source Code Change Procedure

The source control system (Git Lab) stores source codes for all D3S projects. The general guidelines recommended for all projects are as follows:

When submitting code to the source control, developers should comment on the submitted code; their comments must include the issue number from Gemini for easier traceability of the requirement.

Developers are permitted to submit only working code (see the Implementation Checklist). For temporary storage of source code, we use the shelving feature of Git Lab.

Developers are not allowed to submit source changes to production build branch of the source control. Instead, they must use development branches and merge the change later.

Continuous Integration & Build

To support automated application deployment, all projects use Continuous Integration and Build on a dedicated build machine.

Version Management

Our software development plans for major and minor versions includes project milestones, resources, dependencies, and risk management.

Click here to learn about how we plan and manage new versions of our software products.

Implementation Checklist

We provide the following checklist as guidance for all developers to help them manage and check their own work:

• Coding complete

This includes source code, as well as database scripts, etc. Always submit complete and working code.

• Check completeness against requirements

Read again what was required and compare with what you have implemented.

• Compare your changes

Compare changes against previous version (both code and database scripts) before submit. It is a good practice to separate source code for an issue from the other files. Revert unchanged files and ensure you submit all necessary files.

• Run a “Turkey Test”

If there is a change your code will run in another language, with a non-Latin alphabet, or in non-Latin environment, check your code carefully. In Turkish, for example, the letters i and I are different. This applies also for databases. If you have a database with a Turkish collate, always check the query on this database.

• Run the code in the debugger/write unit tests

Never think your code will work without being tested.

• Run code analysis and correct findings

Run the code analysis in Visual Studio and fix relevant warning/errors.

• Create/update internal technical documentation

Create or update relevant info (e.g. new settings, behavior, new screenshots).

• Test the final code at own developer machine

Test the scenario at your own development machine.

• Consider getting a code review (with findings processed)

Think about the risks of your code changes. If you are not sure, ask for code review.

• Consider creating load test/create a load test

Think if a load test is necessary or required.

• Consider writing and automated UI test/create one and run it

Think if you can use automated UI test.

• Update build configuration

Check if you need to update deployment parameters. Check if default configuration is ok.

• Submit to source control with recommended label

Submit source files with issue number. Do not submit database scripts and source code together, split them into two submits. Submit separately also technical documentation update.

• Ensure the build of your code succeeds

Check central build complete successfully with you change.

• Log time spent on the issue

Do not forget to report your time on the issue. This should be done every day if the task is longer.

• Update issue status in Gemini (ticketing & issue management system)

Set implemented status for the issue you have just finished.

Code Review

We perform Code Review either during development, prior to submission of code to the source control, or after submission to the source control by evaluating the changes to the source code against the previous version.

We perform Code Review for any code that impacts system-wide functionality or the degree of availability, integrity, confidentiality, speed, memory consumption, users, API, and security. We use a risk matrix to help determine when code reviews are required.

We also conduct code reviews any time an assigned developer and/or their Team Leader thinks code review may be required. We encourage all developers to have their code reviewed regularly or with each submission, regardless of the classification of the submitted code.

General Approach to Testing

Our general strategy is to have developers test their work (especially deployed applications) before they hand it off to testers. Testing of a given developer’s work is conducted by another developer with similar or related skill-set and availability. This is typically a member of the same team as the developer who is assigned the work. This approach radically improves the quality of testing and decreases the number test iterations.

Click here to read more about our test methods and procedures.

The post How We Manage Source Code appeared first on Inception CRM.

Quality Assurance requires a lot of documentation. But it’s not documentation for the sake of documentation. Good documentation helps manage expectations and brings clarity to the budget. It also helps us define the development approach best suited to the project.

For each project, we precisely describe requirements and their acceptance criteria. Risk Management is an integral part of this, as is validation. To make sure a product works properly, we test every component against its requirement, and we test the entire product against any identified risks.

We also follow best practices for software development. We use international programming standards and review all of our code before releasing it. And we use professional tools for source control, versioning, testing and deployment to make sure there are no hiccups along the way.

Programming Standards

As most of our products are based on Microsoft .NET platform, we follow Microsoft .NET Framework Guidelines and Best Practices for writing source code.

The basic development tool is Microsoft Visual Studio, an integrated development environment that enables developers to design, develop, debug, make unit tests, prepare automated load tests, analyze runtime problems.

Code Reviewing

We perform code reviews either during development, prior to the submission of code to the source control, or after submission to the source control by evaluating the changes to the source code against the previous version.

Code review is performed for any code that impacts system-wide functionality or the degree of availability, integrity, confidentiality, speed, memory consumption, users, API, and security.

Requirements Specifications

Requirements specifications include the customer’s requirements as well as the features of the product we’re delivering.

User Requirements

The User Requirements Specification (or “URS”) contains all of a customer’s high-level and specific needs. It describes both functional and non-functional requirements, from interface design to the customer’s password policy. It’s the basis for all of the work that follows.

Functional Requirements

Functional requirements specify the required functions. They are captured in a Functional and Design Specification (“FSDS”). The FSDS precisely describes all of the features and functions of a delivered product according to its required use cases.

This includes both system behaviors and workflows, as well as an app’s look and feel. Each feature and function is connected to its corresponding user requirement to make sure nothing is missed.

Non-Functional Requirements

We address non-functional requirements, such as security and availability, in a Technology and Solution Architecture specification (or “TSA”). The TSA lists all of the technologies that will be used to develop, build and deploy a software product.

The TSA covers everything from the deployment model to the frameworks, coding languages, GUI components and software libraries used to make the product. It also describes the technical infrastructure, hosting (in case of client-server applications), and any connected or 3rd-party services.

Development Approach

Customer requirements generally determine our development approach. They tell us what technologies to use and how to deploy the product once its ready to be released. During development, we refine the product’s design according to the limits and possibilities of the selected tools.

Key factors that determine our development approach are the deployment model and connected services. System deployment and Installation follow the technical hardware and software configuration requirements for the product.

Native apps for iOS, Android, Windows and web browsers, for example, each require different technologies and deployment methods. Client-server applications have more dependencies than standalone applications, as do apps connected to third-party services.

Data Migration

In case the product is connected to external data services, we create additional specifications for data migration. The Data Migration Specification covers a wide range of requirements for the data migration process, including:

• Defining business rules for data validation, cleansing and transformation
• Defining business rules for data input
• Executing data cleansing according to business rules, supporting data input processes and resolving data quality queries
• Selecting a data modeling tool with reverse engineering capability (e.g. ERWin)
• Identifying all required data sources and the owner of each source
• Establishing data feeds
• Identifying (inactive and active) legacy systems and operational data stores
• Defining the data items required (customer definitions)
• Creating data models for the source data

Data Migration is a complex process than involves a number of steps, including:

• Selecting a data migration tool
• Creating extract files for each data source
• Resolving any errors identified by users (administrators)
• Creating extracts and performing data clean up
• Completing the migration (extract, transform and load) for each data source
• Running acceptance tests on the integrated target database (incl./esp. referential integrity)

Acceptance Criteria

To ensure the quality of our products, we establish acceptance criteria. The requirements for performance, safety, and testing determine what the acceptance criteria look like. We then test all of our acceptance criteria in order to ensure make sure the products meet the quality requirements.

These tests, which cover everything from development to installation and performance, form the basis of our quality guarantee. They also establish the parameters for a product’s quality documentation.

Test Plan

Defining testing methodologies to be carried out in each stage of the development project (as defined in the test documentation for each development stage) is critical to the success of a project. Major areas of testing that we address in our test plans include:

• Development testing
• Installation testing
• Operational testing
• Performance testing

Functional Risk Assessment

We assess functional risk once we’ve finalized the functional specification. We take into account everything that can go wrong in a live scenario and prepare ways to mitigate those risks in advance. As a result, the functional specification might be updated to account for any new features that we need to implement to address potential risks.

However, the main output of the functional risk assessment is the product validation strategy. A key part of this is testing. The best way to mitigate risk is simply to test any bugs, errors or unwanted behaviors out of the app. To that end, we prepare a robust testing plan that covers all important areas of the system.

Product Validation

Testing is a key component of product validation. It involves many separate testing activities, beyond those conducted by developers. While unit testing and code reviews are important, these are more routine functions.

Product validation, on the other hand, focuses more on the quality documentation that needs to be produced. This documentation provides important evidence that the product works as expected, and that quality has been assured.

Validation Policy

The validation policy provides the scope for all the tests we conduct as part of the validation process. It identifies the types quality documents we need to produce, as well as their structure and contents.

In most cases, the validation policy defines the document structure and contents for Installation Qualification (IQ), Operation Qualification (OQ) and Performance Qualification (PQ). Each qualification contain its own validation protocols and test cases.

Validation Protocols

Validation protocols are essentially all of the test plans that we need to carry out in order to ensure product quality. We validate our software according by following the test cases described in each plan. Each test case has its own steps, which allow any developer to replicate another developers test to confirm that everything is working well.

We design test cases to confirm a number of things. One of them is product functionality (i.e., that we’ve delivered all required features and they are working properly). Another is product usability (i.e., how well does it perform in a live scenario). And a third is functional risk.

Validating a product against risks is important. It asks us to check whether any of the identified risks appear, and if so, to see how effectively the mitigation strategy addresses them. For example, if a connected service fails, does the user have a way to easily reboot it?

Change Management

A product is released only once it has met all acceptance criteria and passed validation checks. However, it is normal for products to evolve after their initial release as new requirements are introduced.

Change control and configuration and change management follow similar procedures as initial development and release. This means that new requirements are define and a new development plan is established.

After that, new acceptance criteria are defined and the product is tested until they’re met. The new version is released only after complete validation of the entire product.

The post How We Manage Quality appeared first on Inception CRM.

Risk Management

D3S manages risk at both the development and service levels to make sure all of our software works perfectly. When implementing a new product, or enhancing an existing one, we assess all of its features and functions for functional risk.

Based on the risks we’ve identified, we test all potentially-impacted features and functions. We document our tests in so-called “validation protocols,” which are connected to a validation policy. The output these tests is quality assurance (QA).

Once a product is released, we document the areas of the system that are high risk. Based on this we establish priorities for repeated testing. This helps us guarantee the quality of our work. It also helps us make sure that all agreed deliverables are met on a continuing basis.

Through regular testing, we can identify any bugs or undocumented behaviors and resolve them in a timely fashion. The Service Level Agreement (SLA) sets the specific benchmarks for this service. Per the terms of the SLA, we escalate issues as needed to make sure they’re resolved on time, according to their importance and severity.

The post How We Manage Risk appeared first on Inception CRM.