Software Architecture in The Presales Process
Software Architecture in The Presales Process
Architecture in the
Presales Process
Humberto Cervantes
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
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]
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>>
- 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)
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 design Architectural design
• Humberto Cervantes
– [email protected]
19