Wicsa7:Workshop:The Value of Software Architecture
From WICSA Conference Wiki
Contents |
Workshop
Friday, 22 February 2008, 9:00 – 12:30
Organizers
- Sérgio Almeida Dias
- Marcos Pedroso
- Phd. Reginaldo Arakaki
Workshop Theme
This workshop will discuss and propose alternatives to measure software architecture complexity based on quality attributes as non-functional requirements such as performance, reliability, and modifiability.
Popular software complexity estimates, like function-points, are focused on the functionality and do not pay enough attention to complexity imposed to fulfill the severe quality requirements of some modern projects.
The participants will be encouraged to analyze different implications of architecture and quality attributes on software development efforts and risks.
The goal of this workshop is to produce insights to encourage further research and future methods that consider quality attributes on software complexity metrics.
Questions to stimulate discussion:
- What do Function Point, COSMIC and COCOMO not measure? Can cost models help us place a value on architecture? - Quality Point/Scenario Based Point?
- Software systems quality attributes are realized as a result of tradeoff decisions. How do we identify Quality Attributes and Tradeoff requirements and increase the value of software architecture? (ATAM/QAW)
- Architectures deliver quality attributes such as performance, reliability, modifiability, etc. What is the cost or benefit of these?
- How do we identify uncertainty points that can reduce the value of software architecture? (Formalize risks and uncertainties)
- Which metrics can be used to define mitigation actions upon software architecture uncertainties?
- The existence of a project knowledge database is very critical to support an estimation model creation. Which information is critical to be collected from the projects? Which kinds of analysis are relevant for software architecture complexity estimation and value analysis?
Workshop Discussions and Contributions
From the six proposed subjects, participants decided to focus on two.
Cost Models
The proposed seed of discussion was:
- Estimates using one or more techniques:
- Knowledge Base
- Lines of Code
- Function Point: measure techniques aimed in functionality elements
- Mathematical Models - COCOMO: mathematical model-based estimate where this model provides complexity elements
- Pressman and Sommerville
- These techniques are not adequate to measure the architectural complexity in aspects like: security, scalability, usability, changeability:
- uses some context and environment factor (function point)
- uses productivity to distinguish contexts
Mr. Mohamad Kassab, from Concordia University, presented us his research work on this subject, based on the article Non-Functional Requirements: Size Measurement and Testing with COSMIC-FFP written by him, O. Ormandjieva, M. Daneva, and A. Abran.
Our annotations on discussions
- Sometimes, the amount expend to evaluate non-function points could cost more than the result itself
- Some non-functional aspects already have a base estimation related to entire project, for example, a specific ability take 5% of the project.
- NFR is very immature yet e mostly based on previous project knowledge experience.
- NFR evaluation can impact in initial estimation of Functional Requirements
- That is an idea to come from NFR and finding out the consequences for the project, registering the rationales of decisions taken.
- NFR provides patterns to correlate NFRs between each other.
Future Work
Discussions during workshop didn't address, however, the challenge of effectively identify the complexity derived from architectural decisions. Existing approach still relies on some sort of "productivity index". The NFR Framework helps a lot on revealing existing dependencies between NFRs and to manage the complete set of covered NFRs. Required effort, though, should be determined using a conventional approach, driven by functionality.
Cost Models
The proposed seeds of discussion was:
- Subject 3: Architectures, Quality Attributes and ROI
- BP - Functionality: benefits of automation
- Functionality demands architectural infrastructure: architecture costs
- Architecture costs brings automation benefits
- Subject 4: Risks and uncertainty
- ATAM Scenarios - critical situations: helps on risks and uncertainty identification
- Quality Attributes helps to mitigate risks and uncertainties
- Without proper handling they decrease architecture value
- Architecture Value = fplus (BP, Functionality, Architecture Benefit, Managed Risks, Handled Uncertanties)
- - fminus(Architecture Cost, Unhandled Risks)
Our annotations on discussions
With these themes in mind, discussions was mostly on the following areas:
- Value is different from cost
- First identify the ability with risk. Than we have to show evidences to customer that we are aware about it
- But, how to identify correct ability? Non identified NFR could bring damage to the proposed architecture. "Most of the time we have faced NFR we didn't expected at the begin of the prject" is a common statement. Correctly identify architectural risks relies mostly on architects experience.
- A good software architect is the one that preciselly address NFR that were more important when it was designed
- Extensive use of prototypes is an idea to be evaluated? Some abilities can't be handled by that?
- Is difficult to separate Risks and Uncertainties. It's probably a good idea to have a kind o guideline to guide such classifications.
- Could NFR Framework help to identify undisclosed risks?
Future Work
Based on discussions during the workshop, the subject of risk identification is the very first that comes to everyone's mind. Risk mitigation is the second step of the process that will not be reached if correct risks were not identified.
