How We Work
We see ourselves as partners in your road to success. Below is an outline of how we engage our new customers, but remain flexible to their leadership and preferred process. As an offshore entity, we remain conscious of the importance of clear communication, and are a little obsessive about not letting communiqué slip thru the cracks of project complexities.
- New Client expresses interest in Teleparadigm
- Technologist/Sales present to Customer. Together, we explore fit.
- Establish Proof of Concept – finalize requirements and related costs
- Goals of POC: (a) produce some tangible result for end-users for feedback and funding, and (b) Experience working together.
- Together, evaluate POC results – what went well and what didn’t at project level and people level. Use the experience to determine whether to go for real project(s) and what changes to implement for smoother functioning.
- Together, engage in deep interactions and iterations on technical and feature requirements for short-term, production quality project(s).
- Teleparadigm presents short-term proposals including an SRS and project management deliverables – resources (man-hours), milestones, deliverables, and timelines – as well as cost estimate.
- We believe in transparency and provide a variety of web-based project management tools that allow our customers to learn what we are doing on a daily basis. We are also flexible in case our customers prefer alternative tools.
- Project managers usually provide weekly reports and customers are welcome to any SCRUM meetings.
- Most projects are typically based on time and material, while some smaller ones may be based on a fixed price model.
- Client approves implementation of short-term project(s) based on mutually agreed SOW.
- Design and implementation of short-term project begins. See design and implementation.
- As short-term projects tend towards success, where relevant, we explore long-term relationship with customer with regards to a BOT service model.
- Throughout the process, Teleparadigm regularly checks in with the customer to find out their satisfaction levels.
Every project has
- Project Manager - Acts as the point of contact for customers
- Tech/Module Leads - Designing and Architect the solution. They report to the Project Manager.
- UI designers and Engineers - Coding/Testing
The team organization may change based on the size and duration of the project and advice from customer.
Interactions with customers
- Daily/Weekly Status Reports are sent by the Project Manager
- Review Project Status through a Weekly/Bi-Weekly meeting.
- Progress Monitoring
- Regular Code commit to Source control
- Nightly Builds
- Bug Tracking
If customers prefer alternative tools to achieve synergy between development teams, then we are open to adopting and learning new tools that will close the distance divide. Below is a sample of the many tools used.
|Web Conferencing||GoToMeeting/Team viewer|
|Phone||VoIP Provider- Vonage|
|Bug Tracking||Bugzilla, Mantis|
|Collaboration||Google Docs , eRoom , Assembla ,Wiki|
|Instant Messenger||Skype, Yahoo|
|Development and Debugging Tool||Eclipse IDE, MS Visual Studio C/C++ and .NET, Apple XCode and Cocoa, Adobe Flex Builder|
|Code Versioning||SVN, CVS, GIT|
|Testcase Management tools||Testlink, QTP|
|Manuals and User Help||JavaHelp, RoboHelp|
We are open to development methologies that our customers prefer – Agile versus waterfall. For Agile development, the design and implementation can be done in shorter, tighter iterations, effectively nibbling away at the project requirements and demonstrating results as they are completed.
To remove dependencies and for efficiency, separate design activities are started in parallel. The common resources in these activities are the team lead and the customer representative for each design aspect. The design aspects are:
User Interface Design
- Members Involved : UI Designer, Team Lead, QA, and Customer,
- Storyboard mockups and iterative reviews with client.
- Design final UI screens
- Members Involved: Architect/Team Lead and usually, Customer
- Define E-R diagrams
- Create final schemas
- Members Involved: Team Lead, QA and Customer
- Analyze the requirements
- Define Test cases/ Test scenarios
- Define Input Domains
- Prepare Traceability Matrix
During the design phase itself, QA is involved so they understand the product and the priority of various features.
After design, implementation begins.
Daily status reporting
An interesting aspect of our standard software development practices is that we produce daily reports for all of our major Clients and Business Partners. Other software developers may query the benefit of this in that it takes time out of the day to type in what the developers have been working on. We have found that it serves us well in that:
- It keeps the Client up to date with what is going on
- It is a record of the development work performed over time
- Developers can easily recall what they did or how they did some task even years after the actual work day
- By having to write down what work tasks they performed during the day, it provides a useful internal feedback loop for the actual developer writing the daily report
- It provides a useful communication mechanism for clients or developers that are separated by multiple timezones
The practice of creating daily reports on the software development work we perform works well for us. It has increased the visibility of our work when the client is physically removed from our location and provides a record of our work.
We follow two levels of code review:
- A Peer review in which a team mate goes through your code to find out glitches and to check if the coding standards agreed upon for the project are followed.
- The team lead then reviews the code once more to check further if all coding standards are met including code documentation.
Once these are undertaken the code is checked in the clients repository using the repository control system. Some customers have lead developers in-house, and are welcome to conduct additional code reviews, and communicate with the project manager. All code is well-commented, so that the customer’s return on investment is protected and transferable at every check-in.
We currently use the SVN revision control system as in house code versioning system. Regardless, for the size of our development team it has served us well. We adapt to other versioning systems if a client wants us to use a different version control system. Every change to a program's source code is logged with a date/time and the developer that made the change along with specific comments to each commit. Each revision is identified by a revision number. This revision control information helps us as developers manage the software development process over the lifetime of the software products we maintain. In addition there is a web based control panel for viewing the statusof the code revisions.
We use continuous integration as part of the software development and maintenance workflow. A continuous integration server monitors the revision control database waiting for developers to make changes. As changes are detected, the build server gets a copy of the changes and then automatically builds and tests all of the software products that have been changed. Our build server also automatically builds an installable release of the software products we maintain.
This provides immediate feedback to the development team as to the health of the development system for the software products we maintain. If a developer makes a change that say works fine in the application they are working but introduces a fault in another application, the team will be informed soon after a check-in occurs.
Testing and QA
In a typical QA/testing environment manual testing can account to up to 80% of all testing, indeed, in many places it accounts for 100%. Our QA team performs both manual testing and automated testing for our projects. Currently we are using Bugzilla as the bug tracking system. Also we use Testlink to create and manage Test cases as well as organize them into Test plans.
Our preference is to automate the testing of all software products we develop where practical. This allows regression tests to be performed whenever changes are made to ensure the existing software functionality hasn't been adversely affected. We use Junit for the test automation of Java Programs and Nunit for the .NET programs.
We follow a strict regimen for manual testing. The PM appoints an individual or team responsible for QA depending on the size and type of the project. The QA will have organizational freedom, authority, and independence to objectively evaluate and report on project activities. The QA ensures that resources (tools, databases, work stations, etc.,) for performing the QA Process and providing QA services are adequate. Tools required to perform the QA tasks are identified based on project requirements. Generally tasks include identifying quality objectives in measurable terms, Types of test and verification and validation (V&V) activities, Entry and exit criteria for project lifecycle phases, QA participation in development of project plans, standards, and procedures execution. The QA Group performs the tasks as defined in the project or QA Plan. Problems or non-conformances with requirements and standards are documented and reported to the PM or appropriate authority. The QA Group communicates the results of QA activities to relevant stakeholders for resolution.