At cyberThink InfoTech Pvt. Ltd., the project development methodology and approach followed, depends upon an assortment of factors. We follow traditional waterfall model, prototyping model, or iterative RUP methodologies, depending on the project’s type.
We have a set of well-defined software engineering processes for software development life cycle. Each of these processes, ranging from requirements to release, is based on industry-standard software development practices. Our processes evolved over a period, to incorporate best practices in requirements management, project management and oversight, design methods and testing methodologies and tools.
We are equipped with a comprehensive Quality Management System (QMS) comprising of Organizational Standard Software Development Processes, Departmental processes like HR and Information Systems (HRIS), Artifacts for each process (process assets) and its related reference documents like Organizational coding guidelines, Review Guidelines etc.
After analyzing the client's requirements in detail and based on the interactions with the Project Team, we work with the most appropriate approach that suits our customer’s needs.
The approach, we prefer is dividing the entire project into a number of process iterations, each one having its own set of requirements, design, development, testing and implementation phases.
A behavioral prototype enables CIPL to build a product model by showing something concrete and executable to users, customers, managers, and stakeholders.
We follow stringent communication techniques for projects in our offshore model. We have state-of-the-art communication infrastructure facilities to communicate with our client on a daily basis for their requirements, project status updates, and other project-specific details.
We propose to follow the development approach as described below:
Requirements are gathered using industry-standard practices and reviewed both internally by peers and externally by clients, and findings of reviews are tracked to closure. Once these requirements are frozen, the development work begins.
All the requirements are numbered at the onset so that they are tagged for identification and documented accurately in the design document. Each requirement is assigned a Requirements ID, which is further used to track the requirement from definition, design, implementation, and testing phases. This also helps to easily track and verify that all the requirements are catered or not.
B. Project Management
A project kick-off meeting marks the beginning of the project. A comprehensive Project plan is prepared, which outlines all the critical aspects related to the smooth project execution. These include:
General Planning and Milestones
Scope Management
Team formation and Engagement
Integration Planning
Communication Planning
Quality Management
Risk Management and Mitigation
Procurements Management
Tracking and Control Mechanisms
Detailed Schedule (We use MS PROJECT as our primary scheduling tool)
The Process tailoring is also an important part of this phase. One process doesn’t fit for all, hence adjustments might required. PM and SQA refer to organizational process tailoring guidelines and tailor the process according to it. SQA ensures that processes are tailored appropriately to meet the needs of the project based on the type and size. After then, the tailored process is documented in the Project Plan.
C. Detailed Design
Detail Design defines and maps the entire system in details, as well as the functional process flow.
The content of the design document contains the following main items:
Block Diagram
Overall System Architecture
Class Diagram
Screen Shots and field Validations
Flow diagram/Sequence Diagram
Database Diagram
Deployment View
For entire functionality, we use Microsoft Visio for architecture and database design. Before the design is finally approved, it is exhaustively reviewed by Technical Leaders and System Architects. Design specific errors are identified and resolved. The detailed design can also be given to the customer for review, if required.
Here, actual coding activities are done according to the organizational coding guidelines for different technologies. Internal and inline commenting is done along with the coding activity. Completion of each module results in preparation of test cases and unit level testing. Code reviews are also done to ensure that the developed code adheres to the organizational guidelines for coding.
Code Reviews are done upon completion of each software unit. This ensures that coding is done according to laid out guidelines and that code is readable, clean, and maintainable.
E. Testing
Various levels of testing have been defined and followed by CIPL:
Unit Testing
Functional Testing
Integrated Testing
System Testing
Acceptance Testing
Test Planning is done at the onset of the project in the project-planning phase. The Test plan outlines the types of test to be performed, resources, tools, and responsibilities for test related activities.
For unit testing, the developers are made responsible for the quality of the module they are developing. At different levels and for different kind of projects, we use unit-testing tools like NUnit for .NET framework and JUnit for Java based applications.
For functional testing, test cases are generated and filled with data and supplied to the QA team.
During the integrated testing the entire application is deployed on the testing infrastructure and then various aspects of the application such as the platform support, browser support etc. are considered. Here some automated tools and stress testing tools are also used.
The final User Acceptance Testing (UAT) is also a very important procedure, which is done in phases by the client, before accepting the complete delivery of the application. Processes for projects are continuously verified and monitored by the SQA and senior team members of the project to ensure that the defined processes are followed to streamline the development and enhance the effectiveness.
Risk Management
Prior to commencement of the project, we follow an approach wherein all known risks specific to the project are identified and documented. The Risk Management Section of the Project Plan is generated, where all possible foreseen risks and their contingencies are documented and addressed.
Each risk is given a Risk ID, and has a risk category, occurrence probability, consequences, and mitigation strategy. Risks are assessed throughout the execution to identify any new risks that may occur. This assists us to visualize the possible problem areas and address them right at the onset.
For risks associated with delay in client feedback, we propose to have a dedicated Engagement Manager (can be anyone from client side) at the clients end to ensure faster approval, review and feedback process.
";
if($exit == 1)
exit;
}
return $db_rec_row_array;
}
//use to insert record
function insert($query,$debug=0)
{
if(trim($query) == "")
die("Query is Empty: ".mysql_error());
/*
This is used to check that query has insert word or not
If you try to execute other types of query in that case this will give the error
*/
if(!preg_match("/^insert/i",$query))
die(" Invalid Query: ".$query." ");
$this->result = mysql_query($query,$this->links);
if(!$this->result)
die(" Result Erorr: ".mysql_error()." ".$query." ");
/*
This is used to debug the code and print the query
You have to pass 1 (one) as the second argument of the edit function
Default is $debug 0 set.
*/
if($debug == 1)
{
print "
";
exit;
}
return $this->result;
}
//use to update record
function update($query,$debug=0)
{
if(trim($query) == "")
die("Query is Empty: ".mysql_error());
/*
This is used to check that query has update word or not
If you try to execute other types of query in that case this will give the error
*/
if(!preg_match("/^update/i",$query))
die(" Invalid Query: ".$query." ");
$this->result = mysql_query($query,$this->links);
if(!$this->result)
die(" Result Erorr: ".mysql_error()." ".$query." ");
/*
This is used to debug the code and print the query
You have to pass 1 (one) as the second argument of the edit function
Default is $debug 0 set.
*/
if($debug == 1)
{
print "
";
exit;
}
return $this->result;
}
//use to insert, update, replace and delete record
function delete($query,$debug=0)
{
if(trim($query) == "")
die("Query is Empty: ".mysql_error());
/*
This is used to check that query has delete word or not
If you try to execute other types of query in that case this will give the error
*/
if(!preg_match("/^delete/i",$query))
die(" Invalid Query: ".$query." ");
$this->result = mysql_query($query,$this->links);
if(!$this->result)
die(" Result Erorr: ".mysql_error()." ".$query." ");
/*
This is used to debug the code and print the query
You have to pass 1 (one) as the second argument of the edit function
Default is $debug 0 set.
*/
if($debug == 1)
{
print "