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 Re-Launch Re-Launch Launch Re-Launch HLD REQ CODE REQ CODE HLD HLD TEST CODE CODE TEST TEST TEST Post-Mortem Post-Mortem Post-Mortem Post-Mortem 3 Cycle 1 Cycle 2 … Cycle n
Previous work • “ Introducing Software Architecture Development Methods into a TSP ‐ Based Development Company ” (SATURN 2010) • Documentation using Architectural drivers scenarios Re-Launch <<precedes>> REQ Architectural design • Adapted ADD HLD <<precedes>> CODE TEST Architectural • Use of VaB Templates Post-Mortem documentation <<precedes>> Problem: Many architectural Architectural • Scenario ‐ based decisions are made before the evaluation evaluations actual TSP ‐ based development is performed, during Presales 4
Project development • 2 important phases [Accepted] Presales Development (TSP) [Rejected] - Architect - Architect Estimation Project data - Leader - Leader data - Team Historic database 5
Project development • 2 important phases [Accepted] Presales Development (TSP) • These estimates are calculated from [Rejected] components associated with specific - Architect - Architect Estimation Project data technologies - Leader - Leader data - 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>> Presales Architectural design Architectural design <<precedes>> <<precedes>> architecture Architectural Architectural documentation documentation <<precedes>> <<precedes>> - Architect - Architect Architectural Architectural evaluation evaluation - 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 – Primary features <<precedes>> • “The kiosk system shall allow birth Architectural design certificates to be visualized and printed” <<precedes>> – Early quality attributes Architectural • “100% of the information that is stored in documentation the kiosk system shall be protected (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 Estimation component component component Estimation component Estimation Estimation 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 documentation – “The observations made by the <<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 • Scenarios Architectural drivers [Rejected] Architectural drivers • Initial ADD • Subsequent ADD <<precedes>> <<precedes>> iterations iterations Architectural design Architectural design <<precedes>> <<precedes>> • Initial views • Standard views Architectural Architectural • Initial project plan • Actual project documentation documentation <<precedes>> <<precedes>> plan Architectural Architectural 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 Architectural drivers [Rejected] <<precedes>> <<precedes>> Architectural design Architectural design - Architect - Architect <<precedes>> <<precedes>> - Leader - Leader Architectural Architectural documentation documentation - Team <<precedes>> Presales <<precedes>> Final Architectural Architectural architecture architecture evaluation evaluation 18
Thank you! • Questions? • Humberto Cervantes – hcm@xanum.uam.mx 19
Recommend
More recommend
