1. Trang chủ
  2. » Công Nghệ Thông Tin

Lecture Software process improvement: Lesson 43B - Dr. Ghulam Ahmad Farrukh

28 5 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 28
Dung lượng 129,73 KB

Nội dung

Lecture Software process improvement: Lesson 43B provide students with knowledge about: strategic application of software metrics; private data; project’s private data; functional management; project management; dissecting software defects;... Please refer to the detailed content of the lecture!

Strategic Application of Software  Metrics Lecture # 43­B Strategic Application of Software  Metrics Strategic Application of Software  Metrics • Sensitive usage of metrics data • Process improvement through defect  analysis • Validation of best practices Use the concept of public and  private data to drive your  decisions on how to collect and  analyze data Private Data • Understanding of who owns what data and  when it is appropriate to share the data with  others – People prefer to keep defect data private – How do we analyze defects to improve  processes rather than blame people? – Private data becomes public at well­defined  handoffs or transitions – Accountability Inspections • Inspections are such transitions • If inspections are properly run, these defects  are less embarrassing than defects that are  found later • Data is no longer private • Focus of accountability shifts from  individual to team Project’s Private Data • Time data • Principle of “Information Hiding” is applied • “Information Hiding” during project review Public Data • Metrics for public data – – – – Calendar times Defect rates Project costs Measure of functionality Private and Public Data 10 Functional Management ­ 2 • Don’t emphasize one metric to the  exclusion of others • Support your people when their reports are  backed by data useful to the organization 14 Project Management • Don’t try to measure individuals • Gain agreement with your team on the  metrics that you will track, and define them  in a project plan • Provide regular feedback to the team about  the data they help collect • Know the strategic focus of your  organization and emphasize metrics that  15 support the strategy in your reports Project Team • Do your best to report accurate, timely data • Help your managers to focus project data on  improving your processes • Don’t use metrics data to brag about how  good you are or you will encourage others  to use other data to show the opposite 16 Use software failure analysis to  help drive process improvement  decisions and to measure the  impact of those decisions 17 Dissecting Software Defects • Customer’s view of defects • Development engineer’s view of defects • Support engineer’s view of defects 18 Defect Cube 19 Defect Cube Customer View e.g Design defect, Wrong data Definition, Coding defect, Missing logic n io ms t rip pto n c s m  o r De  Sy fort ome   ­  Ef ust   ­    c     Analysis/Action/   Disposition   ­ Actual cause   ­ Source   ­ Type   ­ Resolution Development Engineer View e.g Critical Serious Medium Low tus a t S             use a c   d ecte ility p s ­Su eatab d p ­ Re karoun r ­Wo Support Engineer View e.g Hardware subsystem, Operating sys. Component, Application component, Documentation 20 Key Questions to Learn from  Mistakes • What development or maintenance process  failed? • How often do such failures occur? • How expensive is it to fix such failures? • Which components are most subject to  failures? • What process change will detect or  eliminate these failures? 21 Evaluate all software process  changes in terms of measurable  ROI 22 Cost/Benefit Analyses • Analysis of savings from use of design  inspections • Analysis of savings from use of structure  methodologies (analysis and design) • Analysis of savings from use of complexity  analysis • Analysis of savings from use of  certification process for a single project 23 Help your boss’s boss to better  understand software process  issues through tracking a  balanced set of metrics 24 Hierarchy of Metrics Acceptance 25 Hierarchy of Metrics Acceptance Data collection automated; analysis with expert system support Experiments validating best Practices with data Common terminology; data comparisons Project trend data available Acceptance of need for measurement 26 Summary 27 Reference • Practical Software Metrics for Project  Management and Process Improvement by  Robert Grady (Part II) 28 ...Strategic Application of? ?Software? ? Metrics Strategic Application of? ?Software? ? Metrics • Sensitive usage of metrics data • Process? ?improvement through defect  analysis •... improving your processes • Don’t use metrics data to brag about how  good you are or you will encourage others  to use other data to show the opposite 16 Use? ?software? ?failure analysis to  help drive? ?process? ?improvement ... analysis • Analysis of savings from use of  certification? ?process? ?for a single project 23 Help your boss’s boss to better  understand? ?software? ?process? ? issues through tracking a  balanced set of metrics

Ngày đăng: 09/12/2022, 03:39