Types of Automation Frameworks
Data Driven Automation Framework
Keyword Driven Automation Framework
Modular Automation Framework
Hybrid Automation Framework
Data Driven Automation Framework
Repeated use of Test Scripts with Different Inputs and
Response Data coming out of Predefined Dataset
Easy to implement in IBM - RFT with the help of Datapools
Helps in Reducing Coding for Large Test Cases
Ease of Testing of Time-Consuming & Complex Test Cases
Keyword Driven Automation Framework
As the Name suggests, it enables Keyword Driven Testing
or Table Driven Testing
Data & Keyword Tables being Independent of the
Automation Tool
Enables Documentation of the Functionality of the
Application under Test (AUT) in A Tabular Format
Modular Automation Framework
Test Script Modularity Framework:
Enables creation of Small, Independent Scripts representing
Modules & Functions of the Application under Test (AUT)
Test Library Architecture Framework:
Enables creation of Library Files representing Modules &
Functions of the Application under Test (AUT)
Hybrid Automation Framework
It is the Most Popularly Implemented Framework
It is a Combination of the Three Types of Frameworks
described before
It has an Ability of Evolving Itself Over a Passage of Time
and Over Many Projects
Steps to Implement Automation Framework Approach
1) Identification of the Scope of Testing:
Company Oriented, Product Oriented, Project Oriented
2) Identification of the Needs of Testing:
Identify Types of testing e.g. FT, Web Services etc. and application / modules to be tested
3) Identification of the Requirements of Testing:
Find out the Nature of Requirements, Identification of type of actions for each requirement & identification of High Priority Requirements
4) Evaluation of the Test Automation Tool:
Preparation of Evaluation Checklist, Identification of the Candidate Tools Available, Sample Run, Rate & Select the Tool, Implementation & Training
5) Identification of the Actions to be automated:
Actions, Validations & Requirements supported by the Tool
6) Design of the Test Automation Framework:
Framework Guidelines, Validations, Actions Involved, Systems Involved, Tool Extensibility Support, Customs Messages & UML Documentation
7) Design of the Input Data Bank:
Identification of Types of Input file, Categorization & Design of File Prototypes
8) Development of the Automation Framework:
Development of Script based upon Framework Design, Driver Scripts, Worker Scripts, Record / Playback, Screen / Window / Transaction, Action / Keyword & Data Driven
9) Population of Input Data Bank:
Different Types of Data Input, Population of Data from Different Data Sources, Manual Input of Data and Parent – Child Data Hierarchy
10) Configuration of the Schedulers:
Identify Scheduler Requirements & Configure the Schedulers
Thursday, July 8, 2010
CODD’S RULES” for Relational Data Base.
What are CODD’s Rules????
Codd's 12 rules are a set of thirteen rules (numbered zero to twelve) proposed by Edgar F. Codd, a pioneer of the relational model for databases, designed to define what is required from a database management system in order for it to be considered relational, i.e., an relational database
1 Information Rule: All information in a relational database including table names, column names are represented by values in tables. This simple view of data speeds design and learning. User productivity is improved since knowledge of only one language is necessary to access all data such as description of the table and attribute definitions, integrity constraints. Action can be taken when the constraints are violated. Access to data can be restricted. All these information are also stored in tables.
2 Guaranteed Access Rule: Every piece of data in a relational database, can be accessed by using combination of a table name, a primary key value that identifies the row and column name which identified a cell. User productivity is improved since there is no need to resort to using physical pointers addresses. Provides data independence. Possible to retrieve each individual piece of data stored in a relational database by specifying the name of the table in which it is stored, the column and primary key which identified the cell in which it is stored.
3 Systematic Treatment of Nulls Rule: The RDBMS handles records that have unknown or inapplicable values in a pre-defined fashion. Also, the RDBMS distinguishes between zeros, blanks and nulls in the records hand handles such values in a consistent manner that produces correct answers, comparisons and calculations. Through the set of rules for handling nulls, users can distinguish results of the queries that involve nulls, zeros and blanks. Even though the rule doesn’t specify what should be done in the case of nulls it specifies that there should be a consistent policy in the treatment of nulls.
4 Active On-line catalog based on the relational model: The description of a database and in its contents are database tables and therefore can be queried on-line via the data manipulation language. The database administrator’s productivity is improved since the changes and additions to the catalog can be done with the same commands that are used to access any other table. All queries and reports can also be done as any other table.
5 Comprehensive Data Sub-language Rule: A RDBMS may support several languages. But at least one of them should allow user to do all of the following: define tables and views, query and update the data, set integrity constraints, set authorizations and define transactions. User productivity is improved since there is just one approach that can be used for all database operations. In a multi-user environment the user does not have to worry about the data integrity an such things, which will be taken care by the system. Also, only users with proper authorization will be able to access data.
6 View Updating Rule: Any view that is theoretically updateable can be updated using the RDBMS. Data consistency is ensured since the changes made in the view are transmitted to the base table and vice-versa.
7 High-Level Insert, Update and Delete: The RDBMS supports insertions, updation and deletion at a table level. The performance is improved since the commands act on a set of records rather than one record at a time.
8 Physical Data Independence: The execution of adhoc requests and application programs is not affected by changes in the physical data access and storage methods. Database administrators can make changes to the physical access and storage method which improve performance and do not require changes in the application programs or requests. Here the user specified what he wants an need not worry about how the data is obtained.
9 Logical Data Independence: Logical changes in tables and views such adding/deleting columns or changing fields lengths need not necessitate modifications in the programs or in the format of adhoc requests. The database can change and grow to reflect changes in reality without requiring the user intervention or changes in the applications. For example, adding attribute or column to the base table should not disrupt the programs or the interactive command that have no use for the new attribute.
10 Integrity Independence: Like table/view definition, integrity constraints are stored in the on-line catalog and can therefore be changed without necessitating changes in the application programs. Integrity constraints specific to a particular RDB must be definable in the relational data sub-language and storable in the catalog. At least the Entity integrity and referential integrity must be supported.
11 Distribution Independence: Application programs and adhoc requests are not affected by change in the distribution of physical data. Improved systems reliability since application programs will work even if the programs and data are moved in different sites.
12 No subversion Rule: If the RDBMS has a language that accesses the information of a record at a time, this language should not be used to bypass the integrity constraints. This is necessary for data integrity
Codd's 12 rules are a set of thirteen rules (numbered zero to twelve) proposed by Edgar F. Codd, a pioneer of the relational model for databases, designed to define what is required from a database management system in order for it to be considered relational, i.e., an relational database
1 Information Rule: All information in a relational database including table names, column names are represented by values in tables. This simple view of data speeds design and learning. User productivity is improved since knowledge of only one language is necessary to access all data such as description of the table and attribute definitions, integrity constraints. Action can be taken when the constraints are violated. Access to data can be restricted. All these information are also stored in tables.
2 Guaranteed Access Rule: Every piece of data in a relational database, can be accessed by using combination of a table name, a primary key value that identifies the row and column name which identified a cell. User productivity is improved since there is no need to resort to using physical pointers addresses. Provides data independence. Possible to retrieve each individual piece of data stored in a relational database by specifying the name of the table in which it is stored, the column and primary key which identified the cell in which it is stored.
3 Systematic Treatment of Nulls Rule: The RDBMS handles records that have unknown or inapplicable values in a pre-defined fashion. Also, the RDBMS distinguishes between zeros, blanks and nulls in the records hand handles such values in a consistent manner that produces correct answers, comparisons and calculations. Through the set of rules for handling nulls, users can distinguish results of the queries that involve nulls, zeros and blanks. Even though the rule doesn’t specify what should be done in the case of nulls it specifies that there should be a consistent policy in the treatment of nulls.
4 Active On-line catalog based on the relational model: The description of a database and in its contents are database tables and therefore can be queried on-line via the data manipulation language. The database administrator’s productivity is improved since the changes and additions to the catalog can be done with the same commands that are used to access any other table. All queries and reports can also be done as any other table.
5 Comprehensive Data Sub-language Rule: A RDBMS may support several languages. But at least one of them should allow user to do all of the following: define tables and views, query and update the data, set integrity constraints, set authorizations and define transactions. User productivity is improved since there is just one approach that can be used for all database operations. In a multi-user environment the user does not have to worry about the data integrity an such things, which will be taken care by the system. Also, only users with proper authorization will be able to access data.
6 View Updating Rule: Any view that is theoretically updateable can be updated using the RDBMS. Data consistency is ensured since the changes made in the view are transmitted to the base table and vice-versa.
7 High-Level Insert, Update and Delete: The RDBMS supports insertions, updation and deletion at a table level. The performance is improved since the commands act on a set of records rather than one record at a time.
8 Physical Data Independence: The execution of adhoc requests and application programs is not affected by changes in the physical data access and storage methods. Database administrators can make changes to the physical access and storage method which improve performance and do not require changes in the application programs or requests. Here the user specified what he wants an need not worry about how the data is obtained.
9 Logical Data Independence: Logical changes in tables and views such adding/deleting columns or changing fields lengths need not necessitate modifications in the programs or in the format of adhoc requests. The database can change and grow to reflect changes in reality without requiring the user intervention or changes in the applications. For example, adding attribute or column to the base table should not disrupt the programs or the interactive command that have no use for the new attribute.
10 Integrity Independence: Like table/view definition, integrity constraints are stored in the on-line catalog and can therefore be changed without necessitating changes in the application programs. Integrity constraints specific to a particular RDB must be definable in the relational data sub-language and storable in the catalog. At least the Entity integrity and referential integrity must be supported.
11 Distribution Independence: Application programs and adhoc requests are not affected by change in the distribution of physical data. Improved systems reliability since application programs will work even if the programs and data are moved in different sites.
12 No subversion Rule: If the RDBMS has a language that accesses the information of a record at a time, this language should not be used to bypass the integrity constraints. This is necessary for data integrity
V-Model
V-Model
The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.
Verification Phases
1. Requirements analysis:
In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.
2. System Design:
System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.
3. Architecture Design:
This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.
4. Module Design:
This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.
The V-model is a software development model which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.
Verification Phases
1. Requirements analysis:
In this phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However, it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase.
2. System Design:
System engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly.
The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.
3. Architecture Design:
This phase can also be called as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.
4. Module Design:
This phase can also be called as low-level design. The designed system is broken up in to smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudo code - database tables, with all elements, including their type and size - all interface details with complete API references- all dependency issues- error message listings- complete input and outputs for a module. The unit test design is developed in this stage.
SAS 70 Type I Audit Information
Type I audits include an examination of controls that have been placed in operation and how these very controls achieve the specified control objective for a stated period of time. Generally speaking, costs and completion time for a SAS 70 Type I audit are less than that of a Type II audit. Service organizations that generally have a Type I audit performed include those that have never had a SAS 70 performed compliance quickly, without having to undergo a longer audit process, such as that for a Type II.
A Type I report is only issued for a particular date. For example, a certified public accounting firm would examine a company’s controls and report on the "controls placed in operation" for a specified point in time, such as June 1, 2008. A fair amount of criticism of SAS 70 Type I audits has centered around it’s limited testing period, which many feel is inadequate to gain a sufficient understanding of a service organization’s control environment. As such, Type II audits are considered the viable choice, and they too have fallen under criticism for various reasons. Type I audits are beneficial in many ways, such as laying the framework and foundation for subsequent Type II audits in future periods, along with giving the service organization an understanding of expectations and time commitments for regulatory compliance auditing. Please note that completing consecutive Type I audits are typically rare, does not suffice for Section 404 of the Sarbanes-Oxley Act of 2002, and ultimately does not provide user organizations with the assurances they are seeking.
Performing a SAS 70 Type I audit is a structured, multi-step process, which includes a number of predefined processes and procedures that must take place to ensure its successful and timely completion. Generally, successfully completing a SAS 70 Type I and then moving towards Type II compliance for subsequent years is the most common path many service organizations choose to undertake when considering a SAS 70 roadmap for compliance that has long-term value.
SAS 70 Type II Testing Period Considerations
Type II audits include an examination of controls that have been placed in operation and testing of operating effectiveness. Testing of controls is required for Type II audits, with a minimum testing period of at least six months. Testing is conducted throughout various predetermined timeframes throughout the six-month period, and in a manner that significantly mitigates any type of business interruption. However, other factors, circumstances can lead to a smaller testing period, such as four (4) months, or a longer testing period, such as ten (10) months. Many times, the test period is driven by external auditor requirements, user organization demands, along with service organization financial and operational concerns for undertaking the audit itself. For example, many times a user organization is notified by its external auditors (user auditors) that one of their outsourced providers (service organization) conducts transaction processing activities that affect the user organization's "information system". When this happens, a dialogue amongst all parties will ensue, with the testing period being a paramount topic. It's just one of many scenarios that can decide the testing period of the Type II audit.
A Type II report is issued after a generally accepted period has been completed. For example, an accounting firm would examine a company's controls from June 1, 2007 to November 30, 2007 and report on the "controls placed in operations and tests of operating effectiveness" for the six-month test period of the audit.
Type II compliance can be attained by following the most common approach, whereby service organizations undergo a Type I audit, then move towards Type II compliance for subsequent years. However, due to factors stated earlier, such as varying financial statement reporting time periods for publicly traded corporations and a host of other issues, working immediately towards Type II compliance becomes the only option at times.
A Type I report is only issued for a particular date. For example, a certified public accounting firm would examine a company’s controls and report on the "controls placed in operation" for a specified point in time, such as June 1, 2008. A fair amount of criticism of SAS 70 Type I audits has centered around it’s limited testing period, which many feel is inadequate to gain a sufficient understanding of a service organization’s control environment. As such, Type II audits are considered the viable choice, and they too have fallen under criticism for various reasons. Type I audits are beneficial in many ways, such as laying the framework and foundation for subsequent Type II audits in future periods, along with giving the service organization an understanding of expectations and time commitments for regulatory compliance auditing. Please note that completing consecutive Type I audits are typically rare, does not suffice for Section 404 of the Sarbanes-Oxley Act of 2002, and ultimately does not provide user organizations with the assurances they are seeking.
Performing a SAS 70 Type I audit is a structured, multi-step process, which includes a number of predefined processes and procedures that must take place to ensure its successful and timely completion. Generally, successfully completing a SAS 70 Type I and then moving towards Type II compliance for subsequent years is the most common path many service organizations choose to undertake when considering a SAS 70 roadmap for compliance that has long-term value.
SAS 70 Type II Testing Period Considerations
Type II audits include an examination of controls that have been placed in operation and testing of operating effectiveness. Testing of controls is required for Type II audits, with a minimum testing period of at least six months. Testing is conducted throughout various predetermined timeframes throughout the six-month period, and in a manner that significantly mitigates any type of business interruption. However, other factors, circumstances can lead to a smaller testing period, such as four (4) months, or a longer testing period, such as ten (10) months. Many times, the test period is driven by external auditor requirements, user organization demands, along with service organization financial and operational concerns for undertaking the audit itself. For example, many times a user organization is notified by its external auditors (user auditors) that one of their outsourced providers (service organization) conducts transaction processing activities that affect the user organization's "information system". When this happens, a dialogue amongst all parties will ensue, with the testing period being a paramount topic. It's just one of many scenarios that can decide the testing period of the Type II audit.
A Type II report is issued after a generally accepted period has been completed. For example, an accounting firm would examine a company's controls from June 1, 2007 to November 30, 2007 and report on the "controls placed in operations and tests of operating effectiveness" for the six-month test period of the audit.
Type II compliance can be attained by following the most common approach, whereby service organizations undergo a Type I audit, then move towards Type II compliance for subsequent years. However, due to factors stated earlier, such as varying financial statement reporting time periods for publicly traded corporations and a host of other issues, working immediately towards Type II compliance becomes the only option at times.
Estimation Guidelines
Why Estimate?
Estimation is an essential part of any project methodology. Estimation is used for a number of purposes:
• To justify the project, particularly at the proposal stage, enabling the costs to be compared with the anticipated benefits and to enable informed comparisons to be made between different technical or functional options.
• To enforces the disciplines needed to make the project succeed.
• To secure the resources required to successfully deliver the project.
• To ensure that the support impact of the project is fully understood.
• To inform and improve our software development process.
This document describes the techniques used to produce reliable estimates for the work required to complete projects and tasks.
Overview of the Estimation Process
The best people to undertake estimation are the staff who are going to do the work. The staff chosen to produce an estimate are typically drawn from IS, customers and/or service partners who have relevant experience of similar previous projects or tasks in the business area.
Our estimation process is based on three components:
1. Expert judgement, i.e. consultation with qualified experts from within IS and our business and service partners. This is supplemented, where required, by expert input from software suppliers and consultants.
2. Experience, i.e. comparison of the proposed project or task with previously completed work.
3. Task Decomposition, i.e. decomposing the project into components, i.e. a Work Breakdown Structure, and estimating each component individually to produce an overall estimate.
The estimates are validated through peer review and are backed up by an experienced Project Manager who takes overall responsibility for the total. Estimates are reviewed and updated throughout the project lifecycle. Estimates, and the processes followed to produce them, are transparent and consistent across all projects.
Project And Task Estimation
Estimation Technique 1 - Three Point Estimation
The Three Point Estimation technique is based on statistical methods, and in particular, the Normal distribution. Three Point Estimation is the preferred estimation technique for IS Applications projects. In Three Point Estimation we produce three figures for every estimate:
a = the best case estimate
m = the most likely estimate
b = the worst case estimate
These values are used to calculate an E value for the estimate and a Standard Deviation (SD) where:
E = a + (4*m) + b / 6
SD = (b - a)/6
E is a weighted average which takes into account both the most most optimistic and pessimistic estimates provided and SD measures the variability or uncertainty in the estimate.
To produce a project estimate the Project Manager:
1. Decomposes the project into a list of estimable tasks, i.e. a Work Breakdown Structure
2. Estimates each the E value and SD for each task.
3. Calculates the E value for the total project work as E (Project Work) = Σ E (Task)
4. Calculates the SD value for the total project work as SD (Project Work) = √Σ SD (Task) 2
We then use the E and SD values to convert the project estimates to Confidence Levels as follows:
• Confidence Level in E value is approximately 50%
• Confidence Level in E value + SD is approximately 70%
• Confidence Level in E value + 2 * SD is approximately 95%
• Confidence Level in E value + 3 * SD is approximately 99.5%
IS Applications use the 95% Confidence Level for all project estimates.
A spreadsheet template for Three Point Estimation is available together with a Worked Example illustrating how the template is used in practice.
Estimation Technique 2 - Base and Contingency Estimation
Base and Contingency is an alternative estimation technique to Three Point Estimation. It is less scientifically based and cannot be used to provide Confidence Levels. It can be a useful technique where there is less detail available on which to base the estimate.
In Base and Contingency estimation all estimates have two components the base and the contingency. The base is the minimum expected time required, i.e. when everything goes well. The contingency is the amount of trust placed on the base when risks are are taken into account and is generally expressed as a percentage of the base. A figure of 10% -20% contingency is a typical figure rising to 50% or even greater for more risky tasks. Separating the base and contingency makes the estimation task easier. We can derive a base figure without having to take into account everything that might go wrong and then use risk analysis to determine the appropriate level of contingency. The assumptions that underpin the base estimate are recorded and the contingency reflects the confidence we have that these assumptions are correct.
The Project Manager will also consider project wide risks and undertake a risk analysis to determine the correct amount of contingency to allow for them. These risks are recorded in the project Risk Register. The contingency is based on the maximum costs to the project of the risk occurring weighted by an assessment of how likely it is to occur expressed as a percentage. Project contingency may be estimated in terms of money, resources or a mixture of both. Resource contingency is managed by adding a factor to individual task estimates.
To produce a project estimate the Project Manager:
1. Decomposes the project into a list of estimable tasks, i.e. a Work Breakdown Structure
2. Estimates each task including any task contingency.
3. Adds the estimates together.
4. Adds the project contingency.
Using this technique the Project Manager must be careful to avoid double-counting, i.e. adding contingency to both the project and task estimates for the same risk.
Technical and Overhead Tasks
Typically we will distinguish between the technical tasks of the project, for example code development or package configuration etc, and overhead tasks such as project management or infrastructure support. Each technical task will be individually estimated whilst the estimate for each overhead tasks can often be calculated on a pro-rata basis. Key factors which will influence estimates for technical tasks are:
• size and complexity of the task
• the skills and experience of the development team and their familiarity with the technology being proposed (training may be required to enable members of the team to become productive with the technologies being used and gain familiarity with the business context - this can be estimated separately)
• non functional requirements such as performance, reliability, code reusability etc.
Typical overhead tasks include:
• Project Management
• Quality Assurance
• Business Analysis
• Systems Analysis and Design
• Infrastructure Support
• Testing
• Deployment (includes user training and implementation in live environment.)
Project experience suggests potentially useful rules of thumb for deriving initial estimates for various overhead tasks. These are provided in Table 1 below.
Task Rule Of Thumb
Project Management A full time Project Manager is required for every six staff assigned to the project. A typical Applications project requires 2 to 3 FTE staff in non project management roles. Applying this rule of thumb suggests that the Project Manager should be assigned between 33% and 50% of the non project management time for a typical project.
Quality Assurance Allow a figure of 5% of the overall project estimate for quality assurance.
Business Analysis Allow a figure of 20% of the time allowed for the technical tasks to complete the business specification.
Systems Analysis and Design Allow a figure of 25% of the time allowed for the technical tasks to complete the design specification.
Peer Testing Allow a figure of 10% of the time allowed for the technical tasks.
Integration Testing Allow a figure of 15% of the time allowed for the technical tasks.
Acceptance Testing Allow a figure of 15% of the time allowed for the technical tasks.
Deployment Allow a figure of 5% of the time allowed for the technical tasks.
Table 1 Rules Of Thumb For Estimating Overhead Tasks
This approach simplifies estimation and can provide a useful cross check of the technical estimates. However it is perfectly acceptable for overhead tasks to be decomposed and estimated separately where the Project Manager feels that this is more appropriate.
Producing A Project Estimate - The Estimation Team
The Project Manager should assemble an estimation team for the project. The estimation team will include the Project Manager and other technical experts from IS - chosen to reflect the staff who will actually do the work. The estimation team may also include representative project stakeholders including customers and service partners. Four or five staff in total is a reasonable estimation team size for most projects. The quality of the estimate will only be as good as the estimation team's knowledge of the project so it is vital that they collectively understand, as far possible, everything that is known about the project at the time that the estimate is produced.
The estimation team will generally have at least two meetings. The first of these meetings will:
• Review and agree the project goals and identify any risks or assumptions.
• Discuss ways in which the goals may be met including design options.
• Identify key tasks.
This meeting should be attended by a customer stakeholder who will play a key role in discussions on functionality requirements, usability issues etc.
The second meeting will typically take place a few days later to finalise the estimate. It is important that each member of the team prepares their own estimate of the work involved ahead of this second meeting (Delphi Technique). This ensure every member of the team is fully prepared and reduces the risk of individuals having over-influencing the results of the process. This second meeting:
• Confirms the list of estimable tasks
• Confirm the estimates for each estimable and overhead task
At this meeting the Project Manager may ask members of the estimation team to take a lead role in the discussions for particular tasks. For example, a senior member of the proposed development team may lead the review of coding task estimates by walking-through their estimate of the work involved. This meeting will continue, perhaps with further break outs, until consensus is reached on the estimates for all tasks. (Where "Base and Contingency" technique is being used the Project Manager will then lead discussions to determine the overall project contingency using the same consensus building techniques.)
Notes
1. A typical estimation team will be composed of the following staff: the Project Manager, two developers, an IS Apps Section Head or Team Leader and one or two others such as a customer, a technology specialist (e.g. a Technical Services or MyEd representative) or an external supplier. (From 2006/7 onwards the Applications Development Team Manager must be invited to participate in each Applications estimation team.)
2. During estimation meetings it is vital that a note taker is appointed to record design decisions, assumptions and risks. These notes are an important deliverable from the sessions as they help ensure that the context for the estimate is fully understood.
3. Sufficient time should be allowed to enable the team to complete the estimation process. An allowance of 0.5 - 1 day for each member of the team is reasonable.
Monitoring And Signing Off Project Estimates
The Project Manager will monitor estimates throughout the project. Experience gained from previous stages is used to update the task list and the corresponding estimates. Risks are reviewed and contingencies adjusted as appropriate. The revised estimates are reviewed as part of the sign off process at the end of each stage in the project methodology. Completed estimates are signed off by the Project Manager and key project stakeholders. This will typically be done as part of the stage sign off as indicated in Table 2 below:
Project Methodology Stage Deliverable Requirement
Initiation Project Proposal Estimates to be signed off by the Project Sponsor and Project Services Programme Manager
Note: A single estimation team should be established for each business area programme for estimating proposals produced as part of the Annual Planning process. This will reduce the number of estimation meetings required and improve consistency of estimation within the programme.
Planning TOR Revised estimates to be provided with TOR and signed off by Project Manager, Project Sponsor and IS Applications Management.
Business Analysis PPAR Revised estimates signed off as part of PPAR.
Systems Analysis And Design PPDR Revised estimates signed off as part of PPDR.
Build PPBR Revised estimates signed off as part of PPBR.
Integration PPIR Revised estimates signed off as part of PPBR.
Acceptance ASOR Revised estimates signed off as part of Acceptance Sign Off Review.
Deployment DSOR Revised estimates signed off as part of Deployment Sign Off Review.
Closure Closure Review Actuals and estimates to be reviewed and reasons for divergence recorded as part of Closure Review. This is an important means of reviewing and improving the estimation process and building up a 'lesson learnt' database for projects.
Table 2 Signing Off Estimates Within The Project Methodology
Project Planning And Resourcing
Basics
Project risks must be properly managed. There are many risks which can apply to projects which estimation techniques alone cannot adequately address. These include:
• Unrealistic expectations of costs or timescales.
• Unstable business requirements.
• Lack of commitment from project stakeholders.
• Poor project management or technical skills.
• Unclear roles and responsibilities
If any of these problems exist they should be addressed before the project is started!
All projects must have a Task Plan or Gantt Chart. This may be produced using ASTA Teamplan, Microsoft Project or Excel. This is used record the tasks, their estimated durations and any dependencies. The Task Plan is fundamental to determining an appropriate resourcing strategy for the project.
Projects must also have an appropriate change control mechanism. There is no point in estimating and then allowing the scope to change so that the estimates are no longer valid. The Project Issue and Change Control Log (PICCL) is used to record all changes and ensure that the impact of the change is fully considered before the change is approved.
Resourcing Strategy - Dedicated Resources
Recent project management literature has discussed how best to deliver projects in matrix managed environments. This literature has identified the characteristics of optimally managed projects as:
• Task plans and estimates are produced and maintained.
• A dedicated team of resources are assigned 100% to the project.
• Multitasking of development staff with other projects is minimised or, ideally, eliminated.
• Customer and technical inputs are coordinated to achieve maximum effectiveness.
• Project value is increased through the effective interaction of professional staff.
• There is a clear enterprise wide priority for the project which can be referred to to resolve any resource conflicts which may arise.
• Regular contact between the Project Manager and Resource Managers is maintained to provide rapid resolution of resource issues.
Project Managers should try to bring their projects into line as far as possible with this model and book resources to the project, or as significant parts of the project as is possible, rather than individual tasks. Projects for which this approach is particularly recommended will typically have one or more of the following characteristics:
• Require in excess of 150 Days technical resources.
• Be categorised as "Essential" or "Funded"
• Have one or more hard delivery milestones.
• Can be managed as a joint and closely interacting team of IS and customer staff.
The Project Manager can indicate the requirement for "dedicated" resources as part of the Project Proposal and ToR.
Resourcing Strategy - Non Dedicated Resources
For most Applications projects it will not be possible for the Project Manager to secure dedicated resources. For these projects and task estimates, including 95% confidence levels or contingencies as appropriate, are used to assign resources on a task by task basis.
However with this approach the Project Manager must be aware of a number of factors which can prevent the effective deployment of resources and threaten the overall success of the project:
• "Multi-Tasking" - the Developer has been forced to juggle priorities and resources are spread too thinly. As a result he/she switches from task to task reducing productivity, chewing up the available time and reducing the quality of the task deliverable.
• "Procrastination Syndrome" - the Developer interprets the contingency as additional time to finish a task that they think they could do in less. If problems occur with other work this may be given priority and they don't make a start on the task until too late. There is now no safety margin and the task may be late.
• "Early Completion Syndrome" - there is little reward for early completion, in fact if the Developer provided the original estimate they may find their future estimates reduced. In the absence of any incentives to do otherwise the Developer uses the time saved to undertake additional testing or make the solution more elegant. As a result the best outcome available is to finish on time.
The key to successfully managing and reducing these problems is communication. Early identification of potential problems by the development team, Project Manager and/or the customer is essential. To promote successful communication it is strongly recommended that the Project Manager identify staff to fulfil the following key technical roles at the outset of the project:
• Systems Analyst Developer
• Technical Architect
• Production Management Coordinator
• IS Service Owner(s)
Once identified the staff resources can be secured by means of a 10% resource booking with the relevant Resource Manager. This approach will promote a team culture and provide more flexibility for the Project Manager to secure these key resources for meetings and other project activities. This approach is accommodated with the overall estimate as staff will only record time to the project for actual work done.
Estimation is an essential part of any project methodology. Estimation is used for a number of purposes:
• To justify the project, particularly at the proposal stage, enabling the costs to be compared with the anticipated benefits and to enable informed comparisons to be made between different technical or functional options.
• To enforces the disciplines needed to make the project succeed.
• To secure the resources required to successfully deliver the project.
• To ensure that the support impact of the project is fully understood.
• To inform and improve our software development process.
This document describes the techniques used to produce reliable estimates for the work required to complete projects and tasks.
Overview of the Estimation Process
The best people to undertake estimation are the staff who are going to do the work. The staff chosen to produce an estimate are typically drawn from IS, customers and/or service partners who have relevant experience of similar previous projects or tasks in the business area.
Our estimation process is based on three components:
1. Expert judgement, i.e. consultation with qualified experts from within IS and our business and service partners. This is supplemented, where required, by expert input from software suppliers and consultants.
2. Experience, i.e. comparison of the proposed project or task with previously completed work.
3. Task Decomposition, i.e. decomposing the project into components, i.e. a Work Breakdown Structure, and estimating each component individually to produce an overall estimate.
The estimates are validated through peer review and are backed up by an experienced Project Manager who takes overall responsibility for the total. Estimates are reviewed and updated throughout the project lifecycle. Estimates, and the processes followed to produce them, are transparent and consistent across all projects.
Project And Task Estimation
Estimation Technique 1 - Three Point Estimation
The Three Point Estimation technique is based on statistical methods, and in particular, the Normal distribution. Three Point Estimation is the preferred estimation technique for IS Applications projects. In Three Point Estimation we produce three figures for every estimate:
a = the best case estimate
m = the most likely estimate
b = the worst case estimate
These values are used to calculate an E value for the estimate and a Standard Deviation (SD) where:
E = a + (4*m) + b / 6
SD = (b - a)/6
E is a weighted average which takes into account both the most most optimistic and pessimistic estimates provided and SD measures the variability or uncertainty in the estimate.
To produce a project estimate the Project Manager:
1. Decomposes the project into a list of estimable tasks, i.e. a Work Breakdown Structure
2. Estimates each the E value and SD for each task.
3. Calculates the E value for the total project work as E (Project Work) = Σ E (Task)
4. Calculates the SD value for the total project work as SD (Project Work) = √Σ SD (Task) 2
We then use the E and SD values to convert the project estimates to Confidence Levels as follows:
• Confidence Level in E value is approximately 50%
• Confidence Level in E value + SD is approximately 70%
• Confidence Level in E value + 2 * SD is approximately 95%
• Confidence Level in E value + 3 * SD is approximately 99.5%
IS Applications use the 95% Confidence Level for all project estimates.
A spreadsheet template for Three Point Estimation is available together with a Worked Example illustrating how the template is used in practice.
Estimation Technique 2 - Base and Contingency Estimation
Base and Contingency is an alternative estimation technique to Three Point Estimation. It is less scientifically based and cannot be used to provide Confidence Levels. It can be a useful technique where there is less detail available on which to base the estimate.
In Base and Contingency estimation all estimates have two components the base and the contingency. The base is the minimum expected time required, i.e. when everything goes well. The contingency is the amount of trust placed on the base when risks are are taken into account and is generally expressed as a percentage of the base. A figure of 10% -20% contingency is a typical figure rising to 50% or even greater for more risky tasks. Separating the base and contingency makes the estimation task easier. We can derive a base figure without having to take into account everything that might go wrong and then use risk analysis to determine the appropriate level of contingency. The assumptions that underpin the base estimate are recorded and the contingency reflects the confidence we have that these assumptions are correct.
The Project Manager will also consider project wide risks and undertake a risk analysis to determine the correct amount of contingency to allow for them. These risks are recorded in the project Risk Register. The contingency is based on the maximum costs to the project of the risk occurring weighted by an assessment of how likely it is to occur expressed as a percentage. Project contingency may be estimated in terms of money, resources or a mixture of both. Resource contingency is managed by adding a factor to individual task estimates.
To produce a project estimate the Project Manager:
1. Decomposes the project into a list of estimable tasks, i.e. a Work Breakdown Structure
2. Estimates each task including any task contingency.
3. Adds the estimates together.
4. Adds the project contingency.
Using this technique the Project Manager must be careful to avoid double-counting, i.e. adding contingency to both the project and task estimates for the same risk.
Technical and Overhead Tasks
Typically we will distinguish between the technical tasks of the project, for example code development or package configuration etc, and overhead tasks such as project management or infrastructure support. Each technical task will be individually estimated whilst the estimate for each overhead tasks can often be calculated on a pro-rata basis. Key factors which will influence estimates for technical tasks are:
• size and complexity of the task
• the skills and experience of the development team and their familiarity with the technology being proposed (training may be required to enable members of the team to become productive with the technologies being used and gain familiarity with the business context - this can be estimated separately)
• non functional requirements such as performance, reliability, code reusability etc.
Typical overhead tasks include:
• Project Management
• Quality Assurance
• Business Analysis
• Systems Analysis and Design
• Infrastructure Support
• Testing
• Deployment (includes user training and implementation in live environment.)
Project experience suggests potentially useful rules of thumb for deriving initial estimates for various overhead tasks. These are provided in Table 1 below.
Task Rule Of Thumb
Project Management A full time Project Manager is required for every six staff assigned to the project. A typical Applications project requires 2 to 3 FTE staff in non project management roles. Applying this rule of thumb suggests that the Project Manager should be assigned between 33% and 50% of the non project management time for a typical project.
Quality Assurance Allow a figure of 5% of the overall project estimate for quality assurance.
Business Analysis Allow a figure of 20% of the time allowed for the technical tasks to complete the business specification.
Systems Analysis and Design Allow a figure of 25% of the time allowed for the technical tasks to complete the design specification.
Peer Testing Allow a figure of 10% of the time allowed for the technical tasks.
Integration Testing Allow a figure of 15% of the time allowed for the technical tasks.
Acceptance Testing Allow a figure of 15% of the time allowed for the technical tasks.
Deployment Allow a figure of 5% of the time allowed for the technical tasks.
Table 1 Rules Of Thumb For Estimating Overhead Tasks
This approach simplifies estimation and can provide a useful cross check of the technical estimates. However it is perfectly acceptable for overhead tasks to be decomposed and estimated separately where the Project Manager feels that this is more appropriate.
Producing A Project Estimate - The Estimation Team
The Project Manager should assemble an estimation team for the project. The estimation team will include the Project Manager and other technical experts from IS - chosen to reflect the staff who will actually do the work. The estimation team may also include representative project stakeholders including customers and service partners. Four or five staff in total is a reasonable estimation team size for most projects. The quality of the estimate will only be as good as the estimation team's knowledge of the project so it is vital that they collectively understand, as far possible, everything that is known about the project at the time that the estimate is produced.
The estimation team will generally have at least two meetings. The first of these meetings will:
• Review and agree the project goals and identify any risks or assumptions.
• Discuss ways in which the goals may be met including design options.
• Identify key tasks.
This meeting should be attended by a customer stakeholder who will play a key role in discussions on functionality requirements, usability issues etc.
The second meeting will typically take place a few days later to finalise the estimate. It is important that each member of the team prepares their own estimate of the work involved ahead of this second meeting (Delphi Technique). This ensure every member of the team is fully prepared and reduces the risk of individuals having over-influencing the results of the process. This second meeting:
• Confirms the list of estimable tasks
• Confirm the estimates for each estimable and overhead task
At this meeting the Project Manager may ask members of the estimation team to take a lead role in the discussions for particular tasks. For example, a senior member of the proposed development team may lead the review of coding task estimates by walking-through their estimate of the work involved. This meeting will continue, perhaps with further break outs, until consensus is reached on the estimates for all tasks. (Where "Base and Contingency" technique is being used the Project Manager will then lead discussions to determine the overall project contingency using the same consensus building techniques.)
Notes
1. A typical estimation team will be composed of the following staff: the Project Manager, two developers, an IS Apps Section Head or Team Leader and one or two others such as a customer, a technology specialist (e.g. a Technical Services or MyEd representative) or an external supplier. (From 2006/7 onwards the Applications Development Team Manager must be invited to participate in each Applications estimation team.)
2. During estimation meetings it is vital that a note taker is appointed to record design decisions, assumptions and risks. These notes are an important deliverable from the sessions as they help ensure that the context for the estimate is fully understood.
3. Sufficient time should be allowed to enable the team to complete the estimation process. An allowance of 0.5 - 1 day for each member of the team is reasonable.
Monitoring And Signing Off Project Estimates
The Project Manager will monitor estimates throughout the project. Experience gained from previous stages is used to update the task list and the corresponding estimates. Risks are reviewed and contingencies adjusted as appropriate. The revised estimates are reviewed as part of the sign off process at the end of each stage in the project methodology. Completed estimates are signed off by the Project Manager and key project stakeholders. This will typically be done as part of the stage sign off as indicated in Table 2 below:
Project Methodology Stage Deliverable Requirement
Initiation Project Proposal Estimates to be signed off by the Project Sponsor and Project Services Programme Manager
Note: A single estimation team should be established for each business area programme for estimating proposals produced as part of the Annual Planning process. This will reduce the number of estimation meetings required and improve consistency of estimation within the programme.
Planning TOR Revised estimates to be provided with TOR and signed off by Project Manager, Project Sponsor and IS Applications Management.
Business Analysis PPAR Revised estimates signed off as part of PPAR.
Systems Analysis And Design PPDR Revised estimates signed off as part of PPDR.
Build PPBR Revised estimates signed off as part of PPBR.
Integration PPIR Revised estimates signed off as part of PPBR.
Acceptance ASOR Revised estimates signed off as part of Acceptance Sign Off Review.
Deployment DSOR Revised estimates signed off as part of Deployment Sign Off Review.
Closure Closure Review Actuals and estimates to be reviewed and reasons for divergence recorded as part of Closure Review. This is an important means of reviewing and improving the estimation process and building up a 'lesson learnt' database for projects.
Table 2 Signing Off Estimates Within The Project Methodology
Project Planning And Resourcing
Basics
Project risks must be properly managed. There are many risks which can apply to projects which estimation techniques alone cannot adequately address. These include:
• Unrealistic expectations of costs or timescales.
• Unstable business requirements.
• Lack of commitment from project stakeholders.
• Poor project management or technical skills.
• Unclear roles and responsibilities
If any of these problems exist they should be addressed before the project is started!
All projects must have a Task Plan or Gantt Chart. This may be produced using ASTA Teamplan, Microsoft Project or Excel. This is used record the tasks, their estimated durations and any dependencies. The Task Plan is fundamental to determining an appropriate resourcing strategy for the project.
Projects must also have an appropriate change control mechanism. There is no point in estimating and then allowing the scope to change so that the estimates are no longer valid. The Project Issue and Change Control Log (PICCL) is used to record all changes and ensure that the impact of the change is fully considered before the change is approved.
Resourcing Strategy - Dedicated Resources
Recent project management literature has discussed how best to deliver projects in matrix managed environments. This literature has identified the characteristics of optimally managed projects as:
• Task plans and estimates are produced and maintained.
• A dedicated team of resources are assigned 100% to the project.
• Multitasking of development staff with other projects is minimised or, ideally, eliminated.
• Customer and technical inputs are coordinated to achieve maximum effectiveness.
• Project value is increased through the effective interaction of professional staff.
• There is a clear enterprise wide priority for the project which can be referred to to resolve any resource conflicts which may arise.
• Regular contact between the Project Manager and Resource Managers is maintained to provide rapid resolution of resource issues.
Project Managers should try to bring their projects into line as far as possible with this model and book resources to the project, or as significant parts of the project as is possible, rather than individual tasks. Projects for which this approach is particularly recommended will typically have one or more of the following characteristics:
• Require in excess of 150 Days technical resources.
• Be categorised as "Essential" or "Funded"
• Have one or more hard delivery milestones.
• Can be managed as a joint and closely interacting team of IS and customer staff.
The Project Manager can indicate the requirement for "dedicated" resources as part of the Project Proposal and ToR.
Resourcing Strategy - Non Dedicated Resources
For most Applications projects it will not be possible for the Project Manager to secure dedicated resources. For these projects and task estimates, including 95% confidence levels or contingencies as appropriate, are used to assign resources on a task by task basis.
However with this approach the Project Manager must be aware of a number of factors which can prevent the effective deployment of resources and threaten the overall success of the project:
• "Multi-Tasking" - the Developer has been forced to juggle priorities and resources are spread too thinly. As a result he/she switches from task to task reducing productivity, chewing up the available time and reducing the quality of the task deliverable.
• "Procrastination Syndrome" - the Developer interprets the contingency as additional time to finish a task that they think they could do in less. If problems occur with other work this may be given priority and they don't make a start on the task until too late. There is now no safety margin and the task may be late.
• "Early Completion Syndrome" - there is little reward for early completion, in fact if the Developer provided the original estimate they may find their future estimates reduced. In the absence of any incentives to do otherwise the Developer uses the time saved to undertake additional testing or make the solution more elegant. As a result the best outcome available is to finish on time.
The key to successfully managing and reducing these problems is communication. Early identification of potential problems by the development team, Project Manager and/or the customer is essential. To promote successful communication it is strongly recommended that the Project Manager identify staff to fulfil the following key technical roles at the outset of the project:
• Systems Analyst Developer
• Technical Architect
• Production Management Coordinator
• IS Service Owner(s)
Once identified the staff resources can be secured by means of a 10% resource booking with the relevant Resource Manager. This approach will promote a team culture and provide more flexibility for the Project Manager to secure these key resources for meetings and other project activities. This approach is accommodated with the overall estimate as staff will only record time to the project for actual work done.
Wednesday, July 7, 2010
How to create Project Plan.
Project Planning A Step by Step Guide
The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project.
Often project planning is ignored in favour of getting on with the work. However, many people fail to realise the value of a project plan in saving time, money and many problems.
This article looks at a simple practical approach to project planning. On completion of this guide you should have a sound project planning approach that you can use for future projects.
Step 1 Project Goals
A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project.
As a first step it is important to identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are:
• The project sponsor
• The customer who receives the deliverables
• The users of the project outputs
• The project manager and project team
Once you understand who the stakeholders are, the next step is to establish their needs. The best way to do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be recorded and set as a low priority.
The next step once you have conducted all the interviews and have a comprehensive list of needs is to prioritise them. From the prioritised list create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART principle. This way it will be easy to know when a goal has been achieved.
Once you have established a clear set of goals they should be recorded in the project plan. It can be useful to also include the needs and expectations of your stakeholders.
This is the most difficult part of the planning process completed. It's time to move on and look at the project deliverables.
Step 2 Project Deliverables
Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.
Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is next.
Step 3 Project Schedule
Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify the following:
• The amount of effort (hours or days) required to complete the task
• The resource who will carryout the task
Once you have established the amount of effort for each task, you can workout the effort required for each deliverable and an accurate delivery date. Update your deliverables section with the more accurate delivery dates.
At this point in the planning you could choose to use a software package such as Microsoft Project to create your project schedule. Alternatively use one of the many free templates available. Input all of the deliverables, tasks, durations and the resources who will complete each task.
A common problem discovered at this point is when a project has an imposed delivery deadline from the sponsor that is not realistic based on your estimates. If you discover that this is the case you must contact the sponsor immediately. The options you have in this situation are:
• Renegotiate the deadline (project delay)
• Employ additional resources (increased cost)
• Reduce the scope of the project (less delivered)
Use the project schedule to justify pursuing one of these options.
Step 4 Supporting Plans
This section deals with plans you should create as part of the planning process. These can be included directly in the plan.
Human Resource Plan
Identify by name the individuals and organisations with a leading role in the project. For each describe their roles and responsibilities on the project.
Next, describe the number and type of people needed to carryout the project. For each resource detail start dates, estimated duration and the method you will use for obtaining them.
Create a single sheet containing this information.
Communications Plan
Create a document showing who needs to be kept informed about the project and how they will receive the information. The most common mechanism is a weekly/monthly progress report, describing how the project is performing, milestones achieved and work planned for the next period.
Risk Management Plan
Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible and be prepared if something bad happens.
Here are some examples of common project risks:
• Time and cost estimates too optimistic
• Customer review and feedback cycle too slow
• Unexpected budget cuts
• Unclear roles and responsibilities
• Stakeholder input is not sought or their needs are not properly understood
• Stakeholders changing requirements after the project has started
• Stakeholders adding new requirements after the project has started
• Poor communication resulting in misunderstandings, quality problems and rework
• Lack of resource commitment
Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log and write down what you will do in the event it occurs and what you will do to prevent it from occurring. Review your risk log on a regular basis adding new risks as they occur during the life of the project. Remember, when risks are ignored they don't go away.
The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project.
Often project planning is ignored in favour of getting on with the work. However, many people fail to realise the value of a project plan in saving time, money and many problems.
This article looks at a simple practical approach to project planning. On completion of this guide you should have a sound project planning approach that you can use for future projects.
Step 1 Project Goals
A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project.
As a first step it is important to identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are:
• The project sponsor
• The customer who receives the deliverables
• The users of the project outputs
• The project manager and project team
Once you understand who the stakeholders are, the next step is to establish their needs. The best way to do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be recorded and set as a low priority.
The next step once you have conducted all the interviews and have a comprehensive list of needs is to prioritise them. From the prioritised list create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART principle. This way it will be easy to know when a goal has been achieved.
Once you have established a clear set of goals they should be recorded in the project plan. It can be useful to also include the needs and expectations of your stakeholders.
This is the most difficult part of the planning process completed. It's time to move on and look at the project deliverables.
Step 2 Project Deliverables
Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered.
Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is next.
Step 3 Project Schedule
Create a list of tasks that need to be carried out for each deliverable identified in step 2. For each task identify the following:
• The amount of effort (hours or days) required to complete the task
• The resource who will carryout the task
Once you have established the amount of effort for each task, you can workout the effort required for each deliverable and an accurate delivery date. Update your deliverables section with the more accurate delivery dates.
At this point in the planning you could choose to use a software package such as Microsoft Project to create your project schedule. Alternatively use one of the many free templates available. Input all of the deliverables, tasks, durations and the resources who will complete each task.
A common problem discovered at this point is when a project has an imposed delivery deadline from the sponsor that is not realistic based on your estimates. If you discover that this is the case you must contact the sponsor immediately. The options you have in this situation are:
• Renegotiate the deadline (project delay)
• Employ additional resources (increased cost)
• Reduce the scope of the project (less delivered)
Use the project schedule to justify pursuing one of these options.
Step 4 Supporting Plans
This section deals with plans you should create as part of the planning process. These can be included directly in the plan.
Human Resource Plan
Identify by name the individuals and organisations with a leading role in the project. For each describe their roles and responsibilities on the project.
Next, describe the number and type of people needed to carryout the project. For each resource detail start dates, estimated duration and the method you will use for obtaining them.
Create a single sheet containing this information.
Communications Plan
Create a document showing who needs to be kept informed about the project and how they will receive the information. The most common mechanism is a weekly/monthly progress report, describing how the project is performing, milestones achieved and work planned for the next period.
Risk Management Plan
Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible and be prepared if something bad happens.
Here are some examples of common project risks:
• Time and cost estimates too optimistic
• Customer review and feedback cycle too slow
• Unexpected budget cuts
• Unclear roles and responsibilities
• Stakeholder input is not sought or their needs are not properly understood
• Stakeholders changing requirements after the project has started
• Stakeholders adding new requirements after the project has started
• Poor communication resulting in misunderstandings, quality problems and rework
• Lack of resource commitment
Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log and write down what you will do in the event it occurs and what you will do to prevent it from occurring. Review your risk log on a regular basis adding new risks as they occur during the life of the project. Remember, when risks are ignored they don't go away.
REQUIREMENT MANAGEMENT REPORTS
REQUIREMENT MANAGEMENT REPORTS
Some examples of requirements management reports are below. When identifying requirements management information needs for your project, provide an example of suggested reports. This will help you get better feedback on what kinds on information to keep in the requirements repository. Reports are based on the information associated with the requirements. (Requirement text can be omitted from some reports, but is included in the examples for clarity.)
• Backward trace: a traceability report showing the origin of an item. This can be used to determine if unnecessary items are being created (goldplating) that are not warranted by the requirements or to discover the reason for an item.
• Compliance matrix: a report showing the requirements that have been satisfied by a work product or activity.
• Forward trace: a traceability report showing items that would be affected by a requirements change, such as the impact on a design, documents, and/or software.
• Priority: a report of requirements by priority. This report may be used to determine what requirements must be implemented before others. It is also useful when time to build is inadequate or funding is limited.
• Qualification method: a report of requirements by qualification method (inspection, analysis, demonstration, test). This report provides requirements that testers or others must address.
• Requirements validation matrix: a report of requirements and the test cases associated with them. The report can be used to track test case development and approval and can be included in the master test plan.
• Risk: a report of requirements by risk level. This report may be used to determine what requirements are most critical to test completely or to assist in planning when time to test is inadequate.
• Unsatisfied/unallocated requirements: a report of requirements that are unaddressed or unassigned. This report may accompany a compliance matrix and is a quality check to ensure no requirement has been dropped.
Some examples of requirements management reports are below. When identifying requirements management information needs for your project, provide an example of suggested reports. This will help you get better feedback on what kinds on information to keep in the requirements repository. Reports are based on the information associated with the requirements. (Requirement text can be omitted from some reports, but is included in the examples for clarity.)
• Backward trace: a traceability report showing the origin of an item. This can be used to determine if unnecessary items are being created (goldplating) that are not warranted by the requirements or to discover the reason for an item.
• Compliance matrix: a report showing the requirements that have been satisfied by a work product or activity.
• Forward trace: a traceability report showing items that would be affected by a requirements change, such as the impact on a design, documents, and/or software.
• Priority: a report of requirements by priority. This report may be used to determine what requirements must be implemented before others. It is also useful when time to build is inadequate or funding is limited.
• Qualification method: a report of requirements by qualification method (inspection, analysis, demonstration, test). This report provides requirements that testers or others must address.
• Requirements validation matrix: a report of requirements and the test cases associated with them. The report can be used to track test case development and approval and can be included in the master test plan.
• Risk: a report of requirements by risk level. This report may be used to determine what requirements are most critical to test completely or to assist in planning when time to test is inadequate.
• Unsatisfied/unallocated requirements: a report of requirements that are unaddressed or unassigned. This report may accompany a compliance matrix and is a quality check to ensure no requirement has been dropped.
REQUIREMENTS TRACEABILITY MATRIX
Traceability matrices can be established using a variety of tools including requirements management software, databases, spreadsheets, or even with tables or hyperlinks in a word processor.
A traceability matrix is created by associating requirements with the work products that satisfy them. Tests are associated with the requirements on which they are based and the product to be tested against the requirement.
Traceability requires unique identifiers for each requirement and product. Numbers for products are established in a configuration management (CM) plan. The configuration management plan is how changes will be tracked and controlled. Traceability is a key part of managing change.
Traceability ensures completeness, that all lower level requirements come from higher level requirements, and that all higher level requirements are allocated to lower level ones. Traceability also provides the basis for test planning.
Below is a simple traceability matrix structure. There can be more things included in a traceability matrix than shown. In traceability, the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.
Sample Traceability Matrix
A traceability matrix is a report from the requirements database or repository. What information the report contains depends on your need. Information requirements determine the associated information that you store with the requirements. Requirements management tools capture associated information or provide the capability to add it.
The examples show forward and backward tracing between user and system requirements. User requirement identifiers begin with "U" and system requirements with "S." Tracing S12 to its source makes it clear this requirement is erroneous: it must be eliminated, rewritten, or the traceability corrected.
For requirements tracing and resulting reports to work, the requirements must be of good quality. Requirements of poor quality transfer work to subsequent phases of the SDLC, increasing cost and schedule and creating disputes with the customer.
A variety of reports are necessary to manage requirements. Reporting needs should be determined at the start of the effort and documented in the requirements management plan.
A traceability matrix is created by associating requirements with the work products that satisfy them. Tests are associated with the requirements on which they are based and the product to be tested against the requirement.
Traceability requires unique identifiers for each requirement and product. Numbers for products are established in a configuration management (CM) plan. The configuration management plan is how changes will be tracked and controlled. Traceability is a key part of managing change.
Traceability ensures completeness, that all lower level requirements come from higher level requirements, and that all higher level requirements are allocated to lower level ones. Traceability also provides the basis for test planning.
Below is a simple traceability matrix structure. There can be more things included in a traceability matrix than shown. In traceability, the relationship of driver to satisfier can be one-to-one, one-to-many, many-to-one, or many-to-many.
Sample Traceability Matrix
A traceability matrix is a report from the requirements database or repository. What information the report contains depends on your need. Information requirements determine the associated information that you store with the requirements. Requirements management tools capture associated information or provide the capability to add it.
The examples show forward and backward tracing between user and system requirements. User requirement identifiers begin with "U" and system requirements with "S." Tracing S12 to its source makes it clear this requirement is erroneous: it must be eliminated, rewritten, or the traceability corrected.
For requirements tracing and resulting reports to work, the requirements must be of good quality. Requirements of poor quality transfer work to subsequent phases of the SDLC, increasing cost and schedule and creating disputes with the customer.
A variety of reports are necessary to manage requirements. Reporting needs should be determined at the start of the effort and documented in the requirements management plan.
Communication Plan
Communication Planning
It is surprising how few projects actually have a communication plan which shows any thought. The attitude seems to be that we will just keep people informed as we go along. On the other hand, in staff surveys, communication is right at the top of people's complaints. Perhaps project teams are part of the problem.
Who to talk to
This is a very simple question to answer. You need to talk with the key stakeholders. If you have identified the key stakeholders, you have identified those who need to know. Your audience. What they need to know will differ.
There are also stakeholders that don't make the "Key" list who you need to keep in the loop. Typically these people have some peripheral involvement in the process, and you need to understand why, and if they need to be included in the plan. Often, they are happy to either ask specific questions, or access particular information themselves.
What to tell them
A simple response is to ask "What do you want to know?" Each key stakeholder is a stakeholder for one or more reasons. If you have defined the roles and responsibilities for the project, the reason should be obvious. For example, the Test Manager is responsible for preparing test plans, carrying out testing, and signing off the software as being ready to move into production. They are interested in timing because they have to schedule the testing. They are interested in scope variations that might change the scope of their testing.
They are probably not interested in financial reporting unless it will have an impact on the budget available for testing. Having identified each stakeholder, identify why they are a stakeholder, and what they need to know in that role. Too much information can be as bad as not enough. Keep the information limited to what each person or group might need to do their job. If people ask for more, by all means give it, but try to start with a clear definition of what goes to whom.
When to tell them
Ask the question "How often will the information change?" For a schedule, it might be weekly. For a financial summary it might be monthly. Look at each piece of information, and identify how often it varies significantly. This will determine your timing.
How to tell them
Each project will have a number of communication events. These may be weekly reports, project board meetings, newsletters, or a myriad of communication activities. Each of these must be designed to fulfil its purpose. There are two basic ways to tell people.
• You can use a medium that relies on: "Push" where the information is pushed to them in a memo, email, or presentation
or
• "Pull" where the information is available, but they have to go find it. A web site is a good example of "pull"
In most cases, you will use "Push". "Pull" is more useful for minor stakeholders, or detailed information that not everyone wants to see. For example, you could send out a two page Executive Summary of a report via email, and have the other 50 pages available on an Intranet.
Another aspect is how to cut through the clutter. A presentation is likely to have more impact, but if you are not going to get a good attendance, an email may be a better option. I have seen the percentage of emails that are printed and read rather than read on screen, and it is surprisingly high. A printed memo might have more chance of being read (or at least scanned) than an email.
Who to tell
Not everything need come from the team. Involving senior management to make major announcements adds weight to the announcement. It also ensures that senior management have a higher level of commitment. Having the GM stand up in front of a group of people and announce something like a date to go live can bring a lot of support to meet that date.
Creating the plan
A communication plan should be developed prior to the project beginning. It should be created by both business and IT. At an even higher level, discussion should take place as to the necessity of developing a change management plan, of which a communication plan is part. Change Management A change management plan should be produced if the project is going to have a significant effect on how the organisation operates. You need to balance this against how agile the organisation is in handling change.
For example, if there is obviously strong resistance to the implementation of a new system which will force amalgamation of several departments, and major business process change, you should be looking at managing that change. Communication is only part of the process. Change management should also cover training, HR counseling, salary negotiations, user involvement and many other aspects. It is beyond the scope of this white paper to discuss change management.
Bringing it all together
A communication plan should cover the following headings.
• Audience. Who should receive the communication?
• Reason. Why you are communicating with them. Why are they a key stakeholder.
• Event. The communication, be it a weekly report, or a presentation to the board.
• Responsible. Who is responsible for preparing and scheduling the piece of communication.
• Medium. The way in which it will be delivered.
• Timing. How often it will be presented.
• Content. What it will contain. This should address the reason the audience will be interested in the project
It is surprising how few projects actually have a communication plan which shows any thought. The attitude seems to be that we will just keep people informed as we go along. On the other hand, in staff surveys, communication is right at the top of people's complaints. Perhaps project teams are part of the problem.
Who to talk to
This is a very simple question to answer. You need to talk with the key stakeholders. If you have identified the key stakeholders, you have identified those who need to know. Your audience. What they need to know will differ.
There are also stakeholders that don't make the "Key" list who you need to keep in the loop. Typically these people have some peripheral involvement in the process, and you need to understand why, and if they need to be included in the plan. Often, they are happy to either ask specific questions, or access particular information themselves.
What to tell them
A simple response is to ask "What do you want to know?" Each key stakeholder is a stakeholder for one or more reasons. If you have defined the roles and responsibilities for the project, the reason should be obvious. For example, the Test Manager is responsible for preparing test plans, carrying out testing, and signing off the software as being ready to move into production. They are interested in timing because they have to schedule the testing. They are interested in scope variations that might change the scope of their testing.
They are probably not interested in financial reporting unless it will have an impact on the budget available for testing. Having identified each stakeholder, identify why they are a stakeholder, and what they need to know in that role. Too much information can be as bad as not enough. Keep the information limited to what each person or group might need to do their job. If people ask for more, by all means give it, but try to start with a clear definition of what goes to whom.
When to tell them
Ask the question "How often will the information change?" For a schedule, it might be weekly. For a financial summary it might be monthly. Look at each piece of information, and identify how often it varies significantly. This will determine your timing.
How to tell them
Each project will have a number of communication events. These may be weekly reports, project board meetings, newsletters, or a myriad of communication activities. Each of these must be designed to fulfil its purpose. There are two basic ways to tell people.
• You can use a medium that relies on: "Push" where the information is pushed to them in a memo, email, or presentation
or
• "Pull" where the information is available, but they have to go find it. A web site is a good example of "pull"
In most cases, you will use "Push". "Pull" is more useful for minor stakeholders, or detailed information that not everyone wants to see. For example, you could send out a two page Executive Summary of a report via email, and have the other 50 pages available on an Intranet.
Another aspect is how to cut through the clutter. A presentation is likely to have more impact, but if you are not going to get a good attendance, an email may be a better option. I have seen the percentage of emails that are printed and read rather than read on screen, and it is surprisingly high. A printed memo might have more chance of being read (or at least scanned) than an email.
Who to tell
Not everything need come from the team. Involving senior management to make major announcements adds weight to the announcement. It also ensures that senior management have a higher level of commitment. Having the GM stand up in front of a group of people and announce something like a date to go live can bring a lot of support to meet that date.
Creating the plan
A communication plan should be developed prior to the project beginning. It should be created by both business and IT. At an even higher level, discussion should take place as to the necessity of developing a change management plan, of which a communication plan is part. Change Management A change management plan should be produced if the project is going to have a significant effect on how the organisation operates. You need to balance this against how agile the organisation is in handling change.
For example, if there is obviously strong resistance to the implementation of a new system which will force amalgamation of several departments, and major business process change, you should be looking at managing that change. Communication is only part of the process. Change management should also cover training, HR counseling, salary negotiations, user involvement and many other aspects. It is beyond the scope of this white paper to discuss change management.
Bringing it all together
A communication plan should cover the following headings.
• Audience. Who should receive the communication?
• Reason. Why you are communicating with them. Why are they a key stakeholder.
• Event. The communication, be it a weekly report, or a presentation to the board.
• Responsible. Who is responsible for preparing and scheduling the piece of communication.
• Medium. The way in which it will be delivered.
• Timing. How often it will be presented.
• Content. What it will contain. This should address the reason the audience will be interested in the project
Agile Methodology
What is Agile?
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
The term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.[
Agile Principles
To help people to gain a better understanding of what agile software development is all about, we can refine the philosophies captured in their manifesto into a collection of twelve principles. These principles are:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software. Or, perhaps the problem is that they think that they need to define everything up front before they can start building software, whereas an evolutionary approach to development seems to work much better.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Like it or not, requirements will change throughout a software development project. Traditional software developers will often adopt change management processes which are designed to prevent/reduce scope creep, but when you think about it these are really change prevention processes, not change management processes. Agilists embrace change and instead follow an agile change management approach which treats requirements as a prioritized stack which is allowed to vary over time.
3. Deliver working software frequently, from a week to a couple of months, with a preference to the shorter time scale. Frequent delivery of working software provides stakeholders with concrete feedback, making the current status of your project transparent while at the same time providing an opportunity for stakeholders to provide improved direction for the development team.
4. Business people and developers must work together daily throughout the project. Your project is in serious trouble if you don't have regular access to your project stakeholders. Agile developers adopt practices such as on-site customer and active stakeholder participation, and adopt inclusive tools and techniques which enable stakeholders to be actively involved with software development.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Too many organizations have a vision that they can hire hordes of relatively unskilled people, provide them with a CMMI/ISO/...-compliant process description, and that they will successfully develop software. This doesn't seem to work all that well in practice. Agile teams, on the other hand, realize that you need build teams from people who are willing to work together collaboratively and learn from each other. They have the humility to respect one another and realize that people are a primary success factor in software development.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For software development team to succeed its members must communicate and collaborate effectively. There are many ways which people can communicate together, and as you can see face-to-face communication at a shared drawing environment (such as paper or a whiteboard) is the most effective way to do so.
7. Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of "earned value" measure based on the delivery of documentation of the holding of meetings.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Just like you can't sprint for an entire marathon, you can't successfully develop software by forcing people to work overtime for months at a time. My experience is that you can only do high-quality, intellectual work for 5-6 hours a day before burning yourself out. Yes, the rest of the day can be filled up with email, meetings, water cooler discussions, and so on, but people's ability to do "real work" is limited. Yes, you might be able to do high-quality work for 12 hours a day, and do so for a few days straight, but after awhile you become exhausted and all you accomplish is 12 hours of mediocre work a day.
9. Continuous attention to technical excellence and good design enhances agility. It's much easier to understand, maintain, and evolve high-quality source code than it is to work with low-quality code. Therefore, Agilists know that they need to start with good code, to keep it good via refactoring, and take a test-driven approach so that they know at all times that their software works. We also adopt and follow development guidelines, in particular coding guidelines and sometimes even modeling guidelines.
10. Simplicity – the art of maximizing the amount of work not done – is essential. Agile developers focus on high value activities, we strive to maximize our stakeholder's return on investment in IT, and we either cut out or automate the drudge work.
11. The best architectures, requirements, and designs emerge from self-organizing teams. This is one of the most radical principles of the agile movement. The Agile Model Driven Development (AMDD) and test-driven design (TDD) methods are the primary approaches within the agile community for ensure the emergence of effective architectures, requirements, and designs.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Software process improvement (SPI) is a continual effort, and techniques such as retrospectives should be adopted to enable you to improve your approach to software development.
Stop for a moment and think about these principles. Is this the way that your software projects actually work? Is this the way that you think projects should work?
Re-read the principles once again. Are they radical and impossible goals as some people would claim, are they meaningless motherhood and apple pie statements, or are they simply common sense? My belief is that these principles form a foundation of common sense upon which you can base successful software development efforts
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams.
The term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
Conceptual foundations of this framework are found in modern approaches to operations management and analysis, such as lean manufacturing, soft systems methodology, speech act theory (network of conversations approach), and Six Sigma.[
Agile Principles
To help people to gain a better understanding of what agile software development is all about, we can refine the philosophies captured in their manifesto into a collection of twelve principles. These principles are:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software. Or, perhaps the problem is that they think that they need to define everything up front before they can start building software, whereas an evolutionary approach to development seems to work much better.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Like it or not, requirements will change throughout a software development project. Traditional software developers will often adopt change management processes which are designed to prevent/reduce scope creep, but when you think about it these are really change prevention processes, not change management processes. Agilists embrace change and instead follow an agile change management approach which treats requirements as a prioritized stack which is allowed to vary over time.
3. Deliver working software frequently, from a week to a couple of months, with a preference to the shorter time scale. Frequent delivery of working software provides stakeholders with concrete feedback, making the current status of your project transparent while at the same time providing an opportunity for stakeholders to provide improved direction for the development team.
4. Business people and developers must work together daily throughout the project. Your project is in serious trouble if you don't have regular access to your project stakeholders. Agile developers adopt practices such as on-site customer and active stakeholder participation, and adopt inclusive tools and techniques which enable stakeholders to be actively involved with software development.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Too many organizations have a vision that they can hire hordes of relatively unskilled people, provide them with a CMMI/ISO/...-compliant process description, and that they will successfully develop software. This doesn't seem to work all that well in practice. Agile teams, on the other hand, realize that you need build teams from people who are willing to work together collaboratively and learn from each other. They have the humility to respect one another and realize that people are a primary success factor in software development.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For software development team to succeed its members must communicate and collaborate effectively. There are many ways which people can communicate together, and as you can see face-to-face communication at a shared drawing environment (such as paper or a whiteboard) is the most effective way to do so.
7. Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of "earned value" measure based on the delivery of documentation of the holding of meetings.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Just like you can't sprint for an entire marathon, you can't successfully develop software by forcing people to work overtime for months at a time. My experience is that you can only do high-quality, intellectual work for 5-6 hours a day before burning yourself out. Yes, the rest of the day can be filled up with email, meetings, water cooler discussions, and so on, but people's ability to do "real work" is limited. Yes, you might be able to do high-quality work for 12 hours a day, and do so for a few days straight, but after awhile you become exhausted and all you accomplish is 12 hours of mediocre work a day.
9. Continuous attention to technical excellence and good design enhances agility. It's much easier to understand, maintain, and evolve high-quality source code than it is to work with low-quality code. Therefore, Agilists know that they need to start with good code, to keep it good via refactoring, and take a test-driven approach so that they know at all times that their software works. We also adopt and follow development guidelines, in particular coding guidelines and sometimes even modeling guidelines.
10. Simplicity – the art of maximizing the amount of work not done – is essential. Agile developers focus on high value activities, we strive to maximize our stakeholder's return on investment in IT, and we either cut out or automate the drudge work.
11. The best architectures, requirements, and designs emerge from self-organizing teams. This is one of the most radical principles of the agile movement. The Agile Model Driven Development (AMDD) and test-driven design (TDD) methods are the primary approaches within the agile community for ensure the emergence of effective architectures, requirements, and designs.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Software process improvement (SPI) is a continual effort, and techniques such as retrospectives should be adopted to enable you to improve your approach to software development.
Stop for a moment and think about these principles. Is this the way that your software projects actually work? Is this the way that you think projects should work?
Re-read the principles once again. Are they radical and impossible goals as some people would claim, are they meaningless motherhood and apple pie statements, or are they simply common sense? My belief is that these principles form a foundation of common sense upon which you can base successful software development efforts
Problem Solving Process
Problem Solving Process
Problem solving includes the following steps:
1. Identification of the problem: “What is the problem? What went wrong? What can go wrong? ”
2. Evaluation of the problem: “Hoe large is it?” "How large can it be?"
3. Analyses of the problem: “What are the reasons that this problem exists or can occur?
4. Establishing alternatives for treating the problem: “” What can be done to eliminate the problem or - if that is not possible - reduce it?”
5. Selection of best alternatives: “Which action nor combination of actions will provide the desired results for a minimum of effort and costs?”
6. Execution of selected actions.
7. Evaluation of the ay that the selected actions have been executed and correction as needed if not doen properly.
8. Evaluation of results and correction of actions (more or different) if desirred results are not being obtained.
9. Continuous investigation and analysis of deviations, losses, damages, accidents, etcetera that nevertheless occur leading to possible further correction of actions
Problem solving includes the following steps:
1. Identification of the problem: “What is the problem? What went wrong? What can go wrong? ”
2. Evaluation of the problem: “Hoe large is it?” "How large can it be?"
3. Analyses of the problem: “What are the reasons that this problem exists or can occur?
4. Establishing alternatives for treating the problem: “” What can be done to eliminate the problem or - if that is not possible - reduce it?”
5. Selection of best alternatives: “Which action nor combination of actions will provide the desired results for a minimum of effort and costs?”
6. Execution of selected actions.
7. Evaluation of the ay that the selected actions have been executed and correction as needed if not doen properly.
8. Evaluation of results and correction of actions (more or different) if desirred results are not being obtained.
9. Continuous investigation and analysis of deviations, losses, damages, accidents, etcetera that nevertheless occur leading to possible further correction of actions
Faulty iPhone 4 Problem
Apple today admitted that an algorithm used in its new smartphone is flawed and promised to update its iOS 4 in the next few weeks.
http://www.reuters.com/article/idUS406838022620100702
http://www.reuters.com/article/idUS406838022620100702
Thursday, July 1, 2010
Movie Masala : Green Zone (2010)
Green Zone (2010)
http://www.imdb.com/title/tt0947810/
Imdb User Rating : 7.1/10
hey folks the movie is worth watching. Matt daemon acting is cool n most fascinating was i didn't feel sleeping at any moment of the whole movie :P . I will give 4/5.
http://www.imdb.com/title/tt0947810/
Imdb User Rating : 7.1/10
hey folks the movie is worth watching. Matt daemon acting is cool n most fascinating was i didn't feel sleeping at any moment of the whole movie :P . I will give 4/5.
Whats the smallest unit of time?
Planck time (tP),
The smallest possible unit of time is known as "Planck's time"It is 5.4 x 10^-44 seconds.
0.000000000000000000000000000000000000000000054 seconds
The smallest possible unit of time is known as "Planck's time"It is 5.4 x 10^-44 seconds.
0.000000000000000000000000000000000000000000054 seconds
Subscribe to:
Posts (Atom)