Product Engineering
Quadwave manages Product engineering implementation through three different cycles:
Project Management Life Cycle (PMLC)
|
Effective project management is said to occur when the project is delivered on time, within the estimated cost, without exceeding the pre- defined scope of the project, and when quality output is delivered, consequently meeting customer expectations.
To implement good project management, training the teams involved is essential. That is, unless your team knows the processes and steps to follow, how can they be expected to productively implement the methodologies? The size of the project plays a big role in the sort of project management that should be implemented. For example, communication in a small project need not be very formal with a fixed method to be followed. It can be as simple as word of mouth without having to put it in writing, but it may depend on the sort of communication happening. If the communication is about rescheduling of project dates, it makes sense to put it in writing so that future planning becomes easier.
In the case of large projects, having appropriate protocol to be followed such as updating documentation when some change happens, or verifying tasks to be performed with checklists, etc. is often necessary. For large projects, having proper processes in place helps the project execution run smoothly, with minimum hassles.
Also project management should not be confused with application development management. Project management is about risk management, cost management, resource management, communications, and quality management. The principles of project management can be applied not only to software product development but any project a Project Manager is involved in.
The project management life cycle (PMLC) consists of the following steps:
During project initiation, the stakeholders are identified and then they agree on the business objective. The resources to be used in the project are decided. The purpose and goals of the project is defined and documented. Here, we are not referring to requirement gathering, but determining whether all stakeholders are agreed on the goals and to identify any problems with the project. Any differences identified should be resolved before the project commences.
The schedule of the project is created – what deliverables and when they will reach you is determined. This requires proper communication between Project Managers and other concerned parties. For example, if it is the programmers who are likely to know what sort of effort would be put into particular tasks involved, it is sensible to pay attention to their opinions on the matter.
The process to be implemented is also determined.
The process or methodology to be implemented depends on the requirements of the product to be developed. Quadwave implements various methodologies depending on your requirements. We implement light weight methodologies like Agile to enable flexible processes. The distinguishing factor about Agile methodologies compared to traditional ones is that they accommodate changes. Quadwave implements Extreme Programming (XP) and Scrum methodologies. Communication between the stakeholders and simplicity of code and programming are stressed in Agile methodologies. Different stages of development are not rigidly adhered to, but are broadly estimated and scheduled. The assumption is that design, analysis, and development are unpredictable in nature. The main aim is to improve flexibility, yet control risk. This is done by breaking up the initially identified requirements into sets of features and the most important ones are developed and delivered first. Based on the initial performance of the software, the coding, processes, schedules, etc. can be changed as required. This process ensures that change request at any stage can be entertained and risks are identified and remediation steps taken.
In the case of XP, simple code, constant testing of code, engaging the customer in the development process, pair programming are some of the defining qualities. Development using eXtreme Programming is often iterative in nature. To accommodate new requirements without pushing the development process into chaos, the schedules for the deliverables of these iterations have to be planned and ensured that they followed. If not, then estimation can be performed again. Communication through daily informal meetings ensures efficiency along with daily planning and task assignment.
Scrum is another lightweight, Agile methodology implemented successfully at Quadwave. Unlike the linear processes of earlier development models, in Scrum, as in XP, communication, daily status meetings, entertaining change request are the significant qualities. The Backlog (the identified requirements) and risks can be re- evaluated and changed after any Sprint (set of defined development activities for a pre- defined period).
Both methodologies are ideal for small to medium sized projects of up to 30 team members.
Project planning involves the following:
-
risk assessment activities
-
defining change control processes
-
preparing resources for the start of the project through meetings
At this stage, the tasks involved in the project are defined and allocated to the resources. The right people for the appropriate activities are identified. Short term goals are defined and imparted to the team members. Coding standards, communication channels to be used should be identified and communicated to the resources.
The plans made at this stage may be subject to change at later stages; nevertheless, the initial specifications and identified risks should be made clear to all stakeholders.
- Process Tracking and Execution
This phase consists of the actual development of the project. The project manager oversees the whole development process and deals with any issues that crop up. The project manager also ensures that development is taking place according to plan and schedules are being met. The product is also tested and implemented in this phase. The deliverables submitted to the client should be satisfactory and acceptable.
Tracking the project involves periodic verification to see if the scheduled deadlines can be met and the project is progressing within budget. If not, new plans have to be created to enable this or with the customer’s authorization, they should be rescheduled. Often, new resources may have to be added to the project to facilitate faster development. This involves training and orientation of the new resources. This possibility has to be kept in mind during the planning stages.
Configuration management starts with a configuration plan which details the process to incorporate change request and overall management of configuration.
During development, change request can be entertained if appropriate processes are in place to incorporate those changes smoothly. Change control should be managed effectively to avoid any negative effects. If code changes, and new requirements and features are not managed properly, the development process may spiral out of control. For this, the new requirements are analyzed carefully to judge the contribution it would make to the application and to estimate the additional cost, time and resources required to complete incorporating the changes. If the time and effort put into the development appears to be disproportionate compared to the potential benefit, it is better to avoid the change altogether.
The source code, documentation relating to the product being developed, different versions of the documents, documents recording configuration changes, modified code, and other artifacts created during development are maintained in a central repository. Version control tools are used for this. A version control system enables the project files to be maintained.
A defect tracking tool helps keep track of bugs in the software product. Bugs can be stored and managed effectively using these tools. Bugs are evaluated, prioritized and systematically dealt with.
One of the most important phases of project planning is risk management. Risk has to be identified at the requirements stage itself so that later, when other risks are identified, it does not accumulate and become unmanageable then. As new risks are identified, the project should be re- evaluated and mitigation steps should be taken. This may involve changing deadlines and plans made initially.
Quadwave identifies and addresses multiple levels of risks and addresses them in consultation with the customer.
Quadwave encourages knowledge sharing and maintains a repository of all the material generated including documentation of the various projects, emails, source code, and reference material. A knowledge management system manages the material, organizes it, and makes it available to Quadwave’ employees for use. The information can be reused and transferred to different projects. A knowledge management system ensures that information is available constantly so that development is not stalled due to lack of sufficient knowledge. Resources need not spend time searching for material if it is readily available on the intranet.
A knowledge archive also encourages employees to try out new technologies and promotes innovative thinking.
|
| Product Development Life Cycle (PDLC) |
|
Once your product idea has taken shape and the product strategy has been decided, the product is ready for physical realization. Like everything else in the universe, product development too has different stages in its lifetime. We refer to it as the Product Development Life Cycle or PDLC.
Product engineering involves actual development of software by implementing, most often, an iterative model.
Our typical development of a software product involves the following phases, which are iterative in nature. They are:
In the pre-inception stage, the business model and the enterprise architecture is decided. The reusable assets are evaluated and the development process to be implemented is developed.
Top
The inception stage of product engineering comprises of the following steps:
-
Identifying project scope – It involves defining the high level features of the product and identifying most of the use cases. The people and systems that will interact with the product are also identified.
-
Estimation – Time schedule and cost are estimated at a high level
-
Identifying risks – Risks are identified at different stages of the product development stages, but it is important to know the high priority risks at the initial stages itself and project planning should be performed keeping those risks in mind.
-
Infrastructure – The hardware, software, workspace, and the staff likely to be required for the development should be determined.
Before the next phase is started, the Lifecycle Objectives (LCA) milestone should be passed and stakeholders must agree on the following:
-
Scope of the project
-
Initial software requirements – All parties must agree on the requirements that have been captured
-
Cost and schedule estimate
-
Risk acceptance – All parties should agree that risks have been identified, assessed, and risk mitigation has been taken into account
-
Development process to be used
-
Feasibility from a business perspective
-
Project plan
Top
In the elaboration stage, the requirements of the product are specified in detail and the baseline of the architecture is defined. The requirements are detailed into a system use case or technical requirements. The details of the next phase – construction are also worked out. Architectural risks are identified and mitigation techniques are incorporated. The hardware, software, and communication systems, which is required is understood and implemented.
Once the elaboration phase is over, the team should pass the Lifecycle Architecture (LCA) milestone. Stakeholders must agree on the following:
-
The project vision is realistic
-
Software requirements
-
Architecture is stable and satisfies the requirements
-
Risk acceptance – There should be agreement that risks have been identified, assessed, and risk mitigation has been taken into account
-
Cost and schedule estimate has been undertaken
-
The objectives of the project can be met
-
Detailed project plan
-
The system architecture reflects the realities of the enterprise architecture
Top
The major share of the work involved in product development occurs in the construction phase – completing requirements specification, prioritizing requirements, designing a solution, coding, and testing the software.
At the end of the construction phase, the Initial Operational Capability (IOC) milestone has to be passed. Stakeholders must agree on the following:
-
System is stable and mature to deploy to system users
-
Stakeholders and the business are ready for the product deployment
-
Risk acceptance – There should be agreement that risks have been identified, assessed, and risk mitigation has been taken into account
-
Cost and schedule estimate has been undertaken
-
Iteration plans for the next phase are in place
-
The artifacts produced should comply with enterprise standards
Top
This phase involves extensive testing, code rework to fix significant bugs, beta testing, manufacturing, and distribution of software and documentation.
Before entering the next phase, i.e. the Product Release (PR), stakeholders must agree on the following:
Top
This phase involves product support, change management of requirements and bugs. This phase ends when the Release Replacement (RR) milestone is reached. The application is replaced or retired (due to release of new version, replacement by new system, business ceasing to be operational, etc.) and all stakeholders agree to the step.
Top
In this phase, systems are successfully removed from production. The application should be removed with minimum disturbance to users and business operations. Dependant systems should be reworked so that they don’t rely on the system, which is being replaced. All data previously used by the system should be maintained separately elsewhere. The Release Retirement milestone signifies the end of the retirement phase and indicates that:
-
The system is completely removed; including software, hardware, and data
-
All stakeholders are informed of the product replacement
Top
|
Different processes in each of the above-mentioned life cycles often occur in parallel. For example, software testing processes are conducted simultaneously as product development.
|
