spm10 spm and software architecture
DESCRIPTION
Slides for the 10th lecture on Software Architecture for the Software Product Management course at Utrecht University.TRANSCRIPT
![Page 1: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/1.jpg)
Software Product Management Software Architecture
Lecture 10
Garm Lucassen
Sjaak Brinkkemper
24 September 2014
![Page 2: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/2.jpg)
Relationship agenda
• Software Architecture definition & motivation
• The Software Architect
• SPM and SA processes
• In practice
• Improving the collaboration
• Future vision: continuous architecting
• Assignment
2
![Page 3: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/3.jpg)
Software Architecture
• Software Architecture is the set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both (Clements et al., 2010)
• Industry refers to “software architecture” for three things:
1. The (conceptual) high level structure of software (instantiation)
2. Discipline of creating a high level structure
3. Documentation of the high level structure
The Software Product Architect is responsible for creating and maintaining the software product’s architectural structure and integrity
In this lecture we focus on how Software Product Management and Software Architecture relate.
3
![Page 4: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/4.jpg)
Motivation
• Helferich, Schmid and Herzwurm in 2006: SPM alignment with SA is critical to the success of a software product line!
– Reuse potential is lost
– Major product opportunities missed
• Fricker (2012): As of yet it is unclear how effective business-socio-technical congruence is achieved and what its empirically grounded business case is
4
![Page 5: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/5.jpg)
Motivation
• Helferich, Schmid and Herzwurm in 2006: SPM alignment with SA is critical to the success of a software product line!
– Reuse potential is lost
– Major product opportunities missed
• Fricker (2012):
5
![Page 6: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/6.jpg)
Motivation
• Helferich, Schmid and Herzwurm in 2006: SPM alignment with SA is critical to the success of a software product line!
– Reuse potential is lost
– Major product opportunities missed
• Fricker (2012): that’s cool but no one really knows how, let alone whether it’s really worth the effort
6
![Page 7: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/7.jpg)
Motivation
• Therefore… study software product manager interaction with software architect
– What processes should you participate in together?
– What are your reciprocal contributions to one another?
– How can you improve your relationship?
7
![Page 8: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/8.jpg)
Relationship agenda
• Software Architecture definition & motivation
• The Software Architect
• SPM and SA processes
• In practice
• Improving the collaboration
• Future vision: continuous architecting
• Assignment
8
![Page 9: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/9.jpg)
The Software Architect
• In Software Producing Organizations (SPOs)
– Software architect is a loosely defined role
– Typically early employee
– “First among equals”
– “Knows everything, but there is no documentation.”
• Has four primary tasks (Taylor et al., 2010)
1. Developing project strategy
2. Designing systems
3. Communicating with stakeholders
4. Being a leader
9
![Page 10: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/10.jpg)
The Software Architect
• Over time software architecture forms by making Architectural Design Decisions (ADDs) based on project context:
– Stakeholder requirements
– History of previous ADDs
• ADDs for architecturally significant requirements beforehand
• All others on an ad-hoc basis
• Agile?
10
![Page 11: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/11.jpg)
The Software Architect
• Creates architecture documentation for multiple purposes (Clements et al., 2010)
– Design
– Analyze
– Communicate
– Educate
• Architecture descriptions are inherently multi-viewed (IEEE Standard 1471-200)
11
![Page 12: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/12.jpg)
Relationship agenda
• Software Architecture definition & motivation
• The Software Architect
• SPM and SA processes
• In practice
• Improving the collaboration
• Future vision: continuous architecting
• Assignment
12
![Page 13: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/13.jpg)
SPM and SA processes
• SPM is closely linked to requirements engineering (Ebert, 2007)
• SA demands good requirements engineering
13
Twin Peaks of Requirements and Architecture (Nuseibeh, 2001)
![Page 14: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/14.jpg)
SPM and SA processes
SPM Goals (Ebert, 2007) SA Goals (Taylor, 2010)
Creating a winning product Developing project strategy
Conquering markets and growing market share
Designing systems
Delivering value to customers Communicating with stakeholders
Being a leader
14
Requirements are central to both stakeholders
• Satisfy customer requirements to deliver value and create product success
Demands selecting the right requirements
Enabling developers to implements them in the right way
![Page 15: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/15.jpg)
Impact on one another’s goals
• Software architect contributes to
1. creating a winning product
2. delivering value to customers
• Product quality depends on architect’s success at
1. Developing project strategy
2. Designing systems
• However, impact of a successful software architect in comparison to less successful is unknown…
15
![Page 16: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/16.jpg)
Impact on one another’s goals
• Product manager contributes to developing project strategy
– Software architects formulate adequate technical solutions for any requirement
– Solution might be sub-optimal for product context (Taylor et al., 2010)
– Quality Attributes vary per feature
16
![Page 17: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/17.jpg)
Impact on one another’s goals
• Product manager is the interface for communicating with external stakeholders
– Taylor notes that software architects are in frequent contact with customers and users
– Impossible for SPOs. Large number and widely varying customers and users
– Instead, product manager is gatekeeper
17
![Page 18: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/18.jpg)
Reciprocal Contributions Model
18
Lucassen et al., 2014
![Page 19: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/19.jpg)
RCM-A1: Product requirement
• A product requirement is a requirement to be covered by future product releases described in the company’s own terminology and context.
![Page 20: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/20.jpg)
RCM-A2: Requirement feedback
• Architect reviews the product requirements
• And gives feedback
– Constraints
– Grouping
– Dependencies
– Ask for requirement details
– Technical impact
20
“This requirement necessitates first implementing NGF-137”
“We need to split this requirement into a client and server requirement”
![Page 21: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/21.jpg)
Reciprocal Contributions Model
21
Lucassen et al., 2014
Requirement Refinement, identification
and organizing
![Page 22: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/22.jpg)
RCM-A3: Architectural Product Knowledge
• Product manager needs architectural input to
– Identify technical debt
– Understand technical details of the product
– Understand opportunities of new technology
– Create roadmaps
• “HTML5 video is cool. Maybe we should replace our flash player?”
• “We’re still on Ruby on Rails 2.3.2. We need to upgrade now or run into huge problems in the (near) future”
22
![Page 23: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/23.jpg)
Reciprocal Contributions Model
23
Lucassen et al., 2014
Requirements gathering, input for
roadmapping
![Page 24: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/24.jpg)
RCM-A4: Release definition
• To be written by Product Manager
– Co-authors: Architect & Marketing
• Scope
– Whole product release
– Only for major and minor releases; not for bug fixes
• Content
– Major theme(s) of the release
– Listing of product requirements to be incorporated in the next release (copied labels from RDB)
– Critical dependencies between product requirements
– Distributed ownership of envisaged work
– Planned release date
![Page 25: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/25.jpg)
RCM-A5: Product context
• Alongside the release definition
– Enables autonomous decision making
– Understand reasoning behind feature (why)
– Prevents mis-implementation
• Requires extra effort now
• Eventually leads to better quality and cheaper development
• “We want the data structure for the questionnaire module to support all imagineable question types. Although we focus on strictly likert and multiple choice now, we intend to expand in the near future”
25
![Page 26: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/26.jpg)
Reciprocal Contributions Model
26
Lucassen et al., 2014
Product context
clarification
![Page 27: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/27.jpg)
RCM-A6: Architectural Design Decisions
• Choices that shape your product
• Includes the rationale
• Set of ADDs leads to the architecture of the product
• And thus ultimately deliver value
• “For the time being we keep the Pre-payment module within Ticket Sales. From Release 4.0 on it will be moved to Payment.”
27
![Page 28: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/28.jpg)
Relationship agenda
• Software Architecture definition & motivation
• The Software Architect
• SPM and SA processes
• In practice
• Improving the collaboration
• Future vision: continuous architecting
• Assignment
28
![Page 29: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/29.jpg)
SPM & SA Collaborative Processes
• Common collaborative processes:
– Requirements refinement
– Requirements gathering
– Product roadmapping
– Requirements prioritization
• Expected, but unconfirmed:
– Product context clarification
• Others:
– External stakeholder communication
– Requirements organization and identification?
29
Common Indirect Unconfirmed
Requirements gathering Requirements identification
Product context clarification
Requirements prioritization
Requirements organization
Requirements refinement
Product roadmapping
![Page 30: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/30.jpg)
SPM & SA collaborative processes
+ Requirements Refinement
30
![Page 31: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/31.jpg)
Product Context Clarification ?
• Transferring product context is not important
• Yet, software architects have deep contextual knowledge:
– Software architect employee before product manager
– Contextual knowledge grows organically
• However…
– Product context, markets, technology and customers change
31
![Page 32: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/32.jpg)
Requirements Gathering
• Software architect is a unique internal stakeholder
– Technical debt
– Formulate requirements for critical deficiencies
• Even for technically strong product managers
“Gathering requirements from the software architect is our most important collaborative process. Due to my functional
focus, I no longer notice where code quality is degrading and overdue maintenance is growing”
32
![Page 33: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/33.jpg)
Requirements Gathering
• Typically a maintenance meeting every other week
– Software architect presents problem areas
– Product manager shares business perspective
– Go or no go on maintenance effort
• Unnecessary if software architect has strong product context awareness
33
![Page 34: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/34.jpg)
Requirements Refinement
• Virtually all product manager refine requirements with software architect
• Not included in SPMCM
• Approach as described in Vlaanderen et al. (2011) is excellent, but uncommon
• Simple approach
– SPM creates high level definitions for requirements
– SPM coordinates and supports dev team in (bi-)weekly refinement meeting
34
![Page 35: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/35.jpg)
Requirements Refinement Meeting
• Product manager
– Answers development questions
– Validates development’s interpretation of his work
– Sometimes assists in dependency linking (organizing)
• Conveying WHY we are developing a feature is imperative
– Enables developers to:
• Autonomously answer questions
• Prevents additional information requests
• Prevents incorrectly implemented features
35
![Page 36: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/36.jpg)
Requirements Prioritization & Product Roadmapping
• Half of product managers involve software architect in prioritization and roadmapping
• Software architect complements product manager’s technical expertise
• Product manager makes actual decisions
• Less relevant when product manager is technically strong
36
![Page 37: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/37.jpg)
Relationship agenda
• Software Architecture definition & motivation
• The Software Architect
• SPM and SA processes
• In practice
• Improving the collaboration
• Future vision: continuous architecting
• Assignment
37
![Page 38: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/38.jpg)
Improving the collaboration
• Virtually no tools/methods available
• Software Architecture Documentation?
• Shared architectural views improves:
– people alignment
– communication clarity
• But SPOs refuse to create meticulous architectural models
– Errors in models lead to wrong decisions
– “No documentation is better than outdated and thus wrong documentation”
38
![Page 39: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/39.jpg)
What can we do?
• Rely on drawing incidental models?
– Forgoes educational and analysis benefits
• Define a company-wide approach:
– Utilize a hybrid functional/technical view
– Agree on a level of detail that both stakeholders can work with
– Document your views in one, community accessible place
– Adhere to a strict step-wise approach like the Accurate Architectural Models Approach
39
![Page 40: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/40.jpg)
AAMA
40
This is still kind of primitive…
![Page 41: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/41.jpg)
Relationship agenda
• Software Architecture definition & motivation
• The Software Architect
• SPM and SA processes
• In practice
• Improving the collaboration
• Future vision: continuous architecting
• Assignment
41
![Page 42: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/42.jpg)
Continuous Architecting (vision)
42
![Page 43: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/43.jpg)
Requirements and Architecting on a Video Wall
43
![Page 44: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/44.jpg)
Assignment
• Case study on stakeholder involvement during requirements management and roadmapping
• Focus is on mutual information exchange between product manager and software architect
• Semi-structured interview
– We provide questions
– But you should ask follow-up questions
44
![Page 45: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/45.jpg)
Assignment
• Following four goals:
1. To describe the product manager’s requirements management processes including requirements gathering,
requirements identification, requirements organization and requirements refinement.
2. To describe the product manager's roadmapping processes.
3. To relate the Reciprocal Contributions Model (Lucassen,
2014) to your company’s situation, explaining which artifacts and activities are present and absent.
4. Formulate advice to improve the company's requirements
management and roadmapping processes.
45
![Page 46: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/46.jpg)
Assignment
• 7 steps:
1. Introduce the research goals
2. Explain the interview structure
3. Ask sufficient questions to write a report on the Requirements Management & Roadmapping subjects below
4. Introduce the SPM & SA Reciprocal Contributions Model
5. Discuss the SPM & SA Reciprocal Contributions Model with the interviewee
6. Ask if the interviewee has any questions
7. Invite the interviewee to the Industry Session on Friday October 31
46
![Page 47: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/47.jpg)
Assignment
• Available on website
– Outline case study report (approx 4500 words)
– Suggested Questions
• Not all questions are going to be relevant
• Expected to put more emphasis on some questions/sections than others
47
![Page 48: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/48.jpg)
SPMCM
48
![Page 49: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/49.jpg)
Reciprocal Contributions Model
49
![Page 50: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/50.jpg)
Questions?
50
![Page 51: SPM10 SPM and Software Architecture](https://reader033.vdocuments.us/reader033/viewer/2022052323/55894cdbd8b42a7d268b45ee/html5/thumbnails/51.jpg)
References
51