Personal intro. Good afternoon everyone my name is Richard Minca. I’m the quality manager for OSA. I graduated from Monash Uni in 1993 with a B.E. and B.Sc. And completed a Grad Cert in Software Quality Assurance. I’ve worked at Honeywell Software Centre as a software engineer and quality systems engineer developing real time control systems and improving their software quality system. From their I moved to Australian Arrow. Has anybody heard of them? They are a part of the Yazaki group who turn over about $8billion/year. There I was maintaining a CAD system with the proposal of developing a new one. From their I moved to Datacraft who where then taken over by ComTech where I was a software engineer developing IVR and CTI solutions. After ComTech I moved to OSA where I have been a quality engineer then quality manager for the last 3 years. One of the benefits of moving around so much in such a short time is I’ve seen good and bad practices in companies to do with management, engineering and quality. Hence the focus of my lectures over the next 2 days. So, if you have any questions during the presentation please keep them to yourself. I’m not really interested. No seriously, most questions are welcome and some will even be answered.
These are the topics I intend to race through over the next 2 lectures. What is Quality where we talk about some definitions and examine some principles in quality management. Then a discussion of current practices in management, engineering and process improvement practices. Along the way I hope we can look at some case studies to reveal these techniques.
Well we instinctively know what it isn’t. Anything that crashes or breakdowns when you’re doing simple tasks - whether it be software to a car. Dud stapler that doesn’t staple all the way through the document. Buckled staples. Quality doesn’t necessarily mean expensive. A sponge does the job of cleaning up spills but is a relatively inexpensive item. Question: Can anyone give me a definition of what is quality? Show point 1 And just as important to meet requirements is to meet expectations But that’s from the customer’s perspective. Its no good doing a job if we go broke or get sued doing it or the risks are too high. Question: What does quality mean from the business perspective. Show point 2
How we do it as well as what we are doing.
Question: What sort of factors or characteristics do we need to consider in ‘Meeting requirements’ and hence development a quality product? Looking for 12. For external and internal customers it means the following things. Product has quality factors or characteristics which enables us to meet requirements. Functionality - Satisfies the specifications and fulfils the user’s objectives. Correctness is low defect densities. We measure critical, serious, medium and low defect densities against a set of release criteria. Usability - Effort required to learn, operate, prepare, input and interpret the output of a system or program. How might we measure this? Time taken to learn a series of operations, the number of mouse clicks to perform an operation or the number of defects submitted that are user errors. Reliability - Extent to which a product can be expected to perform its intended function with required precision. Typically, think about the frequency between failures or the length of time a system can run non-stop before failing. We measure this through defect densities and by performing volume testing. Performance/Efficiency - Amount of computing resource and code required by a system or program to perform a function. Response to user. We assess this by performing volume testing and measuring the timeit takes for a sytem to respond to a user and watching memory, CPU and network traffic trends. Supportability - Effort required to locate and fix an error in an operational system or program.
Localisation – Effort required to ensure a program can operate in another languag. OSA is now looking at localisation issues and the cost there is litterally months of effort. Testability - Effort required to test a system or program to ensure that it performs its intended function. Comes back to requirements, how understandable are they and how easy to validate. Portability - Effort required to transfer a system or program from one hardware configuration and/or environment to another. This was very a important requirement at OSA. We developed a tool called OpenUI which was a cross platform client server GUI development tool. It had to run on Windows 3.1 to Windows 98 to Windows NT4. It had to run on many different flavours of Unix and Linux. It had to run on MacIntosh. Developed coding edicts. Developed a portability library which allowed for OS specific functionality and catered for the differences and problems that different Oses had. Modifiability - Effort required to modify or enhance an operational system or program. How long does it take to fix a defect or add an enhancement. Important measure as it is directly related to the cost of quality. Re-useability - Extent to which a system product can be used in other applications - related to the packaging and scope of the functions that the product performs. We typically think of this from an internal perspective where we have a team working on the development of a common library for use by engineers. This is supposed to reduce product development time because the infrastructure is already there. Integrity - Extent to which access to software or data by unauthorised persons can be controlled. How secure is your data? Can you forge your way on to a system and do malicious things. We run tasks with the system account because it apparently can’t be forged. Compatibility - Effort required to couple or interface one system with another.
Point 1 There are three areas we want best practice in. Question: Can anyone list those areas? Point 2 We will cover these practices in a little more detail as we move on to the project management, software engineering and process improvement aspects of the lectures.
Question: Anyone tell me what the unit of measurement is for the cost of quality? Question: We have 4 categories for measuring the cost of quality. What sort of categories do we have when we measure the cost of quality? Typical organisations have 79c in every software dollar spent on cost of quality activities. Up to 68c on failure. Best practice organisations have about 15c or less spent on failure costs. When I was the quality manager at Honeywell we were down to 15% failure costs with around 12% appraisal and prevention costs.
What activites are required to prevent errors and to do the job right the first time? Incurred before the product is developed. Audit the project and process against the software development process. Is management committed to producing a quality product or are they paying lip service to quality. As soon as the next big pressure items hits quality management is out the window. Plan for quality via requirements, project planning, process improvement. Having a defined process so that everyone understands their responsibilities and what they need to do next to achieve a result. Appropriate work conditions. Australian Arrow and Yazaki in Western Samoa. They wanted to make fresh drinking water at the plant a part of an enterprise agreement. They couldn’t understand why people would rather go to the beach then come to work in a sweaty tin shed. Training of peoplein appropriate quality, engineering and management processes.
What activities are required to review completed products against requirements? Includes money spent on inspections, testing and reviews. Incurred after the product is developed but before it is installed. In particular, technical inspections and meeting with your users are effective in reducing the cost of quality. They take up little time but will give big benefits. Do inspections during the requirements and design phase. This is where the big benefit is. Meet with your users or key stakeholders before the project starts - helps in getting requirements and scoping the work and on a regular basis to demonstrate achievements so far. Testing is probably the most expensive appraisal activity. It happens at the end of the lifecycle and hence the costs of fixing things are a lot more than if defects had been discovered via inspection. Error condition handling, validation of data being entered. Say no more. If you’re not doing this then as the “Drink Drive add” says you’re a bloody idiot.
Evil failure: Money wasted on defective products. Includes money spent on repairing faulty products, on operating them, on damage incurred by using them and because the product was not available. Incurred after the product is installed Some failure costs are incurred by the developer and some by the user.
Some great case studies on software development failure: The “automated federal income tax form process system” IRS in 1980 couldn’t handle the workload, cost twice as much as was estimated (at a cost of US$103 million, $206 million Pacific Pessos) and needed to replaced almost as soon as it was installed. President Reagan’s Strategic Defence Initiative. Many software engineers estimate that a system for the SDI would require 100 million lines of code. Order of magnitude larger than anything ever developed before. How would you test that? Can you guarantee the reliability. Therac 25 radiation therapy and X-ray machine. It malfunctioned and killed several patients. Gave out highly concentrated does of radiation when low levels were intended. Space Shuttle Columbia – First scheduled launch in April 1981 was cancelled because of what was revealed to be a synchronisation problem with the shuttle’s five on-board computer. At this stage the project was 3 years late and millions of dollars over budget. The synchronisation problem was introduced two years earlier.
Business modeling What is the business case for doing this work? What is the ROI? We’re not just pursuing sexy technology for the hell of it. There has to be a ROI? Business people are looking for a return of about 5 times the cost of the project and its support. Requirements analysis. Fundamental to quality. Analyse the problems and identify the needs. From here develop the use cases and non-functional requirements that meet our customers needs or quality objectives while ensuring that the business case is still supported. Design How are we going to solve the requirements in computer speak. Implementation. Code, code, code and unit test. Software Testing Does the software do what we say it is going to do. Software Release & Deployment Ready for manufacturing Commissioning at customer sites. Administration Timesheets, leave forms, etc.,
To do with prevention - detect and correct early. Detect and correct defects as soon as they are introduced into the development. The reason is: The longer defects go undetected, the more expensive they become to correct. Easy to fix, just a sentence on a piece of paper. UML diagram somewhere. However once the product has been implemented, fixing takes longer. Code changes, re-compile the system, update design and requirements work if defect is significant. Once rolled out onto customer sites then the cost is even more. HP say if they have a critical defect in their embedded printer software they lose all their profit for that printer line if they have to replace the firmware. Imagine in OSA’s case where we work with customers that have 10000’s desktops if we had to replace the software on all those desktops. What would the cost be? Enormous.
But wait! This is for a manufacturing environment. Does the same apply to a software environment. % Defective products Manufacturing depends on machinery with random and systematic errors. You can get rid of the systematic errors but hard to get rid of the random ones. What we aresaying is that to reduce the % of defective products is not worth the cost and to increase the number would cost to much.
Software is typically a critical product which means that the cost of failure rises steeply as the percentage of defects increases. Evidence also suggests that zero defects (or close to it) can be achieved within a finite and reasonable cost of prevention and appraisal - the increase is not excessive as the percentage of defects approaches zero.
So what, is the acceptable level of quality for software. Zero defects or close to it.
This is an overview of some of the things that I’ll cover as a part of project management
Can anyone give me a definition for a project? Project should have a sound business case as to why the work should be done in the first place.
Management practices. “ Plan the Work…Work the Plan.” Unlike this guy we want to make sure that we know where we are going!!
Won’t go into people management in a great amount of detail. This in itself would be a PhD course. I’ll talk about a couple of basic principles and then some practices that we implement at OSA for managing people.
Why is this the most important part of a manager’s job? General ‘Stormin’ Norman Schwarzkopf tells a story about when he was a young officer he had just been re-assigned and he met his new CO for the first time. CO go and tell tanks, go to cannon guns. Nothing happened. You can manage a fleet of tanks, a computer system but to produce magnificent results you need to lead people to achieve the objectives. Because it’s the people that deliver the results. Get the wrong people you won’t get the results or you’ll be sacking them in 6 months time. This is really, really important because no amount of process over-specification will ever make a bad engineer a good engineer. Task matching is associated with motivation. People are motivated by self interest and the desire to do a good job and have fun (not just money). Once you understand an individual’s capability and career desire’s you’re better able to match appropriate tasks for them to do. Team formation. You’ve all heard of the forming, storming, norming, performing, celebrating, mourning lifecycle of a team. Storming handled by focusing on issues not people. Once know issues and what want to achieve it easier to moving to norming and performing. Celebrating and mourning. Product release celebration days and retrospectives to flush out good and bad issues to do with a project.
SMART Objectives: Stretching; Measurable; Achievable; Result, not activity; Time-limited Make sure that they are stretching (except for the first project). That the result is measurable (because what gets measured gets done) It is achievable. That is we’re not setting anyone up for failure and you don’t have to be superman to achieve. The objectives given very specific description of the results that are to be achieved. No grey or fuzzy areas that are may be interpreted ambiguously. The time that it is to be achieved by. Take the estimates of your people and then set the stretching part of the objective. One Minute manager One minute goals. See above. Very clear what our responsibilities are. Basically the objectives and performance standards should take no longer than 1 minute to read, around 250 words. One minute praisings. More often than not people only get told when they do something wrong. That means it can take a very long time to work out how you should be doing something right. One minute praisings catch people doing something approximately right, and tell them immediately they did it right. It tells them specifically what they did right so they know what to do and continue to make better. Tell your staff how that makes you feel as their manager. This is easy to do when people know what they have to achieve and what the performance standards are. One minute reprimands are similar to one minute praisings. Reprimand them immediately by telling them specifically what they did wrong. Tell your staff how that makes you feel as their manager. Do reaffirm that you think well of them but not their behaviour in this situation. Now there is some touchy feely gooey stuff as well as part of this one minute management. The pregnant pause. It’s to let people know that as there manager you truly care about them, there performance and that you believe they can make a valuable contribution to the organisation.
Command for product development Project Management Understanding of the customer, technology and people. Manages change and enables team to manage change Product Manager Continually examining the target market Understands what pushes the buttons of clients and how the product payload will benefit these clients. Enables focus on product features and services Makes it clear what needs development for short project cycles Constant communication with product teams Service Oriented People Build stronger ties with customers Focuses organisation on delivering service to customers Result: Aids product development through VOC $ is for products. These targets are easy strikes for existing customers. Product Architects Having a robut architecture makes it easier to change and hit project targets. Big picture – understand benefits to customer as well as good architects. R&D function – helps eliminate architectural rot. In early development phases allows assessment of architectural alternatives that will allow product to continue to meet the needs of the customers and the product vision. Eliminating architectural rot – Investing in the product architecture a little bit at a time in the relevant development areas for the product cycle. This enables fulfillment of the architecture big picture by ensuring that we build a skyscraper and not a Tower of Pisa. Troops Engineers Best and most experienced in their field They have a productivity different of 20:1 between the outstanding performer and an average performer. Even more if you believe in negative productivity. Continually good performers, they understand the problem domain and the solution domain and have proven successful project experience. That’s important because “Technology is no substitute for experience.”
OK. Let’s move away from this fuzzy people stuff and start dealing with things that are tangible, like a project plan. What is the first thing we want to do as part of a project plan? Scope defines the body of work and objectives that are to be achieved by the project team. When we understand the boundary of work, that is the scope, we can define the what objectives will be developed for the project, what won’t be and what is unresolved. You’ll find that objectives that aren’t in scope or aren’t resolved are more contentious than ones that are in scope. Once scope has been identified the objectives should be prioritised. This helps identify the project targets and enables the project to keep focused on incremental delivery of results. Identifying who your key stakeholders and sponsors are will be instrumental to your project success. They have influence over the direction and funding of the project. Important to get all project participants involved in defining the plan. This is a form of joint application development. Get product management, project management, engineers, customers and field personnel involved as appropriate. This gives context to people so that they understand the issues and get a good feel for what the project is about. This makes planning quite quick and ensures that a good plan that has thought of the project risks can be developed. Examples. SMS project plan and Minnow project plans
Measurement It’s an integral part of determining the status of the project and how successful it is. This helps in determining when corrective action needs to be taken. What do the sliders mean? Well the more to the right they are the more important meeting these goals are for the success of the project. Some are conflicting in nature and the more sliders that are full on the greater the risk of the project not being successful. Example, if the product on time slider and the quality requirements slider are full on what do you think the risk of the project might be like. Project measurements & product measurements. Cover these later. Examples: SMS project plan sliders
Project risk summary. Every project must have a running risk and issues list. If you don’t identify and attack your risks they will bring your project to a halt. When planning your project it helps to paranoid and think about all the worst case things that may happen and how they may be contained. So you need to identify the risks and assess them and their impact, put in place a mitigation plan so that they don’t stop the project and think of contingencies in case the risk does eventuate. Must attack risks before that get you. Everyone’s responsibility, from project manager to engineer to stakeholder to identify and help mitigate. Process tailoring is the strategy of how to deliver the project objectives using an organisations standard process. This means you take the process and identify areas where it doesn’t quite suit the project. These areas are defined and the project plan puts new arrangements in place that better suit the project. Tailoring the process helps us to manage the management and technical complexity of a project by ensuring that the process will help to hit targets and do it quickly. So, how do we strike quickly? Well Dr. Boehm discovered this great relationship for effort in a project: Effort = Effort Adjustment Factor * Size ^Process EAF - Of course, we all know what EAF is. Well it was clear to me! EAF = Domain, Personnel, Environment, Tools, Quality Effort = (Personnel) (Environment) (Quality) (Size ^ Process) This means our continuous improvement activities are focused on reducing development effort which has a significant reduction in our time to market. In effect, it tells us that continuous improvement happens with all aspects of the 4P’s Well, as we know, despite having been told otherwise, size counts. And reducing size or complexity, the amount of human generated stuff reduces the effort required. Means we get to the target quicker. (Components, modeling) But by the same token, quality, like size, is important too. Are you just as confused as I am on that particular issue? Trading off or backing off on quality thresholds allows us to reduce the effort required in terms of product features, performance, and rework. Improving the development process by focusing on iterative development and architecture 1st. Avoiding non-value added process activities (rework, delays, communications overhead) Developing an adequate solution in minimum steps and iterations) Using more-skilled personnel and better teams.. Enhancing capabilities and application domain. Using better environments. Tools to automate process. Making steps more efficient. In particular use of an iterative lifecycle model that is use case driven and architecture centric will ensure you deliver results early and mitigate your high level risks early on. Constant process tailoring throughout the project life will allow us to continually work the plan to hit the target. Examples: SMS Project Risk Assessment and Risk Summary. Product suitable for use. Examples: Process Tailoring. Strategy for hitting the target.
Three forms of estimation: - Guess: an unsupported prediction - Guesstimate: A guess based on relevant expereince, undocumented information, or history. - Estimate: A prediction on experience, history or information formally recorded. Estimates are aided by - Sizing techniques like Function point analysis, full function points and use-case points, can’t be used for everything though. - Metrics database recording project effort for a task. Get comparison of effort for like tasks. - By understanding what tasks need to be performed to deliver the result. BAW Use BAW to capture the range of uncertainty in an estimate Qualification of the estimate is often made by stating a risk factor of low, medium or high. This risk factor is used in order to help determine the figures from each B/A/W estimate to use Get multiple people to estimate. Based on individual analysis of tasks to be done and estimates for those. Then a meeting to thrash out those tasks. Productivity Research has shown a range of worst to best developers anywhere from 1 to 30 times the productivity. Make sure that people who are doing the tasks have estimated them. Don’t someone else’s and substitute them. Examples: CLSC Estimates for Error Buffer work
Now that scope, risks, process has been tailored and the estimates have been collated the project schedule can be put together. Here we set out to define the phases and the iterations with in each phase. Each phase and iteration must have a set of defined deliverables. Example: Gannt
Essentially, the project status is concerned with management information regarding the following project parameters: Schedule: Are we meeting it? If not, what issues have caused this slippage and how can we get back on track. Effort: Are we meeting costs budgets? If not, were the estimates right? Have people been able to work efficiently on their tasks or has there been firefighting activity. Re-Work: What is the cost of quality so far for the project so far? Starts to indicate signs of project spiralling out of control when failure costs escalate due to poor product quality and bad practices. Weekly status report What risks or issues have surfaced that need to be addressed? This is a very important aspect of the status report and weekly meeting. Need to have issues raised, discussed and resolved. They are a softer measure of the project success since they are very much to do with a person’s work. Examples: Newsgroups status emails – MJR status Milestone 45 degree chart – SMS Excel spreadsheet Inchpebbles from UDA – Indvidual and total
Size OSA has done some work with function points and are looking at use case points. LOC is typically used, not that it is a really good measure, but it can be used as a benchmarking ROT to compare the productivity of one project with another. It is not an upfront measure and should never be used between industries and orgnanisations. Quality
Example: nDG5.5 Defect trend graphs & release criteria Total trends – All, open, fixed Total open trend – Critical, serious Daily defect totals – New, fixed, progress Example: nDG5.5 Coverage trends
Example: Mitcham volume testing results Test Case Number JobQueue Size Time Taken to Distribute Job Flow Rate Test Case 1 2200 12240 6 Topology 3 consisted of a maximum of 31 physical computers. 1x Warehouse, 1 x Distribution Server, 10 x Deployment Location and 1 x Client. Sets of 10 and 100 virtual DLs were created to achieve the required number of DLs specified in table 6. Job Queue Size PC No. Packages DS Virtual DLs Merged Policies Client Settings Schedules 2200 31 10 10 100 10 1 1
Status updated on a weekly basis as part of team meeting. Formal reviews of project deliverables and status done at the end of each iteration and phase to determine if the exit criteria for the iteration or phase has been achieved. Timesheets have been entered and the project plan has been udpated as a result of the weekly meeting. Issues should be raised here and resolved or added to the risk list. Corrective action should taken as appropriate if the project is falling behind schedule or its quality targets. Corrective action can also be taken at the end of an iteration or phase review to address appropriate schedule and quality issues. Typically see deadlines change, scope reduced or more people added to the project. Working harder goes without saying.
Transcript of "OSA Lecture 1"
Project Management & Software Engineering Techniques to Achieve High Software Quality
Best Practices <ul><li>What areas do we want best practices? </li></ul><ul><ul><li>Management </li></ul></ul><ul><ul><li>Engineering </li></ul></ul><ul><ul><li>Quality Assurance </li></ul></ul>
Cost of Quality Figures Failure (Evil) New Development (What we want to do) Prevention (Good) Appraisal (Good) COQ Circle <ul><li>Unit is the $ </li></ul>
Cost of Quality Activities - Prevention <ul><li>Quality Audit </li></ul><ul><li>Management Commitment </li></ul><ul><li>Quality Planning </li></ul><ul><li>Development methodologies, standards & techniques </li></ul><ul><li>Appropriate Work Conditions </li></ul><ul><li>Quality Training </li></ul>
Cost of Quality Activities - Appraisal <ul><li>Preparation for Reviews </li></ul><ul><li>Walkthroughs / Reviews / Inspections </li></ul><ul><li>Phase / Milestone / Systems Reviews </li></ul><ul><li>Preparation for Testing </li></ul><ul><li>Systems / Acceptance Testing </li></ul><ul><li>Informal Meetings with Users </li></ul><ul><li>Error Condition Handling </li></ul>
Cost of Quality Activities - Failure <ul><li>Project Rework </li></ul><ul><li>Overtime, Idle Time </li></ul><ul><li>Delayed Systems Benefits </li></ul><ul><li>Malfunction and re-run Costs </li></ul><ul><li>Problem Determination / Maintenance </li></ul><ul><li>Execution of Contingency Plans </li></ul><ul><li>Delay, Poor Response Time </li></ul>
Cost of Quality Activities - Failure <ul><li>Employee Turnover, Training </li></ul><ul><li>Fatigue, Frustration, lack of Motivation </li></ul><ul><li>Lost Management Time </li></ul><ul><li>Loss of Credibility </li></ul><ul><li>Loss of Opportunity </li></ul><ul><li>Security / Legal Exposure Loss </li></ul>
Cost of Quality Activities - Work <ul><li>Business Modeling </li></ul><ul><li>Requirements Analysis </li></ul><ul><li>Coding & Unit Testing </li></ul><ul><li>Software Testing </li></ul><ul><li>Software Release & Deployment </li></ul><ul><li>Administration </li></ul>
Cost of Fixing Defects for Each Phase Cost 1 Specification Design Coding Testing Maintenance x10 x100
Acceptable Level of Quality Cost of Prevention plus Appraisal Cost of Failure Total Cost of Quality AQL Cost % Defective
Acceptable Level of Quality Cost of Failure Cost % Defective Total Cost of Quality Cost of Prevention plus Appraisal
Acceptable Level of Quality for Software <ul><li>Zero Defects (or close to it) </li></ul>
Project Management <ul><li>Best Practices </li></ul><ul><li>People Management </li></ul><ul><li>Project Planning </li></ul><ul><li>Project Tracking & Updating </li></ul><ul><ul><li>Status Reports </li></ul></ul><ul><ul><li>Metrics </li></ul></ul><ul><ul><li>Updating the Plan </li></ul></ul>
What is a Project? <ul><li>Projects change the status quo </li></ul><ul><ul><li>Else why do ‘em? </li></ul></ul><ul><li>Projects should have a sound business case before being started </li></ul><ul><li>A project is a related and interdependent set of activities that: </li></ul><ul><ul><ul><li>are related together to meet a set of objectives </li></ul></ul></ul><ul><ul><ul><li>have a number of defined starts and finishes over an extended period of time </li></ul></ul></ul><ul><ul><ul><li>are implemented by a team </li></ul></ul></ul>
Project Management Practices <ul><li>Define Roles and Responsibilities </li></ul><ul><li>Plan the Work </li></ul><ul><ul><li>Technical, Quality and Resource Planning </li></ul></ul><ul><li>Track Progress against Plans </li></ul><ul><li>Progressively Refine the Plans </li></ul>
People Management <ul><li>Recruitment </li></ul><ul><li>Performance Management </li></ul><ul><li>Role Types </li></ul>
Role Types <ul><li>Roles match people to tasks </li></ul><ul><li>Troops </li></ul><ul><ul><li>Engineers </li></ul></ul><ul><li>Command </li></ul><ul><ul><li>Project Manager </li></ul></ul><ul><ul><li>Product Manager </li></ul></ul><ul><ul><li>Service Oriented Staff </li></ul></ul><ul><ul><li>Product Architects </li></ul></ul>
Project Planning <ul><li>Scope decided by Key Stakeholders and Sponsors </li></ul><ul><ul><li>Who are they? </li></ul></ul><ul><li>Unresolved Stakeholder </li></ul><ul><li>Thingy 3.142 Product mngt </li></ul><ul><li>Out </li></ul><ul><li>Thingy 2 </li></ul><ul><li>In </li></ul><ul><li>Thingy 1 </li></ul><ul><li>Thingy 3 </li></ul><ul><li>Scope </li></ul><ul><ul><li>Objective Is In </li></ul></ul><ul><ul><li>Objective Is not In </li></ul></ul><ul><ul><li>Objective Is Unresolved </li></ul></ul><ul><ul><li>Priorities - Target Identification </li></ul></ul>
Project Planning <ul><li>Estimation </li></ul><ul><ul><li>Estimation vs Guesstimation </li></ul></ul><ul><ul><ul><li>Guess: an unsupported prediction </li></ul></ul></ul><ul><ul><ul><li>Guesstimate: a guess based on relevant experience, undocumented information or history </li></ul></ul></ul><ul><ul><ul><li>Estimate: a prediction based on experience, history or information formally recorded </li></ul></ul></ul><ul><ul><li>Best/Average/Worst (BAW) </li></ul></ul><ul><ul><ul><li>Best: assume everything goes better than expected </li></ul></ul></ul><ul><ul><ul><li>Average: assume that things go to plan </li></ul></ul></ul><ul><ul><ul><li>Worst: assume that things go worse than expected </li></ul></ul></ul><ul><ul><ul><li>Risk: qualification of risk is often made with L/M/H </li></ul></ul></ul><ul><ul><ul><li>Works best with multiple people estimating </li></ul></ul></ul><ul><ul><li>Productivity </li></ul></ul><ul><ul><ul><li>Remember variation between individuals </li></ul></ul></ul><ul><ul><ul><li>People doing the work should estimate it! </li></ul></ul></ul>
Project Planning <ul><li>Gantt Charts & Schedules </li></ul><ul><ul><li>Phases & Iteration </li></ul></ul><ul><ul><ul><li>Inception </li></ul></ul></ul><ul><ul><ul><ul><li>Define the scope of the project </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Develop business case </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Develop primary use cases </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Have a candidate architecture </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Mitigate critical risks </li></ul></ul></ul></ul><ul><ul><ul><li>Elaboration </li></ul></ul></ul><ul><ul><ul><ul><li>Project plan baselined </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Develop secondary use cases </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Architecture baselined </li></ul></ul></ul></ul><ul><ul><ul><li>Construction </li></ul></ul></ul><ul><ul><ul><ul><li>Refinement of use cases </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Detailed design (where appropriate) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Beta product available </li></ul></ul></ul></ul><ul><ul><ul><ul><li>User & training course material </li></ul></ul></ul></ul><ul><ul><ul><li>Transition </li></ul></ul></ul><ul><ul><ul><ul><li>‘ Last minute’ enhancement requests </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Manufacturing release quality in product </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Deploy to users </li></ul></ul></ul></ul>
Project Tracking & Updating <ul><li>Status Reports & Metrics </li></ul><ul><li>Updating the Plan </li></ul>
Project Tracking - Status <ul><li>Project Status </li></ul><ul><ul><li>Weekly Status </li></ul></ul><ul><ul><ul><li>Individual & Team Weekly Status Reports </li></ul></ul></ul><ul><ul><ul><ul><li>Achievements </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Objectives </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Issues & Risks </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Details schedule slipagge </li></ul></ul></ul></ul></ul><ul><ul><ul><li>Effort </li></ul></ul></ul><ul><ul><ul><ul><li>People </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Hours - Timesheets </li></ul></ul></ul></ul><ul><ul><ul><li>Inchpebbles </li></ul></ul></ul><ul><ul><li>Milestones </li></ul></ul><ul><ul><li>Iterations & Phases </li></ul></ul><ul><ul><li>Schedule </li></ul></ul><ul><ul><ul><li>Baseline - MS Project </li></ul></ul></ul><ul><ul><ul><li>Schedule slippage </li></ul></ul></ul><ul><ul><li>Re-work </li></ul></ul>
Project Tracking - Status <ul><li>Product Status </li></ul><ul><ul><li>Size </li></ul></ul><ul><ul><ul><li>Function Points & use case points </li></ul></ul></ul><ul><ul><ul><li>LOC </li></ul></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><ul><li>Defect Density </li></ul></ul></ul><ul><ul><ul><ul><li>Functional correctness, reliability </li></ul></ul></ul></ul><ul><ul><ul><li>Defect Trend Rates </li></ul></ul></ul><ul><ul><ul><ul><li>Reliability, supportability </li></ul></ul></ul></ul><ul><ul><ul><li>User monitoring </li></ul></ul></ul><ul><ul><ul><ul><li>Usability </li></ul></ul></ul></ul><ul><ul><ul><li>User error rate </li></ul></ul></ul><ul><ul><ul><ul><li>Usability </li></ul></ul></ul></ul>
Project Plan Updates <ul><li>Formal review milestones </li></ul><ul><ul><li>End of Iteration </li></ul></ul><ul><ul><li>End of Phase </li></ul></ul><ul><li>Take corrective action & Update Project Plan </li></ul><ul><ul><li>Dependent on Sliders </li></ul></ul><ul><ul><li>Rational Irrational </li></ul></ul><ul><ul><li>Change Deadlines Don’t Tell Anyone </li></ul></ul><ul><ul><li>Change Specifications Hope It Will Get Better </li></ul></ul><ul><ul><li>Overtly Degrade Quality Covertly Degrade Quality </li></ul></ul><ul><ul><li>Partition Product – Add Resources Leave Project </li></ul></ul><ul><ul><li>Better Technology Witch Hunt </li></ul></ul><ul><ul><li>Work Harder – Short Term Work Harder – Long Term </li></ul></ul><ul><ul><li>Blame Consultants/Clients </li></ul></ul>
End Result <ul><li>Use Project Management practices </li></ul><ul><li>and Quality Attributes </li></ul><ul><li>to deliver your stakeholders idea of a quality product </li></ul>
Further Info <ul><li>OSA - http://www.osa.com.au/common/ppt/missile.ppt </li></ul><ul><ul><li>ACS Presentation on 4P’s of Short Cycle Product Development </li></ul></ul><ul><li>The Thomsett Company – http://www. thomsett .com.au </li></ul>
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.