Development Methodology

Diyatech follows industry accepted procedures and processes to ensure highest quality output for its customers. We have devised a 4D's (Discover, Design, Develop and Deliver) Methodology based on widely accepted Software Development Life Cycle (SDLC).

Discover
Business requirements

This description is only intended for business and marketing managers of the customer and does not commit any details of what this system would do. This phase try to understand the customer's business needs to provide them a high-level solution portrayal and helping them understand exactly how this would benefit their business.
Software requirements

This segment illustrates all the functionality of the project that is to be implemented. The Client is the owner of this document which describes what exact functionality system should provide, from an external viewpoint. The software requirement capture phase also deals with the parts of the system that have human users, and would describe the functionality from a user's perspective. The audience of this document is first the software engineers/architects who are responsible for using this as their basis for the design of the system. Secondly, this document is intended to help Quality Assurance personnel to start thinking about how to best prepare their test plans. Third, this document is intended for the technical writers so they can start preparing for writing any user's manuals, administration manuals, online help, and more. Finally, this document is intended for the customer to use as their acceptance test before a system could be put into production. Design
Use case analysis

This activity is purely from the perspective of software developers who are digging deep into

software requirements and understanding them more effectively. The main process contains the selection of the common and representative set of software requirements, building use-cases descriptions for them and then use-case course of events for them.A use case is a general, declarative sentence that describes actions a user of the system might perform. Then, for each of these sentences, a paragraph or so of descriptive text may be added. Use case analysis is a technique for developing system specifications and design by analyzing the system from the user's point of view. The results of use case analysis are:

The system requirements will describe the system according to how the user will use the system. Customers will easily understand the system requirements document, so they can help review it to find errors. Designers will add to the system only what the system needs to satisfy its requirements, so the system will be as simple as possible.

Prototype

This activity is very useful but is not always required. For a GUI based system, this becomes a very effective way of understanding all the user interface behavior. Prototyping is also very beneficial for getting the end-user approval about what the final system would look like. For non-GUI parts of a system, it helps solidify software developers' understanding about how to interact with this external system and all the issues related to it. Prototyping may go in parallel with use case analysis.
System architecture

After finishing use case analysis and prototyping, the next activity is to do a high level design. This again involves various UML methodology activities including the preparation of high-level object models, sequence diagrams, collaboration diagram, and data models. The end goal is to come up with a software architecture that can break the entire system into well-defined subsystems. All the subsystems, their public interfaces, and any subsystem interactions and dependencies are discussed in detail. This is the guiding light for all further design and development of the product. Architects and senior members of the development team do this activity. Application design

Develop
Subsystem design

Once an architectural design is finalized, work is then distributed to all the different team members who are responsible for making sure their subsystems are well designed internally and implemented with the best programming practices. During this activity, whenever an individual subsystem is implemented, it is also unit-tested to make sure it works well in isolation.

A test plan is prepared in parallel to the subsystem design and implementation and its outcome is a concise document explaining all the different ways in which the system can be tested. The Test Plan document contains all the test cases, which are to be used by the QA team. In addition to a test plan document, the QA team may also prepare test scripts to help automate some or all of the testing. We also prepare a customer acceptance test plan which is used to ensure that all features and functionality of the project is being handled. Passing this document is the exit criteria at the end of the project. In addition to communicating a clear criteria for project completion, the acceptance test plan provides all critical delivery information to development and QA team for correct and timely implementation and testing.
Subsystem development

Development of subsystems is spread across a number of intermediate milestones. As each milestone is achieved, it demonstrates limited functionality of the system. The purpose of these milestones is to make sure the progress of the project is on-track and the client is able to comment on the content of the work during the project. Integrating the code of all these milestones crafts the whole system.
Unit testing

Each member of the development team is responsible for conducting testing on his/her output. Developers do not release their code until they have tested it thoroughly and are satisfied with its correctness and quality.
Integration testing

This activity is done most by the software developers but the software QA also gets involved in it as a prelude to their eventual alpha testing. The purpose of this testing is to see two or more subsystems working together. As more and more subsystems are implemented and unit-tested, they are also put through integration testing. This is an iterative process and in every iteration it usually contains more and more subsystems until the entire system is completed. Integration testing starts somewhere during the subsystem implementation phase and continue until we reach Alpha phase. Deliver
Alpha testing

When all the different subsystems of the system are completed, unit-tested, and integration tested, the system is considered complete. This stage is called Alpha and any further testing on it is called Alpha Testing. In Alpha Testing, software QA is in-charge of all testing activity and tries to test this system as if it is being used by the end-users. This testing and bug-fixing is again an iterative process and all the information generated during this phase is controlled by a bug tracking system (BTS). We have a BTS in-house that is very effective in helping manage this very crucial phase of the product life cycle.
Beta testing

Many customers release their system to a limited number of their customers and go through another phase of testing and bug-fixing. This phase is called Beta Testing and is very similar to

the Alpha Testing except the customers are the actual "testers" of the system. A BTS is again involved in this phase to manage all the information generated.
System Rollout

This is the last stage of the project in which we work with the customer to rollout the system to all users. We hand-off all source code and documentation to customer after which we get customer's acceptance to formally end the project.