This document provides an overview of a PSP/TSP training course that will be held on September 16-17, 2010. The goals of the training are for participants to understand the purpose and uses of PSP/TSP, learn the basic processes and methods of PSP/TSP, and try using PSP/TSP on projects. The course agenda includes introductions to PSP/TSP on the first day along with planning, tracking, and quality control on the second day. The document also provides background on PSP/TSP, including how they help build individual and team skills and discipline to improve software development processes and outcomes.
The document discusses how the Personal Software Process (PSP) and Team Software Process (TSP) can be used to implement aspects of both Agile development and the Capability Maturity Model Integration (CMMI). PSP focuses on individual skills and discipline, while TSP builds on PSP to develop efficient, self-organizing teams. TSP/PSP teams can adapt Agile practices like iterative development and value delivery while achieving CMMI goals like defined processes and continuous improvement. Case studies show TSP/PSP reducing defects, rework, and improving productivity, quality, and maturity levels.
The Personal Software Process (PSP) and the Team Software Process (TSP) are process improvement frameworks tailored to produce virtually defect free software and deliver it on time.
The main focus of this speed talk is to state some of the similarities and differences between TSP/PSP and Scrum methodologies as well as some Agile practices. Why was there a need to blend these methods (TSP and Agile)? What were we trying to accomplish, or what was the goal here? The goal was to get the best of the TSP and Agile methods/models so that we could develop high quality products in a predictable and repeatable way to successfully tackle projects that are highly unpredictable, rapidly changing, with unknown final client, among others.
There are a few similarities between both management methods (TSP and SCRUM), as well as some differences. There also seems to be a lot of misunderstandings regarding TSP and this presentation will try to debunk some of them. TSP can be Agile too! – Incremental, iterative and adaptive.
Agile Portugal 2012
23 June 2012
The document summarizes the Team Software Process (TSP), which is a disciplined engineering practice developed by the Software Engineering Institute to produce reliable software in less time and at lower costs. TSP focuses on improving team performance through self-directed teams, integrated measurements, and quality reviews. Studies have shown that organizations using TSP achieve improvements in schedule, cost, productivity, and quality, including reducing post-release defects by 80% and balancing schedule and cost variances between -20% to 20%. TSP provides training and tools to implement the process over the course of about a month. A growing number of companies and government organizations have adopted TSP.
The document discusses operational best practices from the Team Software Process (TSP) and Architecture-Centric Engineering (ACE) approaches, including how TSP builds high-quality self-managed teams through methods like the Personal Software Process (PSP) for estimating and reducing defects, while ACE focuses on architectural analysis and tradeoffs to ensure systems meet quality goals. It also provides an example case study of how a financial organization in Mexico successfully used TSP+ACE to develop a new trading engine on an aggressive schedule while delivering high performance, quality, and reliability.
This document discusses implementing CMMI in an agile software development organization. It estimates that agile practices like Scrum already address around 65% of CMMI practices, with the remaining 35% requiring work in areas like risk management, configuration management, and quality assurance. The document provides a reference sheet mapping CMMI practices to agile outputs. It concludes that CMMI implementation is not difficult but requires training people in agile practices, tracking activities as evidence, and seeing CMMI as complementing rather than replacing agile practices, with management commitment key to success. The effort required depends on factors like existing agile maturity and resources.
This document provides an overview of several agile frameworks: Scrum, Kanban, Extreme Programming (XP), Lean, DSDM, and SAFe. It describes the key roles, events, and practices of Scrum. Kanban focuses on limiting work-in-progress to avoid bottlenecks. XP emphasizes rapid development through practices like pair programming and unit testing. Lean aims to eliminate waste. DSDM prioritizes work and collaboration. SAFe is a framework for implementing agile at an enterprise scale across multiple teams. The document compares Scrum, suited for small teams, to SAFe, which coordinates efforts across larger organizations.
Implementing distributed agile framework with
Scrum, XP & Effective Tools usage Dev ops. C. Padma presented this presentation during India Agile week 2015 - Bangalore
The document discusses how the Personal Software Process (PSP) and Team Software Process (TSP) can be used to implement aspects of both Agile development and the Capability Maturity Model Integration (CMMI). PSP focuses on individual skills and discipline, while TSP builds on PSP to develop efficient, self-organizing teams. TSP/PSP teams can adapt Agile practices like iterative development and value delivery while achieving CMMI goals like defined processes and continuous improvement. Case studies show TSP/PSP reducing defects, rework, and improving productivity, quality, and maturity levels.
The Personal Software Process (PSP) and the Team Software Process (TSP) are process improvement frameworks tailored to produce virtually defect free software and deliver it on time.
The main focus of this speed talk is to state some of the similarities and differences between TSP/PSP and Scrum methodologies as well as some Agile practices. Why was there a need to blend these methods (TSP and Agile)? What were we trying to accomplish, or what was the goal here? The goal was to get the best of the TSP and Agile methods/models so that we could develop high quality products in a predictable and repeatable way to successfully tackle projects that are highly unpredictable, rapidly changing, with unknown final client, among others.
There are a few similarities between both management methods (TSP and SCRUM), as well as some differences. There also seems to be a lot of misunderstandings regarding TSP and this presentation will try to debunk some of them. TSP can be Agile too! – Incremental, iterative and adaptive.
Agile Portugal 2012
23 June 2012
The document summarizes the Team Software Process (TSP), which is a disciplined engineering practice developed by the Software Engineering Institute to produce reliable software in less time and at lower costs. TSP focuses on improving team performance through self-directed teams, integrated measurements, and quality reviews. Studies have shown that organizations using TSP achieve improvements in schedule, cost, productivity, and quality, including reducing post-release defects by 80% and balancing schedule and cost variances between -20% to 20%. TSP provides training and tools to implement the process over the course of about a month. A growing number of companies and government organizations have adopted TSP.
The document discusses operational best practices from the Team Software Process (TSP) and Architecture-Centric Engineering (ACE) approaches, including how TSP builds high-quality self-managed teams through methods like the Personal Software Process (PSP) for estimating and reducing defects, while ACE focuses on architectural analysis and tradeoffs to ensure systems meet quality goals. It also provides an example case study of how a financial organization in Mexico successfully used TSP+ACE to develop a new trading engine on an aggressive schedule while delivering high performance, quality, and reliability.
This document discusses implementing CMMI in an agile software development organization. It estimates that agile practices like Scrum already address around 65% of CMMI practices, with the remaining 35% requiring work in areas like risk management, configuration management, and quality assurance. The document provides a reference sheet mapping CMMI practices to agile outputs. It concludes that CMMI implementation is not difficult but requires training people in agile practices, tracking activities as evidence, and seeing CMMI as complementing rather than replacing agile practices, with management commitment key to success. The effort required depends on factors like existing agile maturity and resources.
This document provides an overview of several agile frameworks: Scrum, Kanban, Extreme Programming (XP), Lean, DSDM, and SAFe. It describes the key roles, events, and practices of Scrum. Kanban focuses on limiting work-in-progress to avoid bottlenecks. XP emphasizes rapid development through practices like pair programming and unit testing. Lean aims to eliminate waste. DSDM prioritizes work and collaboration. SAFe is a framework for implementing agile at an enterprise scale across multiple teams. The document compares Scrum, suited for small teams, to SAFe, which coordinates efforts across larger organizations.
Implementing distributed agile framework with
Scrum, XP & Effective Tools usage Dev ops. C. Padma presented this presentation during India Agile week 2015 - Bangalore
This document provides an overview of a two-day software engineering process workshop for the Railroad Commission of Texas. It introduces the workshop facilitator and agenda. The workshop will cover the Capability Maturity Model, the Rational Unified Process, and a use case-centric software development process. It will explain the benefits of the workshop approach and follow an "Orville Redenbacher approach" of discussing topics at a high level before moving on.
The document discusses Agile SCRUM project development methodology. It provides an overview of SCRUM principles and processes including short iterative development cycles called sprints, daily stand-up meetings, sprint planning, tracking sprint backlogs and burn downs, sprint reviews and retrospectives. The roles of product owners, scrum masters and self-organizing cross-functional teams are also summarized.
This document provides an overview of different software development processes including the waterfall model, iterative model, Rational Unified Process (RUP), and Agile Development Process (ADP). It describes the key aspects of each process including phases, roles, artifacts, and ceremonies. Specifically, it provides detailed explanations of Scrum, an agile methodology, including Scrum roles like Product Owner and Scrum Master, ceremonies like the Daily Scrum, and artifacts like the Product Backlog and Sprint Backlog. The document concludes with references for further information.
- Scrum is an agile framework for managing complex projects using short development cycles ("sprints"), regular inspection of progress, and adaptation to change. It emphasizes communication, collaboration, and incremental delivery of work.
- Key Scrum roles include the Product Owner who prioritizes features, the Development Team who implements them, and the Scrum Master who facilitates the process.
- Core Scrum activities are Sprint Planning meetings, Daily Scrums, Sprint Reviews, and Sprint Retrospectives, which focus the team and enable inspection and adaptation.
- The Product Backlog contains prioritized features and the Sprint Backlog contains work for the current Sprint. A Burn Down Chart tracks progress. Scrum
- Scrum is an agile framework for managing product development, with roles of Product Owner, Scrum Master, and Development Team.
- Key rituals include Sprint Planning, Daily Stand-ups, Sprint Review and Retrospective.
- The Product Owner prioritizes features in the Product Backlog to maximize business value, while the Development Team works in sprints to deliver increments of functionality. The Scrum Master facilitates the process and removes impediments.
Agile Methodology in Software DevelopmentRaghav Seth
The document discusses various agile methodologies and frameworks, with a focus on Scrum. It defines Scrum as an agile process that allows teams to focus on delivering the highest business value in the shortest time through rapid inspection of working software every 2-4 weeks. Key Scrum roles include the Product Owner who prioritizes features, the Scrum Master who facilitates the process, and self-organizing Development Teams. Sprints involve planning, daily stand-ups, demos, and retrospectives to continuously improve.
Agile development focuses on effective communication, customer collaboration, and incremental delivery of working software. The key principles of agile development according to the Agile Alliance include satisfying customers, welcoming changing requirements, frequent delivery, collaboration between business and development teams, and self-organizing teams. Extreme Programming (XP) is an agile process model that emphasizes planning with user stories, simple design, pair programming, unit testing, and frequent integration and testing.
The document summarizes agile software development methods. It describes agile as an iterative approach that promotes adaptive planning, evolutionary development, rapid response to change, and close collaboration between self-organizing teams. The key characteristics of agile include iterative development with incremental releases, a people-oriented focus, lightweight processes, and test-driven development. The document also outlines the agile manifesto and lists benefits and situations where agile may not be suitable.
This document provides an overview of Agile and Scrum methodologies. It describes the iterative incremental model and compares it to the waterfall model. The key aspects of Agile include iterative development, early delivery of working software, collaboration between business and developers, self-organizing teams, and face-to-face communication. Scrum is then introduced as a framework for implementing Agile. The core Scrum roles, events, artifacts, user stories, estimation techniques, and burn down charts are defined and explained at a high level.
AGILE PORTUGAL 2016: Adopted agile in a CMMI L5 enterprise: what were the fin...Délio Almeida
This document outlines the results and experiences of a company adopting Agile practices within an existing CMMI Level 5 enterprise. It describes the 5 phases of the process improvement, including defining Agile methodology, conducting pilots, deploying improvements, monitoring deployment, and evaluating effects. Key results included certifying 40 Scrum Masters, achieving sprint goals 86% of the time on average, and preliminary indications of a 7% improvement in net margins. Challenges included maintaining an Agile culture and slower than expected introduction of new tools. Overall, the company was able to successfully blend Agile and CMMI practices and saw benefits from the adoption of Agile.
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
Module 1. Born to fail
- Why projects are failing
- Waterfall & traditional software development
Module 2. Agile
Module 3. Scrum
Module 4. Writing high quality software with Agile
- XP
- How Google Write Software
Module 5. Do's and dont's
- How Scrum might fail
- Myths and realities
Module 6. How to kick off Scrum
The document provides an overview of Scrum, an agile software development framework. It defines Scrum, discusses its history and introduction. It describes the Scrum framework, including roles like Product Owner and Scrum Master, events like sprint planning and review, and artifacts like product and sprint backlogs. It outlines the Scrum process and provides examples of Scrum applications. It discusses advantages like adaptability and faster delivery, and disadvantages like lack of documentation. It concludes that Scrum is popular for experienced teams that can self-organize, but requires strict adherence to be effective.
Pam, a project manager, initially dislikes the CMMI processes her company introduces but eventually wants to understand them better. However, her first experiences with process development, deployment, and appraisals are frustrating and negatively impact her project. The document outlines common reasons why project managers dislike the CMMI, such as unrealistic process requirements and evidence collection taking too much time. It advocates applying CMMI principles like ensuring processes are useful and appraisals don't hinder projects. Pam eventually realizes her struggles were just a dream and is able to apply CMMI in a practical way that improves her work.
Presentation provides agile tools and practices that workplace learning professionals can use with projects. Deck built for Learning Solutions 2014 with presenter notes
Detail Information about Agile Process Frameworks such as SCRUM and CMMI along with agile manifesto. Comparison between scrum and capability maturity model integration
I normally teach Introduction to Agile and Scrum over a 2 day session to teams. Here is a highly condensed 2-hour version of it that covers agile thinking and introduces scrum as a framework without getting into details.
I use it as a course material for teaching to teams or groups looking to get a perspective on "why" as opposed to "how" aspect of agile.
The document provides an overview of Scrum, an agile framework. It discusses the Scrum roles of Product Owner, Scrum Master, and Team. It describes Scrum artifacts like the Product Backlog, Sprint Backlog and how daily stand-ups, Sprint Planning, Reviews and Retrospectives work. Benefits are provided for customers, leadership and team members from adopting Scrum.
This document outlines a model for a sustainable agile transformation within an organization. It begins with an overview of agile basics and scaling agile approaches. It then discusses why agile transformations are difficult, focusing on achieving safety from different stakeholder perspectives. The model proposes defining an operational framework structured around teams, products, and services. It recommends introducing change incrementally, starting with independent pilot teams, and measuring improvement through coaching and assessment. The transformation aims to tie back to business drivers like predictability, quality, and early return on investment.
Building a Giant Atlassian Universe to Take Over the WorldAtlassian
Fidelity Information Services uses Atlassian tools to manage its software lifecycle from end to end, for massive, multi-million LOC financial applications including core banking and channels products. In this session Glen and Chris will share the high-level process flow for development at Fidelity. Attendees will leave with the tools to implement change in their own environments while maintaining control and assuring quality in a regulated environment.
The document discusses process improvement metrics and methods at the Jet Propulsion Laboratory (JPL). It notes that while JPL aims to perform like a CMMI Level 4 organization, it is actually assessed at CMMI Level 3. It outlines some of JPL's data collection methods and key questions around understanding their software environment. Some of the processes in place include tailoring software development processes and measuring performance against processes. Risks, strengths and recommendations are identified from process reviews.
This document provides an overview of a two-day software engineering process workshop for the Railroad Commission of Texas. It introduces the workshop facilitator and agenda. The workshop will cover the Capability Maturity Model, the Rational Unified Process, and a use case-centric software development process. It will explain the benefits of the workshop approach and follow an "Orville Redenbacher approach" of discussing topics at a high level before moving on.
The document discusses Agile SCRUM project development methodology. It provides an overview of SCRUM principles and processes including short iterative development cycles called sprints, daily stand-up meetings, sprint planning, tracking sprint backlogs and burn downs, sprint reviews and retrospectives. The roles of product owners, scrum masters and self-organizing cross-functional teams are also summarized.
This document provides an overview of different software development processes including the waterfall model, iterative model, Rational Unified Process (RUP), and Agile Development Process (ADP). It describes the key aspects of each process including phases, roles, artifacts, and ceremonies. Specifically, it provides detailed explanations of Scrum, an agile methodology, including Scrum roles like Product Owner and Scrum Master, ceremonies like the Daily Scrum, and artifacts like the Product Backlog and Sprint Backlog. The document concludes with references for further information.
- Scrum is an agile framework for managing complex projects using short development cycles ("sprints"), regular inspection of progress, and adaptation to change. It emphasizes communication, collaboration, and incremental delivery of work.
- Key Scrum roles include the Product Owner who prioritizes features, the Development Team who implements them, and the Scrum Master who facilitates the process.
- Core Scrum activities are Sprint Planning meetings, Daily Scrums, Sprint Reviews, and Sprint Retrospectives, which focus the team and enable inspection and adaptation.
- The Product Backlog contains prioritized features and the Sprint Backlog contains work for the current Sprint. A Burn Down Chart tracks progress. Scrum
- Scrum is an agile framework for managing product development, with roles of Product Owner, Scrum Master, and Development Team.
- Key rituals include Sprint Planning, Daily Stand-ups, Sprint Review and Retrospective.
- The Product Owner prioritizes features in the Product Backlog to maximize business value, while the Development Team works in sprints to deliver increments of functionality. The Scrum Master facilitates the process and removes impediments.
Agile Methodology in Software DevelopmentRaghav Seth
The document discusses various agile methodologies and frameworks, with a focus on Scrum. It defines Scrum as an agile process that allows teams to focus on delivering the highest business value in the shortest time through rapid inspection of working software every 2-4 weeks. Key Scrum roles include the Product Owner who prioritizes features, the Scrum Master who facilitates the process, and self-organizing Development Teams. Sprints involve planning, daily stand-ups, demos, and retrospectives to continuously improve.
Agile development focuses on effective communication, customer collaboration, and incremental delivery of working software. The key principles of agile development according to the Agile Alliance include satisfying customers, welcoming changing requirements, frequent delivery, collaboration between business and development teams, and self-organizing teams. Extreme Programming (XP) is an agile process model that emphasizes planning with user stories, simple design, pair programming, unit testing, and frequent integration and testing.
The document summarizes agile software development methods. It describes agile as an iterative approach that promotes adaptive planning, evolutionary development, rapid response to change, and close collaboration between self-organizing teams. The key characteristics of agile include iterative development with incremental releases, a people-oriented focus, lightweight processes, and test-driven development. The document also outlines the agile manifesto and lists benefits and situations where agile may not be suitable.
This document provides an overview of Agile and Scrum methodologies. It describes the iterative incremental model and compares it to the waterfall model. The key aspects of Agile include iterative development, early delivery of working software, collaboration between business and developers, self-organizing teams, and face-to-face communication. Scrum is then introduced as a framework for implementing Agile. The core Scrum roles, events, artifacts, user stories, estimation techniques, and burn down charts are defined and explained at a high level.
AGILE PORTUGAL 2016: Adopted agile in a CMMI L5 enterprise: what were the fin...Délio Almeida
This document outlines the results and experiences of a company adopting Agile practices within an existing CMMI Level 5 enterprise. It describes the 5 phases of the process improvement, including defining Agile methodology, conducting pilots, deploying improvements, monitoring deployment, and evaluating effects. Key results included certifying 40 Scrum Masters, achieving sprint goals 86% of the time on average, and preliminary indications of a 7% improvement in net margins. Challenges included maintaining an Agile culture and slower than expected introduction of new tools. Overall, the company was able to successfully blend Agile and CMMI practices and saw benefits from the adoption of Agile.
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
Module 1. Born to fail
- Why projects are failing
- Waterfall & traditional software development
Module 2. Agile
Module 3. Scrum
Module 4. Writing high quality software with Agile
- XP
- How Google Write Software
Module 5. Do's and dont's
- How Scrum might fail
- Myths and realities
Module 6. How to kick off Scrum
The document provides an overview of Scrum, an agile software development framework. It defines Scrum, discusses its history and introduction. It describes the Scrum framework, including roles like Product Owner and Scrum Master, events like sprint planning and review, and artifacts like product and sprint backlogs. It outlines the Scrum process and provides examples of Scrum applications. It discusses advantages like adaptability and faster delivery, and disadvantages like lack of documentation. It concludes that Scrum is popular for experienced teams that can self-organize, but requires strict adherence to be effective.
Pam, a project manager, initially dislikes the CMMI processes her company introduces but eventually wants to understand them better. However, her first experiences with process development, deployment, and appraisals are frustrating and negatively impact her project. The document outlines common reasons why project managers dislike the CMMI, such as unrealistic process requirements and evidence collection taking too much time. It advocates applying CMMI principles like ensuring processes are useful and appraisals don't hinder projects. Pam eventually realizes her struggles were just a dream and is able to apply CMMI in a practical way that improves her work.
Presentation provides agile tools and practices that workplace learning professionals can use with projects. Deck built for Learning Solutions 2014 with presenter notes
Detail Information about Agile Process Frameworks such as SCRUM and CMMI along with agile manifesto. Comparison between scrum and capability maturity model integration
I normally teach Introduction to Agile and Scrum over a 2 day session to teams. Here is a highly condensed 2-hour version of it that covers agile thinking and introduces scrum as a framework without getting into details.
I use it as a course material for teaching to teams or groups looking to get a perspective on "why" as opposed to "how" aspect of agile.
The document provides an overview of Scrum, an agile framework. It discusses the Scrum roles of Product Owner, Scrum Master, and Team. It describes Scrum artifacts like the Product Backlog, Sprint Backlog and how daily stand-ups, Sprint Planning, Reviews and Retrospectives work. Benefits are provided for customers, leadership and team members from adopting Scrum.
This document outlines a model for a sustainable agile transformation within an organization. It begins with an overview of agile basics and scaling agile approaches. It then discusses why agile transformations are difficult, focusing on achieving safety from different stakeholder perspectives. The model proposes defining an operational framework structured around teams, products, and services. It recommends introducing change incrementally, starting with independent pilot teams, and measuring improvement through coaching and assessment. The transformation aims to tie back to business drivers like predictability, quality, and early return on investment.
Building a Giant Atlassian Universe to Take Over the WorldAtlassian
Fidelity Information Services uses Atlassian tools to manage its software lifecycle from end to end, for massive, multi-million LOC financial applications including core banking and channels products. In this session Glen and Chris will share the high-level process flow for development at Fidelity. Attendees will leave with the tools to implement change in their own environments while maintaining control and assuring quality in a regulated environment.
The document discusses process improvement metrics and methods at the Jet Propulsion Laboratory (JPL). It notes that while JPL aims to perform like a CMMI Level 4 organization, it is actually assessed at CMMI Level 3. It outlines some of JPL's data collection methods and key questions around understanding their software environment. Some of the processes in place include tailoring software development processes and measuring performance against processes. Risks, strengths and recommendations are identified from process reviews.
This whitepaper discusses Hexaware's Probe upgrade tool which helps companies plan and prepare for upgrading their SAP systems. The Probe tool assesses a company's current SAP environment to analyze custom objects and estimate the effort required to upgrade without requiring the target upgrade system. It provides estimates of objects impacted, time and costs to help companies budget and plan resource needs. The tool identifies potential issues with custom objects and provides failure analysis to minimize risks during the upgrade process.
HouSecCon 2019: Offensive Security - Starting from ScratchSpencer Koch
HouSecCon 2019 Offensive Security - Starting from Scratch. Learn from Spencer Koch and Altaz Valani about how to build an offensive security program from scratch, incorporating application security, infrastructure vulnerability management, hardening, devsecops, security champions, and red teaming. Be able to organize these capabilities to tell a story and build maturity to help your organization be more secure. Includes gotchas and lessons learned from industry experience.
Avoid software project horror stories - check the reality value of the estima...Harold van Heeringen
Many large software projects turn into software horror stories, resulting in newspaper headlines and even political issues. Often, the project costs and schedule were estimated unrealistically optimistic, using immature estimation techniques. A relatively simple way to avoid many problems is to perform a reality check on the estimate. This presentation was given on the conference of the International Cost Estimating and Analysis Association (ICEAA2014), June 2014 (Denver, USA)
The document discusses software process models and methodologies, specifically the Personal Software Process (PSP) and Team Software Process (TSP) developed by the Software Engineering Institute (SEI). It provides an overview of how PSP teaches individuals to establish measurable and repeatable development processes to improve performance. Engineers learn the PSP over 7 levels, gathering and analyzing data from small programming assignments to establish performance baselines and drive process improvements. The PSP aims to develop individual discipline and skills needed for successful team development using TSP.
This document provides a summary of Ott Calfee's qualifications, including over 5 years of experience in quality assurance and automation testing using tools like Selenium and JUnit. They have expertise in software development lifecycles like Waterfall and Agile, as well as testing methodologies. Recent experience includes quality assurance roles for projects at Safeway involving a point-of-sale system and in-store ordering. Previous roles involved testing training software, middleware systems at AT&T, and content verification.
The document describes the software requirements process, which includes identifying sources of requirements, understanding customer needs, defining and writing software requirements, analyzing and validating requirements, and conducting formal reviews. The key objectives are to translate software requirements into a clear specification document that establishes the system scope and is consistent, complete, realistic and unambiguous. The process involves planning, requirement gathering, documentation, and traceability activities.
CAT Technology Inc. is an IT consulting and staffing firm that aims to be a global provider of technology and human resource solutions, offering software development, training, and outsourced IT services. The company has a track record of delivering innovative solutions and provides qualified IT professionals on a permanent or contractual basis to meet clients' staffing needs. CAT screens candidates thoroughly and offers training programs to suit both professionals and freshers in various technologies and software programs.
This document outlines the approach and content of a course on technology transfer services and strategy engineering. The course is designed to teach students how to strategically solve real-world problems through a multi-stage process. It begins by having students identify and analyze problems, then develop requirements and design solutions to drive key performance indicators toward desired outcomes. Various tools are used at each stage, and students work in teams on multiple problems while receiving continuous feedback to foster learning over evaluation. The goal is for students to gain experience applying a rigorous process to strategically address issues.
Moving 65,000 Microsofties to DevOps with Visual Studio Team ServicesVSTS Community MSFT
How do you migrate over 65,000 of the most demanding software engineers from infrastructure built up over decades of high-intensity work into a common engineering system based on modern software development technologies and best practices?
This document discusses key measurements for testers, including precision vs accuracy. It provides examples to illustrate the difference between precision and accuracy. The document also discusses goals for testing, including using the SMART framework. It introduces the GQM methodology for defining test goals and questions. Additional sections cover test planning and resources, defect tracking, defect prediction, and release criteria.
The document provides tips on how recruiters can better manage hiring managers during the candidate matching and selection process. It suggests recruiters identify the hiring manager's needs, search for suitable candidates using the right keywords, and pitch candidate profiles that align with the roles while also highlighting potential alternative fits. The document also discusses common challenges faced by both candidates and hiring managers to provide context around expectations.
The document presents a tool called PSP PAIR that automatically analyzes performance data from the Personal Software Process (PSP) to identify problems and recommend improvements. PSP generates large amounts of data but analyzing it manually is time-consuming. PSP PAIR addresses this by developing a performance model and using it to analyze time estimation accuracy and other metrics from PSP data. It identifies potential problems and suggests actions like stabilizing productivity. An evaluation found PSP PAIR could help engineers using PSP by speeding up analysis and proposing targeted improvements. Future work includes validating the model with more data and expanding PSP PAIR to support the Team Software Process.
The document outlines OpenERP's approach to project support for partners, describing the various phases of a project from initial gap analysis and estimation through development, testing, deployment, and post-deployment support, with OpenERP assisting partners at each stage to help ensure project success. It emphasizes that both OpenERP and its partners have a shared responsibility in delivering projects to clients to strengthen the OpenERP brand.
In the world of agile, there is theory and then there is practice. We like to talk about self-organizing teams, asynchronous execution, BDD, TDD, and emergent architecture. We also talk about cross-functional teams: how analysts, testers, architects, technical writers, and UX designers belong on the same team, right next to programmers. It all sounds nice in theory, but how does this work in reality? What do these people actually do? How do they interact? What does it look like? Is there really a pragmatic way to make this work?
In this simulation, a cross-functional team will actually build a piece of software. Every specialist will have a hand in the process. Every specialist will also act as a generalist. Everyone will add value. And as a team, we’ll get something DONE.
This is your opportunity to see agile development in practice, and to bridge the gap between what agilists say and what teams do. And it’s not as new or as difficult as you think – affinity between testers, BA’s, coders, and other team members has really been at the root of effective development practices all along. Let’s just finally acknowledge that it works, demonstrate its capabilities, and encourage it going forward.
This IS agile development.
In just over a year, siroop's engineering teams went from ever more painful releases to 100s of fast and safe production deployments per day. This presentation provides some insights into how this journey unfolded and highlights some of the systemic, cultural and technological changes that were part of it.
This document discusses key measurements for testers, including precision vs accuracy, goals for testing (SMART goals), the GQM methodology for defining test goals and questions, and various metrics for evaluating projects, products, and releases such as defect rates and trends. It provides examples of defining test plans and resources needed, tracking reported vs resolved defects, and criteria for determining when a release is ready.
The document provides an overview of the HandSimDroid project. It includes an agenda for a meeting covering the project overview, process, requirements, risk management, system architecture, next steps, and accomplishments. The team used the Team Software Process and developed requirements, risk management plans, architectural diagrams, and plans to move forward with additional training, prototyping, and formalizing the project scope. They discussed accomplishments from the first part of the project and took questions.
Strategies for Effective Upskilling is a presentation by Chinwendu Peace in a Your Skill Boost Masterclass organisation by the Excellence Foundation for South Sudan on 08th and 09th June 2024 from 1 PM to 3 PM on each day.
The simplified electron and muon model, Oscillating Spacetime: The Foundation...RitikBhardwaj56
Discover the Simplified Electron and Muon Model: A New Wave-Based Approach to Understanding Particles delves into a groundbreaking theory that presents electrons and muons as rotating soliton waves within oscillating spacetime. Geared towards students, researchers, and science buffs, this book breaks down complex ideas into simple explanations. It covers topics such as electron waves, temporal dynamics, and the implications of this model on particle physics. With clear illustrations and easy-to-follow explanations, readers will gain a new outlook on the universe's fundamental nature.
How to Build a Module in Odoo 17 Using the Scaffold MethodCeline George
Odoo provides an option for creating a module by using a single line command. By using this command the user can make a whole structure of a module. It is very easy for a beginner to make a module. There is no need to make each file manually. This slide will show how to create a module using the scaffold method.
How to Make a Field Mandatory in Odoo 17Celine George
In Odoo, making a field required can be done through both Python code and XML views. When you set the required attribute to True in Python code, it makes the field required across all views where it's used. Conversely, when you set the required attribute in XML views, it makes the field required only in the context of that particular view.
বাংলাদেশের অর্থনৈতিক সমীক্ষা ২০২৪ [Bangladesh Economic Review 2024 Bangla.pdf] কম্পিউটার , ট্যাব ও স্মার্ট ফোন ভার্সন সহ সম্পূর্ণ বাংলা ই-বুক বা pdf বই " সুচিপত্র ...বুকমার্ক মেনু 🔖 ও হাইপার লিংক মেনু 📝👆 যুক্ত ..
আমাদের সবার জন্য খুব খুব গুরুত্বপূর্ণ একটি বই ..বিসিএস, ব্যাংক, ইউনিভার্সিটি ভর্তি ও যে কোন প্রতিযোগিতা মূলক পরীক্ষার জন্য এর খুব ইম্পরট্যান্ট একটি বিষয় ...তাছাড়া বাংলাদেশের সাম্প্রতিক যে কোন ডাটা বা তথ্য এই বইতে পাবেন ...
তাই একজন নাগরিক হিসাবে এই তথ্য গুলো আপনার জানা প্রয়োজন ...।
বিসিএস ও ব্যাংক এর লিখিত পরীক্ষা ...+এছাড়া মাধ্যমিক ও উচ্চমাধ্যমিকের স্টুডেন্টদের জন্য অনেক কাজে আসবে ...
हिंदी वर्णमाला पीपीटी, hindi alphabet PPT presentation, hindi varnamala PPT, Hindi Varnamala pdf, हिंदी स्वर, हिंदी व्यंजन, sikhiye hindi varnmala, dr. mulla adam ali, hindi language and literature, hindi alphabet with drawing, hindi alphabet pdf, hindi varnamala for childrens, hindi language, hindi varnamala practice for kids, https://www.drmullaadamali.com
ISO/IEC 27001, ISO/IEC 42001, and GDPR: Best Practices for Implementation and...PECB
Denis is a dynamic and results-driven Chief Information Officer (CIO) with a distinguished career spanning information systems analysis and technical project management. With a proven track record of spearheading the design and delivery of cutting-edge Information Management solutions, he has consistently elevated business operations, streamlined reporting functions, and maximized process efficiency.
Certified as an ISO/IEC 27001: Information Security Management Systems (ISMS) Lead Implementer, Data Protection Officer, and Cyber Risks Analyst, Denis brings a heightened focus on data security, privacy, and cyber resilience to every endeavor.
His expertise extends across a diverse spectrum of reporting, database, and web development applications, underpinned by an exceptional grasp of data storage and virtualization technologies. His proficiency in application testing, database administration, and data cleansing ensures seamless execution of complex projects.
What sets Denis apart is his comprehensive understanding of Business and Systems Analysis technologies, honed through involvement in all phases of the Software Development Lifecycle (SDLC). From meticulous requirements gathering to precise analysis, innovative design, rigorous development, thorough testing, and successful implementation, he has consistently delivered exceptional results.
Throughout his career, he has taken on multifaceted roles, from leading technical project management teams to owning solutions that drive operational excellence. His conscientious and proactive approach is unwavering, whether he is working independently or collaboratively within a team. His ability to connect with colleagues on a personal level underscores his commitment to fostering a harmonious and productive workplace environment.
Date: May 29, 2024
Tags: Information Security, ISO/IEC 27001, ISO/IEC 42001, Artificial Intelligence, GDPR
-------------------------------------------------------------------------------
Find out more about ISO training and certification services
Training: ISO/IEC 27001 Information Security Management System - EN | PECB
ISO/IEC 42001 Artificial Intelligence Management System - EN | PECB
General Data Protection Regulation (GDPR) - Training Courses - EN | PECB
Webinars: https://pecb.com/webinars
Article: https://pecb.com/article
-------------------------------------------------------------------------------
For more information about PECB:
Website: https://pecb.com/
LinkedIn: https://www.linkedin.com/company/pecb/
Facebook: https://www.facebook.com/PECBInternational/
Slideshare: http://www.slideshare.net/PECBCERTIFICATION
6. 什么是 PSP/TSP
PSP – Personal Software Process
TSP – Team Software Process
养成良好的职业习惯,使
养成良好的职业习惯
PSP是一套旨在帮助软件工程师养成良好的职业习惯
之成为企业需要的职业工程师的方法和工具集
TSP为一组具备PSP能力的工程师进行协同工作,提供指
导和帮助
7. PSP/TSP 和 CMMI
CMMI - Builds
organizational
capability
TSP - Builds
quality products
on cost and
schedule
PSP - Builds
individual skill
and discipline
18. SEI提供的PSP/TSP收益数据
Average Effort Deviation - Range Average Schedule Deviation - Range
120% 160%
100% 140%
120%
80%
100%
60% 80%
40% 60%
40%
20%
20%
0% 0%
-20% -20%
Pre TSP/PSP With TSP/PSP Pre TSP/PSP With TSP/PSP
Defects/KLOC in Acceptance Test - Range Post-Release Defects/KLOC - Range
0.9 1.4
0.8 1.2
0.7
1
0.6
0.5 0.8
0.4 0.6
0.3
0.4
0.2
0.1 0.2
0 0
Pre TSP/PSP With TSP/PSP Pre TSP/PSP With TSP/PSP
24. PSP/TSP工具
• PSP Estimation Tool (Customized Access Tool)
• Authorized by CMU/SEI if applying for the PSP training
• Being used during PSP Training
• Get the first personal performance baseline from the 1st 7
programs after the training
• PSP/TSP Project Management Tool (Customized Excel Tool)
• Authorized by CMU/SEI if applying for a SEI Certified TSP
Coach
• Being used during project lifecycle
• Process Dashboard (Web Based Tool)
• License free
30. 计划的基本步骤
Basic steps of planning are 计划的基本步骤是:
1. Understand the requirements 理解需求
2. Conceptual Design 概念设计
3. Estimate size and effort of job 估算规模和工作量
4. Make a task list 制定任务列表
5. Make a schedule 制定进度计划
6. Review and Commitment 评审并达成共识
31. 估算的问题
Detailed size measures such as lines of code (LOC), screen controls, or data base
objects are needed to make good effort estimates
需要有详细的规模度量标准(比如代码行、页数或数据库对象)来做工作量估算。
At the initial planning stage, directly estimating LOC, screen controls, or data base
objects is usually difficult
在计划的初始阶段,直接估算代码行、页数或者数据库对象是非常困难的。
These are not the items you visualize directly from the requirements or
specification
这些元素并不能直接从需求或者规格说明书中获得。
How can this be handled?
那怎么处理呢?
Requirements Lines of
Code?
32. 估算案例:建房子 1
Suppose you want to build a new house
假定你希望建一座房子
You go to a builder to get a cost estimate
你向一个建筑商询价
The builder tells you that the cost is directly related to the size, in
square feet, of the house
建筑商告诉你:价格与房子的规模
规模,即面积
规模 面积直接相关
面积
How can you come up with the needed size estimate?
你如何获得所需的规模估算呢?
33. 估算案例:建房子 2
The builder has detailed size data on actual room sizes for many houses
建筑商拥有许多房间实际面积的详细数据
The data are organized by room type such as bedroom, bath, and kitchen
with the typical small, medium, and large size
这些数据按照房间类型(卧室、浴室、厨房等)以及规模(小、中、大)来组织
34. 估算案例:建房子 3
You visualize a conceptual design of your desired house by listing the
rooms you want and their relative sizes; small, medium, or large
通过列出你想要的房间类型和它们的相关面积,将概念设计形象化:
– To estimate the house size
估算房屋面积
– To estimate the square footage of each room, look up the room type and relative size in
the builder’s size table
为了估算每个房间的平方米,从建筑商的规模表中查找房间类型和相关面积
– Total the estimated room sizes by adding the individual estimates together.
把各个房间估算累加得到总的估算规模
To estimate the cost, multiply the final size estimate by his cost per square
foot
为了估算成本,将每平方米的成本乘以最终的估算面积
35. 类推到软件
– From the requirements, visualize the “parts” needed to build the program (such as the
rooms of the house), the “types” of these parts, and their relative sizes
来自需求,对构造程序所需的“部件
部件”(譬如建造房屋的房间)进行形象化:这些“部件”的
部件
类型以及相关规模。
– Use historical data on the software parts already developed, organized into a relative size
table by part “types,” to estimate “part” size.
历史数据,按组件类型组织一份相关规模表来估算组件
使用曾经开发的软件组件的历史数据
历史数据
模
– Estimate the program size by summing the “part” estimates and adjusting the sum by the
relationship of past estimates to actual sizes
通过累加组件估算得到总的程序规模,以及根据历史估算值与实际规模的关系对累计
校准。
值加以校准
校准
– Estimate effort by multiplying the size estimate by historic productivity.
通过将估算的规模乘以历史生产率 历史生产率(size/hour),得到估算的时间。
历史生产率
37. Conceptual Design
A conceptual design 概念设计
– relates the requirements to the product
将需求与产品关联起来
– defines the product parts that will needed to build the product
定义用以构建产品的组件
– is used as the basis for estimating the size of the product you plan to build
用作规模估算的基础
Conceptual design are not the same as detailed designs
概念设计与详细设计不同
For most projects, the conceptual design can be produced relatively
quickly
对大多数项目而言,概念设计可以相对快速地生成。
If you do not understand the product well enough to make a conceptual
design, you do not know enough to make a plan.
如果你对产品的了解不足以做概念设计,那么也不足于做计划。
如果你对产品的了解不足以做概念设计,那么也不足于做计划。
38. Identify and Size the Proxies
Based on the conceptual design, categorize those parts by comparing each to types
of parts historically produced
基于概念设计,通过把每个组件与历史组件类型比较来对它进行分类。
Next, estimate the relative size of each part by comparing to the size of parts
historically produced
接下来,通过与历史组件的规模比较来估算每个组件的相关规模。
Finally, combine the part estimates to estimate total size of new parts
最后,综合各组件估算值从而估算出新组件的总规模。
39. Estimate Other Element Sizes
If you will be modifying or including existing code, you will need to
estimate those other parts
如果你要修改或者包含已存在的代码,则你将必须估算这些组件。
Base parts are existing parts that will be changed by adding, deleting,
or modifying
“Base parts”,是已经存在并即将被改变的组件(增加、删除或修改)。
Reused parts (R) are parts that will be used unmodified
“Reused parts (R)”,是不会被改变的组件。
40. Calculate Projected Total Program
Size and Effort
To calculate total program size, you add up the individual pieces
为了计算程序的总规模,你需要将各个部分相加。
The total size may be adjusted based on your historical data to
calculate a projected total program size
总规模可以基于你的历史数据进行调整,以计算出计划的程序总规模。
The estimation of development effort is based on the projected
program size
开发工作量的估算基于开发程序的规模。
The projected program development effort can also be adjusted based
on your historical data
程序开发工作量也可以基于历史数据进行调整。
41. 选择合适的规模度量
In class, we encourage you to use LOC as the size measure; you will
likely need additional size measures in practice, however.
在课堂上,我们鼓励使用代码行来度量规模;在实际工作中,你可能
需要其它的规模度量。
Criteria for selecting size measures
选择规模度量方法的标准:
– relates to effort
与工作量相关
– Precise
精确
– machine countable
能够自动计算
42. 规模度量的精确性
A size measure is precise if
精确的规模度量是指:
– Every time you measure the same item you get the same
result
每次度量的结果相同
– Every person who measures the same item gets the same
result
不同人的度量结果相同
Is LOC a precise measure?
代码行是一种精确的度量吗?
43. 代码行统计标准
LOC is not a precise measure unless LOC has been defined precisely
代码行只有被精确地定义才是一种精确的度量
Defining LOC precisely in the work environment can be a significant task
在工作中精确定义代码行是非常重要的任务
In this class, we use the following simple rules for defining a line of code
在我们的课程中,使用下面简单规则来定义代码行
– Count each physical line as one LOC
每个物理行做一个代码行
– Do not count blank lines
不计算空白行
– Do not count line that are only comments
不计算只包含注释的行
– Do not count machine generated lines
不计算自动生成的代码
44. 代码行的类型
The types of LOC include
代码行包括:
– base [B] – LOC that you start with and make changes to
base [B]:你开始时的基础代码,并要对它进行改变。
• deleted [D] – LOC removed from the base “deleted [D]” :从基代码中删除的
• modified [M] – LOC in the base that is modified “modified[]”: 基代码中修改的
– added [A] – LOC that is new
added [A]:新的代码行
– reused [R] – LOC from a library that is used without changes
reused [R]:从程序库中拿来直接使用且没有任何改变的代码行
– added and modified [A&M] – sum of added and modified LOC
added and modified [A&M]:增加和修改代码的总和
:
– new reusable – new LOC that is put into a reuse library
new reusable:用以放进重用库的新代码行
– total [T] - the LOC in the entire program
total [T]:整个程序的代码行
46. PROBE估算原则
Estimating is a continuously precise process
估算是一个逐渐精确
逐渐精确的过程
逐渐精确
– No one knows how big the product will be at beginning
没有人在一开始知道产品规模会有多大;
– The earlier the estimate, the less is known
越早做估算,知道得就越少;
– Estimates can be biased by business and other pressures
估算可能因业务需要或其它压力而有所偏差。
Estimating is an intuitive learning process
估算是一个逐渐学习
逐渐学习过程
逐渐学习
– Ability improves with experience and data
能力会随经验和数据而提高
– Some people will be better at estimating than others
部分人估算得比其它人要好
The objective is to become consistent
目标变得一致
– You will then understand the variability of your estimates
然后你就能理解你的估算的变化性
– You seek an even balance between under- and overestimates
你要平衡乐观与悲观估算
平衡乐观与悲观估算
51. 项目跟踪的问题
• Project tracking would be simple if
如果下面说法存在,则项目跟踪会变得容易:
– we always completed tasks in the planned order
我们总是按照计划的次序完成任务
– no tasks were added or deleted
没有任务增加或删除
• But this never happens 但这绝不可能发生
– Requirements always change 需求总是在变更
– Tasks get cancelled or deferred 任务总被取消或者延迟
– Some tasks are dropped, and others are added 我们经常取消一些任
务或增加一些新任务
– Estimating errors are common 任务的估算也总有些误差
52. EV挣值跟踪
• To track project status in a dynamic environment, you need a way to assign a
value that measures the contribution of each task towards the whole project.
为了在动态环境中跟踪项目状态,我们需要一个值,用于度量每个任务
对项目的贡献。
• Then you can
有了这个值,我们就可以
– add up the value of the completed tasks
知道全部已完成任务的总值
– compare this value to the value of the total job
将已完成任务的总值和项目所有任务的总值相比较
– calculate the percentage of job completion
计算工作完成的比例
• The PSP/TSP does this with a method called earned value (EV)
PSP/TSP通过挣值 挣值做到这一点
挣值
53. 挣值 Earned Value
• The planned value (PV) for a task is the percentage of the total project hours
that is planned for that task
一个任务的 计划挣值 计划挣值PV是这个任务的计划时间与总的项目计划时间的百
分比
• When a task is completed, it is assigned an earned value (EV) that is equal to
the planned value for that task (regardless of how many hours it actually took)
当一个任务完成时,它被赋以一个挣值(EV),这个值等于其计划值,而不
管实际花多长时间完成
• Partially completed tasks receive no earned value.
没有完全完成的任务是没有挣值的
56. 挣值计算
• To estimate the project completion date with EV 为
了利用挣值预计项目结束日期,必须:
1. Determine the EV needed to finish 确定需要完成的挣值
2. Determine the rate at which the individual is earning EV
确定获得挣值的速率
3. Determine how long it will take the individual to earn the
remaining EV 确定需要多久来获得剩余的挣值
57. 预计项目结束日期 - 1
• After three weeks, the work has taken longer than expected, and the developer is not
getting 15 task hours per week
3周之后,实际工作需要花费的时间比期望的要长,并且开发者没有做到每周工作
15小时
• As tasks are completed, their EV is entered for the week earned. Partially completed
work earns no value
随着任务的完成,所对应的周获得了它们的挣值。部分完成的工作没有挣值。
58. 预计项目结束日期 - 2
• The team member has earned 42.8
EV in 3 weeks, or 14.3 EV per week
小组成员在3周内获得42.8的挣值,
或者说每周14.3.
• There are 100 - 42.8 = 57.2 EV to
go. At 14.3 EV per week, that is 4.0
more weeks to go.
还需要得到100 - 42.8 = 57.2 EV . 按
照14.3/周的速度,还需要4周.
• Added to the 3 weeks spent so far,
that is 7.0 weeks.
加上已经花费的3周,总共是7周
• At the current rate of progress, the
team member will be 2.0 weeks late.
按照目前进展速度,小组成员有2
周的延迟
60. 问题 1
• Is this team ahead of or behind schedule, and by
how much?
小组领先或者落后进度吗?程度如何?
61. 问题 2
• Why is the team behind schedule?
• 落后进度的原因是什么?
62. 问题 3
• At this rate, can the team members finish on the original
plan of 25 weeks? If not, how late will they be?
以这样的速度,小组能够按计划的25周完成任务吗?如
果不行,会延期多久?
63. 问题 4
• Can this five-person team meet the original schedule? If
not, what help would they need from management to do?
这个5人组成的团队能够实现进度要求吗?如果不能,
他们需要管理层提供什么样的帮助?
65. 软件质量
To be useful, software must 有用的软件必须是:
– install quickly and easily 快速方便地安装
– run consistently 稳定运行
– handle normal and abnormal cases 恰当地处理正常与非正常状况
– not perform in a destructive or unexpected way 不会以破坏性或意想
不到的方式运行
– be essentially bug-free 基本没有缺陷
Defects are not important to users, as long as they do not
– affect operations 影响操作
– cause inconvenience 造成不方便
– cost time or money 消耗时间和金钱
– cause loss of confidence in the results 影响对程序结果的信心
66. 质量问题
With common quality practices, software groups typically
实践表明,软件团队通常:
– spend more than 50% of the schedule in test
时间进度的50%花费在测试上
时间
– devote more than half their resources to fixing defects
一半以上的资源
资源用于发现和解决缺陷
资源
– cannot predict when they will finish
无法预测测试工作什么时候可以结束
无法预测
– deliver poor-quality and over-cost products
发布低质量
低质量和超支的产品
低质量
To get quality, you must put quality into test
为了得到高质量的软件产品,它必须在进入测试之前就已经具备高质量
69. Review类型
A personal review is conducted by the developer who examines his or
her own product with the goal of finding and fixing as many defects as
possible.
“personal review”是开发者为了尽可能多地解决缺陷,检查自己的产
品。
An inspection is a structured team review of a software product
“inspection”是有组织地对软件产品进行小组评审。
A walkthrough is less formal than an inspection. The product is
presented to an audience that raises issues and asks questions.
“walkthrough”没有“inspection”正式,向听众演示,由听众提出问题。
70. Personal Review原则
The PSP review goal is to find every defect before the first test.
PSP review的目标是在第一次编译或测试之前发现每个缺陷。
To address this goal, you should
为了达到这个目标,你应当:
– Take a break between working and reviewing
在review和工作之间有所间隔
– Review before compiling or testing
在编译和测试之前进行review
– Follow a structured review process
遵循一个结构化的review过程
– Use a checklist derived from personal defect data
使用根据个人缺陷数据不断更新的checklist
– Measure your review process
度量你的review过程
– Use data to improve your reviews
使用数据来改进你的review活动.
71. Reviewing Before Inspecting
The principal focus of inspections should be to find problems that you cannot
find in personal review.
Inspection主要关注在找出个人review中无法发现的问题
When programs have many simple defects, inspectors are distracted and often
miss more important problems
当程序有太多简单缺陷,inspectors会被分散注意力以至于经常遗漏更加重要
的问题。
Reviewing the product first
Inspection之前需要review产品,可以:
– provides a quality product for the inspection
为inspection提供高品质的产品
– shows respect for the inspectors’ time
对inspector的时间表示尊重
– produces higher quality inspections
提高inspection的效率
72. 使用检查表 Checklist
Your reviews will be most effective when your personal checklist is
customized to your own defect experience
当你的checklist是根据自己的缺陷经验定制时,你的review是最有效的。
– Use your own data to create the checklist items
用你自己的缺陷数据建立checklist项
– Adjust the checklist with experience.
根据实际使用结果调整checklist.
在Review过程中,你应该
– Read every check in the checklist before review
在开始Review之前,熟读Checklist中的每一项.
– Link the defects with the checks in the checklist
将检查到的缺陷与Checklist中的Check项进行关联
– Check off each item as you complete it
完成review前核对每一个检查项
73. Review vs. Test
In testing, you must
– detect unusual behavior 发现不正常的行为
– determine what the test program was doing 确定测试程序的运行状况
– find where the problem is in the program 找到问题在程序中的位置
– figure out which defect could cause such behavior 找到产生这种行为的缺陷
This can take a lot of time 这需要很多的时间
With reviews and inspections, you
– follow your own logic 跟随你自己的逻辑
– know where you are when you find a defect 发现一个缺陷时,知道其对应的位置
– know what the program should do, but did not 知道程序应当怎样做却没有做到
– know why this is a defect 知道为什么这是一个缺陷
– are in a better position to devise a correct fix 处于较好的设计纠正措施的位置
76. Reviewing Before Compile
When your development environment has a compile step, it is more
efficient to do code reviews before compiling
如果开发中有编译的步骤,则在编译前进行code review更为有效
The reasons for this are as follows 原因如下
– Avoid compiler reliability mentally, improve coding quality
从心理上消除对编译器的依赖性,
从心理上消除对编译器的依赖性,从而提高编码的质量
– Review time is about the same before or after compiling
在编译前或者后进行review的时间长度基本相同
– If reviews are done before compiling, compile time is substantially reduced
如果在review后进行编译,编译和测试的时间显著减少
– Programs with many compile defects often have many test defects
有很多编译缺陷的程序往往也会有很多测试缺陷
77. 质量指示器
The PSP/TSP has many useful quality and process-control
measures:
PSP/TSP有很多有用的质量和过程控制度量标准
– Phase Yield
– Review Rate
– defects found per unit of size
缺陷发现密度(发现的缺陷数/规模单元)
– defects injected and removed per hour
每小时注入/移除缺陷数
– A/F Ratio
Appraisal (Review, Inspection)时间和Failure (Unit, Integration, System
Testing)时间之比
78. 质量管理原则
The quality of a software system is determined by the quality of its
worst components
软件系统的质量是由最差组件决定的。
The quality of a software component is governed by the individual who
developed it
软件组件的质量是由开发人员决定的。
The key to quality is the individual developer’s skill, commitment, and
personal process discipline
质量的关键在于开发人员的技能,承诺和纪律。
95. TSP核心内容
• TSP Launch
• TSP Team
• TSP Coach
• TSP Data
96. TSP Launch
Day 1 Day 2 Day 3 Day 4
1. Establish 4. Build top-
7. Conduct 9. Hold
product and down and
risk management
business next-phase
assessment review
goals plans
8. Prepare
2. Assign roles 5. Develop
management Launch
and define the quality
briefing and postmortem
team goals plan
launch report
3. Produce 6. Build bottom-
development up and
strategy consolidated
and process plans
98. TSP Coach
•Lead the TSP Launch
•Weekly review the TSP project data
•Lead the project postmortem
99. TSP Data
•Automatically consolidated from PSP data
•Automatically generated by TSP tools
•Used to monitor the project
•Weekly reviewed by the TSP team
100. THA
NK Y
谢谢 OU!
!
Software Engineering Methodology Practices
Simple Efficient Measurable Practical
http://semp.wikispaces.com
Semp.salon@gmail.com
Version 1.00, page 100