Processes at DRC Systems - is not our policy but habit and an on going journey
The Team DRC has imbibed the systems and processes in every walk, be it applying for leaves, holding meetings, gathering requirement to delivery of the project. Even the new recruit takes this as duck to water for optimum output. This enables us to deliver at the precise quality as the customer’s requirement.
- User interface HTML prototype
- Class specification
- Test cases
- Bug Report
- Project Delivery checklist and Setup plan
- Change Request Note and Change Impact Analysis
- System Requirements
System requirement document is all about giving a patient hearing to understand and capture the requirements of the customer. Here we act as a good listener and observer to note the customer's pain areas, the needs and all that the customer expects out of the new software solution.
At DRC Systems, we consider this phase as one of the most crucial stages. We have realized and understood the fact that timely information and patience in gathering the data helps to bridge the gap between the expected and desired output. It forms the basis for the development team and also helps the estimation team to come to a conclusion on time and budget. The more the time spent in this phase more nearer are the fruits of project closing and successful execution. This can be realized from the fact that more time spent in this phase, the clearer is the information and the chances of the ambiguity is less.
Also, in this stage, we try and capture all the functional processes and methodologies addressed through the current application and then what are the new enhancements that the customer requires in the new system.
Also, since this document forms a basis of agreement between the development team and the customer, we take care to see that language, information and all the other characteristic of the documents are kept in synch for easy understating of the customer and its team members.
To see that there is no stone left unturned, we see to it that at the end of the completion of information gathering process, from whatever best has been taken down, there is room for assumptions and dependencies of the information. This is just in case to overcome and avoid the discrepancies of the situation where the teams start blaming each other for not implementing or executing the tasks.
The basic issues that we address in the system requirement document are:
- Functional requirements
- Non functional requirements
- External interface requirements
- Other miscellaneous requirements
- Project Charter
Project charter forms the road map of the project and guides the project in a particular direction. It indicates the understanding of the purpose and also defines the statement of the scope, objectives and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.
The Project Manager creates the Project Charter in the Initiation Phase of the Project, in consultation with the Business Manager. Its purpose is to recognize the existence of the project and to begin the planning process required to accomplish the Project goals.
At DRC Systems, Project Charter would typically act as an internal document that confine to detail planning with information like scope, deliverables, assumptions, roles and responsibilities etc.
In this stage we plan to define the following information:
- Problem statement
- Project goals and objectives
- Project scope
- Critical success factors
- Risks list
- Assumptions
- Constraints
- Milestones and deliverables
- Roles and responsibilities
- Escalation procedure and threshold time
- Communication contact points
- Functional Requirements Specification
As the name suggests, this document takes care of the detailed specification and is supposed to be next higher, detailed version of the requirement documents. Within this document, we try to be more specific and take care of all the minute information as far as possible. From the development point of view, this document is the technical document that has all the minor details of business modules/functions. It takes care of the processes in place and its dependencies, database elements, traceability, impact of changes etc.
At DRC Systems, we term the functional requirement document as the bible for the software development process. We try to be more specific by defining functions with the set of inputs, the processes and the desired output.
- Use Cases and class diagram
Use cases are useful in capturing and communicating functional requirements, and as such they play a primary role in project definition.
Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with much technical information. A complete set of use cases specifies all the different ways to use the system, and therefore defines all behavior required for the system, bounding the scope of the system.
Currently, we maintain use cases in simple excel sheet showing relationship between user and the system.
- Process Flow Diagrams
We translate the information captured during the system requirement and functional specification phase into the flow charts. If the database already exists, we even try to define the pointer like where the data is inserted, into which field and at what stage it is processed. The process flow diagrams or the flow charts are graphical representation defining all the processes.
At DRC Systems, based on the size, time and budget of the project, we try to fulfill this stage and agree to the reality that this stage too helps in bringing lot of clarity towards the system output and minimize the chances of mistakes.
- ERDs
ERD is a modeling technique that represents a logical design of a particular business process. Each entity has attributes and different entities are connected through primary key/foreign key relationships.
Entity-Relation Diagram is a high level data model that includes all major entities and relationships. Its importance is held high for complex projects with large databases with complex business logic and structures.
For the smaller projects, at DRC Systems, we try and capture most of the information pertaining to the database from the Data Dictionary whereas for the complicated projects with complex architecture, ERD is inevitable and we follow the same. The tool used to define and prepare ERD is MS Visio.
- Data Dictionaries
Data dictionary clearly defines the tables, its fields and the field characteristics. Also, it takes care of the field definitions and description.
At DRC Systems, we maintain this through excel sheet with all the tables and field information.
- User interface HTML prototype
At DRC Systems, this stage holds equal importance and one of the critical factors for the successful execution of the project. In this stage or the process, we focus mainly on the usability trends and convenience part for the end users. The information is collected with the involvement of the end users while having continuous interaction with the other team members.
The concentration is on developing attractive applications design while keeping in mind the objectives and goals. We allow user to have the first hand feel of the application. In short, we can term it as a non functional working HTML or a mock functionality which just gives you the flow of the processes. It just demonstrates what elements a web page or application screen will contain. The feedback in this stage is key to the next stage of the development. An approval to the prototype would essentially mean that the requirements are captured and there are no further changes at this stage.
The benefits that can be derived from this stage would be simplified implementation, reaching near to the client’s expectation, eliminating ambiguity, clarity of thoughts and ideas etc.
- Class specification
Class specification acts like a feeder to the development team and an initial technical input phase before we start coding. The specification here is intended to be providing to the intended user with all the set of information that they will need to develop program correctly.
The specification must be sufficiently formal that it can conceivably be machine tested for consistency, completeness and other desirable properties of a specification.
It includes Revision History, detail functionality description, Properties variables, Database Functions used in this class, Functions used in this class (Input Parameters, Return type , Global/Session/ Class Used)
- Test cases
One of the few basic steps towards a good testing methodology would be to define the test cases. A test case would essentially be a component that describes the inputs, followed by actions and processes and finally the expected output.
The basic objective of writing test cases is to validate the testing coverage of the application. We strongly advocate the matter of writing test cases as this leads to some sort of standardization and minimizes the ad-hoc approach in testing.
At DRC Systems, we follow this process of defining the test cases and then submitting the report (if desired by the customer) as a part of quality testing.
- Bug Report
Bugs are part and parcel of any software but yet can be minimized through judicious efforts and systematic approach. We follow a simple yet elaborative bug tracking and reporting system. As soon as a bug is reported, we try and capture the following information:
- Bug Id
- Module
- Bug Description
- Severity
- Priority
- Whom to Assign
- Bug Reported Date
- Bug Resolved Date / Last Updated Status
After resolving the bugs, we include this as apart of project release plan and cross check the same before the release notes are to be sent to the client.
- Project Delivery checklist and Setup plan
Within the Project Delivery checklist, we take care of the following points before releasing the final deliverables:
- Check all the documents required for submission during the deliverables
- Check for the versioning with the final version information
- Remove Debugging and test code from the software
- Include the Quality check report
- Release Notes with details, if required
- Include copyright, license, legal material, any third party software license and agreements to be included.
- Change Request Note and Change Impact Analysis
It is an acceptable fact that Change requests, whether the client terms it as a change or not, are surely bound and part of the software development process. We do accept and respect the client’s requirement for change. Following the change request, we maintain a proper document for the same.
To Start with, we take care of the following steps:
- Prepare a change request note with the following information:
- Schedule Impact
- Cost Impact
- Quality Impact to any deliverables
- Change request ID
- Module
- Description
- From whom the request is sent
- Priority to be assigned
Before actually executing the Change request, we ask our development team to evaluate the change request so as to know the impacts occurring due to this change like changes in the database, changes in design, changes in processes, etc. The impact analysis report is sent to the Project Manager for the approval for time, authority, team/s to be assigned changes and then executed. Also care is taken that back to back all the relevant documents are modified to capture the new changes and documents like ERD, Data dictionary, Flow charts are updated simultaneously.
- Prepare a change request note with the following information:
