Software
Architecture in the
Presales Process
Humberto Cervantes
Universidad Autónoma Metropolitana – Iztapalapa /
Quarksoft
SATURN 2014
1
Quarksoft
• A leading software development company based in Mexico
City
– Founded in 2001
– Offices in Mexico, Spain and USA
• Quarksoft develops custom software for different domains
– Insurance, Manufacturing, Telecommunication, Government
Healthcare
– Many projects are greenfield development
of enterprise applications
• Rated at CMMI level 5
– Development based on the Team Software
Process (TSP)
2
Team Software Process (TSP)
• Proven method that helps plan, evaluate, manage and
control software development work
– Focus on metrics‐based project and quality management
– Does not provide precise guidance on the engineering
activities such as requirements or architectural design
Launch Re-Launch Re-Launch Re-Launch
HLD
REQ
CODE
REQ
HLD CODE
HLD CODE TEST
CODE
TEST TEST TEST
Post-Mortem Post-Mortem Post-Mortem Post-Mortem
Cycle 1 Cycle 2 … Cycle n 3
Previous work
• “Introducing Software Architecture Development Methods
into a TSP‐Based Development Company” (SATURN 2010)
Architectural drivers • Documentation using
Re-Launch scenarios
<<precedes>>
REQ
Architectural design • Adapted ADD
HLD
<<precedes>>
CODE
TEST Architectural
Post-Mortem documentation
• Use of VaB Templates
<<precedes>>
Problem: Many architectural
decisions are made before the Architectural • Scenario‐based
actual TSP‐based development is evaluation evaluations
performed, during Presales 4
Project development
• 2 important phases
[Accepted]
Presales Development
(TSP)
[Rejected]
- Architect Estimation Project data - Architect
- Leader data - Leader
- Team
Historic database
5
Project development
• 2 important phases
[Accepted]
Presales Development
(TSP)
• These estimates are calculated from
[Rejected]
- Architect Estimation
components associated with specific
Project data - Architect
- Leader data technologies - Leader
- Team
• Identification of estimation
components is an essential task
Historic database
Architecture development starts in presales 6
The presales context
Presales
- Architect
- Leader
• Limited information
• Short time
• Internal constraints
• Competition with other Leffingwell, D. “Features, Use Cases, Requirements, Oh My!”,
Rational Software White Paper, 2000
providers
7
Architecture in Presales
• We had to adapt architectural methods to the
presales context
Architectural drivers Architectural drivers
<<precedes>> <<precedes>>
Architectural design
Presales Architectural design
<<precedes>> <<precedes>>
Architectural architecture Architectural
documentation documentation
<<precedes>> <<precedes>>
- Architect Architectural
evaluation
Architectural
evaluation
- Architect
- Leader - Leader
- Team
[Accepted]
Presales Development
(TSP)
[Rejected]
8
Presales architectural drivers
• We shifted the focus from purely
functional features to an architectural
Architectural drivers
drivers approach
<<precedes>>
– Primary features
• “The kiosk system shall allow birth Architectural design
certificates to be visualized and printed”
<<precedes>>
– Early quality attributes
• “100% of the information that is stored in Architectural
the kiosk system shall be protected documentation
(Security)” <<precedes>>
– Constraints Architectural
evaluation
• “The operating system of the kiosks is
windows XP”
9
Presales architectural design
• Goals:
Presales
– Estimation architecture
– Project planning Architectural drivers
– Satisfying drivers
<<precedes>>
• Design decisions for the presales architecture Architectural design
– Selection and adaptation of a reference
architecture <<precedes>>
– Selection of technologies Architectural
– Establishment of deployment layout documentation
– Identification of components for estimation <<precedes>>
Architectural
• The equivalent of performing initial iterations evaluation
of ADD
10
Example
Estimation
component
Estimation Estimation
component component Estimation
component
Estimation
Estimation Estimation component
component component
Estimation
component
Estimation Estimation
component component
Sample reference architecture
(from Microsoft Application Architecture Guide)
11
Presales architectural documentation
• The “primary presentation” and
element catalog sections from Architectural drivers
the VaB template are used
<<precedes>>
Architectural design
• The diagrams that represent the <<precedes>>
architecture are included in the Architectural
project proposal documentation
– Module view <<precedes>>
Architectural
– Layers / Technologies evaluation
– Deployment view
12
Presales architectural evaluation
• 2 – 4 hours peer review process that analyzes
design decisions with respect to the drivers
– Performed before estimation Architectural drivers
– 3 architects
– Seeks to identify risks both in the design <<precedes>>
decisions of the technical solution but also in the
project strategy Architectural design
<<precedes>>
• Some types of risks
Architectural
– Requirements, for example
documentation
• Quality Attributes not quantified
<<precedes>>
– Design decisions, for example
• Inappropriate deployment layout Architectural
• No expertise in selected framework evaluation
– Strategy
• The selected lifecycle is not appropriate to the level
of technical risks in the project
13
Current results: General
• Architecture is now taken into account from the very
beginning of the project’s development life cycle
• Early requirement gathering is driven by the architectural
drivers
• The approach ensures that the presales architecture design
is well aligned to the drivers, but also that the project
strategy supports architectural development
• The proposals that are provided to the customer reflect this
architectural‐centric focus
14
Current results: Evaluation
• We have conducted 18 evaluations
since July 2013
Architectural drivers
• On average the evaluations uncover
<<precedes>>
between 6 and 7 risks (60% technical)
• Good (internal) customer satisfaction Architectural design
– “In general, the evaluation was useful”: <<precedes>>
4.2 / 5 Architectural
– “The observations made by the documentation
<<precedes>>
evaluation team were valuable”: 4.6 / 5
Architectural
• Good response time: 2.9 work days on evaluation
average
15
Lessons learned
• Starting architectural activities from the
beginning of project development is very valuable
in this context
– Results in iterative architectural development
[Accepted]
Pre‐sales Development
(TSP)
• Early drivers Architectural drivers [Rejected] Architectural drivers • Scenarios
• Initial ADD <<precedes>> <<precedes>>
• Subsequent ADD
iterations Architectural design Architectural design
iterations
<<precedes>> <<precedes>>
• Initial views Architectural Architectural
• Standard views
• Initial project plan documentation
<<precedes>>
documentation
<<precedes>>
• Actual project
Architectural Architectural plan
evaluation evaluation
Presales Final
architecture architecture
16
More lessons learned
• Major challenges are related to logistics
– Being able to respond quickly to evaluation requests is
essential
– Training of architects
– The organization must also be adapted in order to
support evaluations
• The presales phase is a great place to experiment
with new approaches
– Frequent evaluations are great for helping the
architects gain maturity
17
Future work
• Evaluate the impact
– We are starting to conduct evaluations on projects
that use the new methods in presales but data
needs to be gathered to evaluate the
improvements
[Accepted]
Pre‐sales Development
(TSP)
Architectural drivers [Rejected] Architectural drivers
<<precedes>> <<precedes>>
Architectural design Architectural design
- Architect <<precedes>> <<precedes>>
- Architect
- Leader Architectural Architectural - Leader
documentation documentation
<<precedes>>
Presales <<precedes>>
Final
- Team
Architectural Architectural
evaluation architecture evaluation architecture
18
Thank you!
• Questions?
• Humberto Cervantes
– [email protected]
19