Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

#BAWI2022_07_GUFPI-ISMA.pdf

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Cargando en…3
×

Eche un vistazo a continuación

1 de 20 Anuncio
Anuncio

Más Contenido Relacionado

Más de IIBA-IT (20)

Más reciente (20)

Anuncio

#BAWI2022_07_GUFPI-ISMA.pdf

  1. 1. BAWI 2022 - Back to the Babok Business Analysis & Measurement: a valuable marriage Speaker Luigi Buglione GUFPI-ISMA President CFPS, CSS, CCFL, CSMS
  2. 2. Agenda • GUFPI-ISMA • …who we are • IIBA-Italy & GUFPI-ISMA: part of a network • The «1-2-3 schema» • A «service» is not a «product»! • BAs and Measurers • A «Knowledge» Value Chain • Which linking point(s)? • BABOK Chapter 4 and Chapter 5 say that… • How to classify requirements? • BABOK vs ISO: a mapping • Roles vs Skills • UNI 11621-2 and 11621-6:2021 • Conclusions & Next Steps
  3. 3. A short bio-sketch… Luigi Buglione • Measurement & Process Improvement Specialist • Ph.D., CFPS, CSP, ITIL4 MP, DOL, SaFE SA,… • Email: Luigi.buglione@gufpi-isma.org • Linkedin: https://www.linkedin.com/in/luigibuglione/ • Current Associations (Sw Measurement) • IFPUG Board member (2013-) • ISBSG Vice-President (2021-) • GUFPI-ISMA President (2013-)
  4. 4. GUFPI-ISMA…who we are? • Since 1990 we are the Italian Association that promotes the dissemination and development of software measurement techniques • In 2001 became GUFPI-ISMA, extending its scope to include also non-functional measurement aspects (and more generally, even non-software ones) • In 2013 we began a series of collaborations with various Italian and non-Italian associations, including IIBA- Italy • GUFPI-ISMA organizes events (EventoMetrico; WebinarMetrico; EventoDifferente) and deliverables (IT/EN) about measurement and its applicability in ICT contracts • URL: www.gufpi-isma.org; https://gufpiisma.wildapricot.org/
  5. 5. IIBA-Italy & GUFPI-ISMA…part of a network… • In 2013 we started to join associations close to our institutional goal and strategy and one of these is IIBA-Italy • We • contribute directly each other to other association’s events • promote the events organized by the other association • are open to create new original contents shared by the two organization • In particular, a BA professional creates/elaborates requirements to be sized while an Expert Measurer has the knowledge for sizing them and contributing to their estimates (time/effort) with a PM/PMO
  6. 6. Different Stakeholders… …different viewpoints • …but what about the Measurement Expert?!?
  7. 7. A good intro… You cannot control what you cannot measure but... You cannot measure what you cannot define but... You cannot define what you don’t know...
  8. 8. The «1-2-3 schema» Source: Buglione L., 123+ABC: interpretare meglio DevOps per misurare bene (e meglio) i progetti, PMexpo2017, 27/10/2017, https://goo.gl/KZhycu ISO/IEC 14764:2022 Svc Lifecycle phases (ITIL v3) 1. Dev 2. Ops 3. Svc (Maint)
  9. 9. BAs & Measurers A «knowledge» value chain • Each skill (and related roles) is useful for fruitful and valuable outcome(s) in your project • The logical flow in the picture can describe a typical inputs/outputs among those professional groups/roles • Managing requirements and sizing them is the input for a project manager/PMO for the estimation (first) and the monitoring job (later)
  10. 10. BABOK v3 Chapter 8 – Solution Evaluation • BABOK v3 Chapter 8.1 and 8.2 are about measurement looking to a generic project (not necessarily a software project) without specific techniques • §8.1.4 gives indicators and tips about the ‘elements’ to consider • §8.1.6 provides no mention of specific techniques (such as FPA, SNAP, COSMIC, etc.) • «Metrics and KPIs» seems to be a high-level indication that needs to be contextualized for creating a measurement plan
  11. 11. BABOK Chapter 8 – Solution Evaluation • §8.2.4 provides high-level indicators about the analysis of performance measures (e.g. ‘accuracy’ is a qualitative criteria, but needs to be quantified too…) • §8.2.6 shows a list of techniques (described in detail in §10.x) that could be categorized (qualitative/quantitative) with a scope of application • Also here, «Metrics and KPIs» seems to be a high-level indication that needs to be contextualized for creating a measurement plan (as in ISO/IEC 15939:2017)
  12. 12. How to Classify Requirements? The «ABC Schema» • This is a requirement taxonomy following the ISO standard classifications • Created in 2012, it is part of the IFPUG/COSMIC sizing standards • Useful for better understanding what must be sized according to which measure(s) taking into account the right productivity levels Costtot Efftot UR FP m/d(f-prod) SP m/d(nf-prod) FUR NFR m/d(org-prj) prod prod prj A B C Q → T → C (p) (E→D) Q → T → C (p) (E→D) Q → T → C (p) (E→D) Other XYZ Sources: * Buglione L., The Next Frontier: Measuring and Evaluating the NonFunctional Productivity, IFPUG MetricViews, August 2012, URL: https://tinyurl.com/4y4wwvb3 * Buglione L., 123+ABC: interpretare meglio DevOps per misurare bene (e meglio) i progetti, PMexpo2017, 27/10/2017, https://goo.gl/KZhycu
  13. 13. How to Classify Requirements? ISO/IEC 25010:2011 – Sw Product Quality • This is the ISO taxonomy for ‘qualitative’ requirements about the software product • 8 characteristics, 31 sub-characteristics • Previous version was coded 9126:1991 (2001)
  14. 14. How to Classify Requirements? ISO/IEC 25012:2008 – Data Quality • This other ISO norm is about ‘Data Quality’ • Important to be joined with the 25010 because data are used by software functionalities and are two different (even if connected) items to be analyzed in detail • For instance: testing the «precision» of a data stored (e.g. geographical coordinates for a Point of Interest) is about the quality of such data, even if the related software functionality for visualizing a map would be ok → the potential incident (defect) would be related to a NFR, not a FUR! • In several contracts and bids, there often is this kind of confusion about what is (or not) related to FURs or NFRs…
  15. 15. The «ABC schema» + the «123 Schema» Source: Buglione L., 123+ABC: interpretare meglio DevOps per misurare bene (e meglio) i progetti, PMexpo2017, 27/10/2017, https://goo.gl/KZhycu ISO/IEC 14764:2022
  16. 16. How to Classify Requirements? BABOK vs «ABC Schema/ISO»: a mapping A/B/C types – it depends from the content A/B/C types – it depends from the content A type (FUR) - it’s about ‘what’ the product shall do B type (NFR) – it’s about the ‘how/how much’ the product shall do B/C types (NFR/PRJ) - about the ‘how/how much’ the project and its product(s) shall do Which kind of ABC requirement type?
  17. 17. UNI 11621-x series Part 2 & Part 6…two norms sharing competencies
  18. 18. Conclusions & Next Steps The future is just out there… • BA and Measurement are two complementary areas of knowledge/expertise • asdA measurer needs good requirements to be sized • A BA needs to size his/her own requirements with specific measurement skills • Classifying requirements is important for helping PM/PMOs in producing the right planning and estimates for a project • BABOK and the ABC schema have different classifications but that can be mapped, looking for a good coverage of the project scope, avoiding the «scope creep» • eCF is asking for new e-competencies for these upcoming years • UNI 11621-x norms at the Italian level are the proper starting point for pursuing such goal at the European level • IIBA-Italy and GUFPI-ISMA collaboration • …is going on from many years • …will produce fruitful outcomes • BTW, would you like to #JoinUs?
  19. 19. Lessons Learned (…a funny end)
  20. 20. Q&A Thanks for your attention!

×