Anilrgowda

According to the Standish Group, the primary contributor for project success (projects delivered on-time and on-budget) is great customer involvement. Knowing that, it makes sense to define best practices for dealing with customers. In the coming months, you will look at best practices for customer involvement that deal with all phases of the software life cycle:

1. Planning: Getting the customers involved in the planning process is critical. Gathering, analyzing, and evaluating requirements is key to ensuring that your project meets the needs of your customer.
2. Design: Good designs are key to ensuring that changes the client requests require minimal changes to your framework.
3. Iterative Coding and Testing: Customers play a major role in Quality Assurance and User Acceptance testing prior to production releases.
4. Production: Having good release management and support ticket management procedures in place will ensure quality releases and great customer support as issues arise.
5. Post Mortem: Upon completion of projects, it is of paramount importance to involve your customers in the project review process. Post Mortem reviews can aid in discovering and document common issues that arose during the project and allows for others to better plan for those risks in upcoming projects.Good designs are key to ensuring that changes the client requests require minimal changes to your framework. The Design Phase is used to determine the technical solution and to provide preliminary estimates for delivering the solution. For the project manager to provide correct estimates, the development team must spend time architecting a technical solution that meets the demands of the functional specification. Additionally, the testing team must develop a Master Test Plan as to allow them to estimate their effort. Upon completion of this phase, a project plan that details the costs, effort, and timeframes in which the solution may be delivered may be developed. As a final step, the client may decide to add, omit, or delay functionality to fit within their timeframe and budget.
   Below are some best practices to aid project management during the Design phase:
   Step 1: Create Detailed Designs
   
   The detailed design document allows your development team to thoroughly think through the development approach, and to determine the effort involved in delivering each functional specification item. Below are the keys to successfully creating detailed designs:
   1. Document your Architectural Roadmap: If your company has not done so yet, document your architectural roadmap for delivering solutions. If you wish to see a template for doing this, go to http://www.pragmaticsw.com/Pragmatic...reOverview.rtf.
   2. Create a Prototype: If a prototype was not created during the customer requirements phase, create a prototype for the feature to ensure that your developers and your project manager agree that the technical design meets the customer requirement. You can quickly create a prototype using FrontPage or any other HTML editor. If there are buttons on the page, explain in detail what will happen (from a technical perspective) when the buttons are clicked.
   3. Specify the details of each function: For example, if you are creating a detailed design for a logon screen, you should have a section that describes exactly what will happen when the Logon button is clicked. It may describe that you will call a business object to validate the userid and password and if it is incorrect, an error is raised (specify the exact error message). It may further specify what objects will be used (like common objects to validate e-mail addresses, and so forth).
   4. Specify "Other Design Considerations:" When implementing solutions based on customer requirements, you should specify whether there are design considerations outside of the norm. For example, you may specify that the software under the current design will work with IE and Netscape versions 6 and higher. You may also specify that no localization will be done; the user interface will support only the English language. These are examples of "other design considerations."
   5. Break the Design into Tasks and Provide Estimates: As the developer specifies the design for each feature, a list of tasks that must be performed to complete each technical function must be identified, along with an estimate of how long (in hours) each task will take to complete.
   6. Have a Team Design Review: Once the detail design is complete, have the technical team review the design (and estimates) to ensure that the developer covered all the bases. Many times, these design reviews bring up ideas that allow you to reduce the effort with a more elegant approach. This approach also allows "other design considerations" to surface and be discussed.
   7. Get Developer and Project Manager Signoff: Have your developer and project manager sign the detail design document so that you can later refer back to it, showing that both parties agree to the approach.
   Detail Design Template: http://www.pragmaticsw.com/Pragmatic...iledDesign.rtf
   Step 2: Create Master Test Plans
   
   The test design document allows your testing team to thoroughly think through the testing approach, and to determine the effort involved in providing adequate test coverage for each functional specification item. The test design document should contain the following sections (you may consider skipping some of these sections for smaller projects):
   1. Introduction: The introduction should explain a why you are testing the product included with these items. It includes Background, References, Code Freeze Dates, and Change Control procedures.
   2. Items to be Tested: This section identifies not only the items to be tested, but also the level of testing in different functional areas. It includes sections on the level of testing, features to be tested, test case matrix, and features to exclude from testing.
   3. Testing Approach: This section defines the overall testing strategy and iterates the deliverables for each phase of the project. It also specifies the tools that you plan to use for defect tracking and issue management.
   4. Release Criteria: This section describes the procedures for allowing the project to enter the production phase. It contains test case pass/fail criteria, testing suspension rules, testing resumption rules, procedures for release to user acceptance testing, and procedures for release to production.
   5. Hardware: This defines the hardware in which the testing will be performed on. This includes your client and server configurations.
   6. Project Plan: Defines the deliverables, budget, and dates for the testing activities.
   Master Test Plan Template: http://www.pragmaticsw.com/Pragmatic...TestDesign.rtf
   Step 3: Design Database and Object Models
   
   Once your development team has created a detailed design, it is time for them to begin determining what database tables are needed to match the design. There are two types of data models:
   • Logical Model:This is a roadmap of all the data structures in your design, with relationships among objects clearly defined. It includes the attributes of each entity and allows you to normalize the data for your specific purpose.
   • Physical Model: This is an implementation of a database on a specific database engine. Based on the Logical Model, the entities become database tables and the attributes become fields in each table.
   When creating your logical model, you will draw diagrams that explain the relationships between the data entities. From here, you create an ERD (Entity to Relationship Diagram) that shows those relationships. For example, if you are creating a billing system, you may have an Invoices entity that has a relationship with Invoice Line Items. In this relationship, an Invoice must have one or more Invoice Line Items. There are many great tools that allow you to draw these diagrams, such as Erwin ERD. Some databases come standard with ERD drawing tools; an example is Microsoft SQL Server. It has an Enterprise Manager that contains an Diagram modeler.
   The Physical model's purpose is performance. Designing databases for performance requires an understanding of the underlying DMBS and normalization techniques. In most instances, the database should be designed relationally and properly normalized. In cases of historical reporting, it is often a good idea to create de-normalized summary tables to quicken the generation of these reports. Most often, it is good design practice to keep only the amount of information necessary to run the business on a day-to-day basis on the operational system and have a separate data warehouse for storing historical data. The data warehouse can produce historical reports or may feed data marts to perform specialized reporting.
   When designing tables, make sure you index the fields that will often appear in where clauses. This will speed data retrieval. Use tools like Oracle's Explain Plan or SQL Server's Show Plan to determine the execution path of your SQL statements. This will let you know whether you are scanning the entire database or scanning an index. If scanning the entire database, consider adding indexes to prevent this from happening.
   If you have a frequently used operation (such as search for Agent information), consider using a stored procedure to return the results. Because stored procedures are pre-compiled, their execution path has been predetermined and is generally faster than simply issuing an SQL statement.
   An important part of the data modeling process is to establish clear standards. For example, your data model should have consistent abbreviations, and should have standard naming conventions. For example, you may decide to name all your tables as plural (Invoices instead of Invoice) and you may decide to always abbreviate number as nbr. If you document your standards ahead of time, this will ensure that all members of your team build a cohesive product.Object Model
   
   Once your database model has been defined, you can define your object model. Below are the steps in object-oriented design:
   • Identify the objects and their attributes (data).
   • Determine what can be done to each object.
   • Determine what each object can do to other objects.
   • Determine the parts of each object that will be visible to other objects and which parts will be private.Similar to database modeling, it is wise to create diagrams that show the relationship between objects. There are many tools on the market to do this (such as Microsoft Visual Modeler). Many of these tools also will generate some of the code behind the objects.
     An important part of the object modeling process is to establish clear standards. For example, your object model should have consistent abbreviations, and should have standard naming conventions. For example, you may decide to name all your objects as plural (Invoices instead of Invoice) and you may decide to always abbreviate number as nbr. Objects also should have consistent method names. For example, you would not want to have an AddNew method in some objects and an Add method in others. Naming your methods consistently allows your programmers to quickly develop using the object model. If you document your standards ahead of time, this will ensure that all members of your team build a cohesive product.
     Step 4: Create the overall Project Plan and Get Signoff
     
     Once the functional specifications have been gathered and the detailed design is complete, the project manager can begin laying out the project deliverables and the calculating the budget for the project. You should always number the functional specifications in a hierarchical manner. That numbering system should follow directly over to the Project Plan, as it allows you to easily trace your project deliverables back to your functional specifications.
     When devising the Project Plan, sit down with your team to ensure that all deliverables are flushed out. This includes all tasks associated with the project, from the Planning phase to the Production phase. For a typical software project, you may decide to organize your project plan with the following major sections:
     • Planning: These are the deliverables discussed in the Planning phase.
     • Design: These are the deliverables discussed in the Design phase.
     • Construction: These are the deliverables for the software construction.
     • Testing: These are the testing delivereables (QA and User Acceptance testing).
     • Implementation: These are the deliverables for rolling out the product to production.
     • Project Closure: These are the final activities used to evaluate how the project went.
     Budget
     
     If you are using a commercial project planning tool, you can calculate the budget automatically as you set up your project plan. Once your budget is calculated, your client may want to re-evaluate their functional specifications to try to trim costs or to speed the delivery of the product.
     For a project to succeed, there are three variables that affect how quickly a project can be completed: Resources, Schedule, and Features. One of the variables must always be flexible to achieve success. For example, if the client has a fixed number of resources (people who work on the project) and their schedule has been set in stone, the feature set must be flexible. This means that they must be flexible to drop some features to make the pre-determined date with that number of resources.
     Project Trade-off Matrix
     
     <table style="border: medium none ; border-collapse: collapse; margin-left: 1in;" border="1" cellpadding="0" cellspacing="0"> <tbody><tr> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td> <td style="border-style: solid solid solid none; border-color: windowtext windowtext windowtext -moz-use-text-color; border-width: 0.5pt 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" bgcolor="#000000" valign="top" width="117">Inflexible</td> <td style="border-style: solid solid solid none; border-color: windowtext windowtext windowtext -moz-use-text-color; border-width: 0.5pt 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" bgcolor="#000000" valign="top" width="117">Flexible</td></tr> <tr> <td style="border-style: none solid solid; border-color: -moz-use-text-color windowtext windowtext; border-width: medium 0.5pt 0.5pt; padding: 0in 5.4pt; width: 87.8pt;" bgcolor="#ece7d4" valign="top" width="117">Resources (Cost)</td> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td></tr> <tr> <td style="border-style: none solid solid; border-color: -moz-use-text-color windowtext windowtext; border-width: medium 0.5pt 0.5pt; padding: 0in 5.4pt; width: 87.8pt;" bgcolor="#ece7d4" valign="top" width="117">Schedule (Ship Date)</td> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td></tr> <tr> <td style="border-style: none solid solid; border-color: -moz-use-text-color windowtext windowtext; border-width: medium 0.5pt 0.5pt; padding: 0in 5.4pt; width: 87.8pt;" bgcolor="#ece7d4" valign="top" width="117">Features</td> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td> <td style="border-style: none solid solid none; border-color: -moz-use-text-color windowtext windowtext -moz-use-text-color; border-width: medium 0.5pt 0.5pt medium; padding: 0in 5.4pt; width: 87.8pt;" valign="top" width="117"> </td></tr> </tbody></table> Working together, the team and customer place a check mark in the appropriate column for each of the project variables. The columns are defined as:
     • Inflexible: Mark two items that are inflexible. For example, if the cost and ship date are set in stone, make Resources (Cost) and Ship Date as Inflexible. Only two items can be inflexible; the last item must be flexible.
     • Flexible: Mark one item as flexible. For example, if you are flexible with the features that are included in the project, mark Features as Flexible.
     A team should use the project trade-off matrix as a reference when making decisions. The matrix is not intended to show absolute priorities; it is merely a tool to facilitate communication and understanding. Most important for the project team is that the matrix shows areas in which the customer is willing to compromise. Make sure that no row or column in the project trade-off matrix has more than one check mark. Any other combination poses serious risk to the project and must be accounted for explicitly in the risk management plan.
     For a team to be successful, at least one check mark must be in the "flexible" column. This means that the team owns at least one variable so that the team is empowered to manage change and risk, and is therefore positioned to achieve success instead of failure.
     Signoffs
     
     The final deliverable in the Design Phase is signoff. You should get signoff from these three teams:
     • Customer: Customer should sign off on the functional specifications, project plan, and budget.
     • Development: The development team should sign off on the functional specifications and detailed design.
     • Testing: The testing team should sign off on the functional specifications and the test design.