Software Architecture in the Presales Process Humberto Cervantes - - PowerPoint PPT Presentation

software architecture in the presales process
SMART_READER_LITE
LIVE PREVIEW

Software Architecture in the Presales Process Humberto Cervantes - - PowerPoint PPT Presentation

Software Architecture in the Presales Process Humberto Cervantes Universidad Autnoma Metropolitana Iztapalapa / Quarksoft SATURN 2014 1 Quarksoft A leading software development company based in Mexico City Founded in 2001


slide-1
SLIDE 1

Software Architecture in the Presales Process

Humberto Cervantes Universidad Autónoma Metropolitana – Iztapalapa / Quarksoft SATURN 2014

1

slide-2
SLIDE 2

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

  • f enterprise applications
  • Rated at CMMI level 5

– Development based on the Team Software Process (TSP)

2

slide-3
SLIDE 3

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 Post-Mortem REQ HLD CODE Re-Launch Post-Mortem HLD CODE TEST Re-Launch Post-Mortem HLD CODE TEST Re-Launch Post-Mortem CODE TEST

Cycle 1 Cycle 2 … Cycle n

TEST REQ

3

slide-4
SLIDE 4

Previous work

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>> Re-Launch Post-Mortem HLD CODE TEST REQ

  • Documentation using

scenarios

  • Adapted ADD
  • Use of VaB Templates
  • Scenario‐based

evaluations

Problem: Many architectural decisions are made before the actual TSP‐based development is performed, during Presales

  • “Introducing Software Architecture Development Methods

into a TSP‐Based Development Company” (SATURN 2010)

4

slide-5
SLIDE 5

Project development

  • 2 important phases

Presales Development (TSP)

Historic database

Project data Estimation data

[Accepted] [Rejected]

  • Architect
  • Leader
  • Architect
  • Leader
  • Team

5

slide-6
SLIDE 6

Project development

  • 2 important phases

Presales Development (TSP)

Historic database

Project data Estimation data

[Accepted] [Rejected]

  • Architect
  • Leader
  • Architect
  • Leader
  • Team
  • These estimates are calculated from

components associated with specific technologies

  • Identification of estimation

components is an essential task

Architecture development starts in presales

6

slide-7
SLIDE 7

The presales context

Presales

  • Limited information
  • Short time
  • Internal constraints
  • Competition with other

providers

  • Architect
  • Leader

Leffingwell, D. “Features, Use Cases, Requirements, Oh My!”, Rational Software White Paper, 2000

7

slide-8
SLIDE 8

Architecture in Presales

  • We had to adapt architectural methods to the

presales context

Presales Development (TSP)

[Accepted] [Rejected]

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

Presales architecture

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

  • Architect
  • Leader
  • Architect
  • Leader
  • Team

8

slide-9
SLIDE 9

Presales architectural drivers

  • We shifted the focus from purely

functional features to an architectural drivers approach

– Primary features

  • “The kiosk system shall allow birth

certificates to be visualized and printed”

– Early quality attributes

  • “100% of the information that is stored in

the kiosk system shall be protected (Security)”

– Constraints

  • “The operating system of the kiosks is

windows XP”

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

9

slide-10
SLIDE 10

Presales architectural design

  • Goals:

– Estimation – Project planning – Satisfying drivers

  • Design decisions for the presales architecture

– Selection and adaptation of a reference architecture – Selection of technologies – Establishment of deployment layout – Identification of components for estimation

  • The equivalent of performing initial iterations
  • f ADD

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

Presales architecture

10

slide-11
SLIDE 11

Example

Sample reference architecture (from Microsoft Application Architecture Guide)

11 Estimation component Estimation component Estimation component Estimation component Estimation component Estimation component Estimation component Estimation component Estimation component Estimation component

slide-12
SLIDE 12

Presales architectural documentation

  • The “primary presentation” and

element catalog sections from the VaB template are used

  • The diagrams that represent the

architecture are included in the project proposal

– Module view – Layers / Technologies – Deployment view

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

12

slide-13
SLIDE 13

Presales architectural evaluation

  • 2 – 4 hours peer review process that analyzes

design decisions with respect to the drivers

– Performed before estimation – 3 architects – Seeks to identify risks both in the design decisions of the technical solution but also in the project strategy

  • Some types of risks

– Requirements, for example

  • Quality Attributes not quantified

– Design decisions, for example

  • Inappropriate deployment layout
  • No expertise in selected framework

– Strategy

  • The selected lifecycle is not appropriate to the level
  • f technical risks in the project

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

13

slide-14
SLIDE 14

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

slide-15
SLIDE 15

Current results: Evaluation

  • We have conducted 18 evaluations

since July 2013

  • On average the evaluations uncover

between 6 and 7 risks (60% technical)

  • Good (internal) customer satisfaction

– “In general, the evaluation was useful”: 4.2 / 5 – “The observations made by the evaluation team were valuable”: 4.6 / 5

  • Good response time: 2.9 work days on

average

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

15

slide-16
SLIDE 16

Lessons learned

  • Starting architectural activities from the

beginning of project development is very valuable in this context

– Results in iterative architectural development

Pre‐sales Development (TSP)

[Accepted] [Rejected]

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

  • Early drivers
  • Initial ADD

iterations

  • Initial views
  • Initial project plan
  • Scenarios
  • Subsequent ADD

iterations

  • Standard views
  • Actual project

plan

Presales architecture Final architecture 16

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

Pre‐sales Development (TSP)

[Accepted] [Rejected]

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

Architectural drivers Architectural design Architectural documentation Architectural evaluation

<<precedes>> <<precedes>> <<precedes>>

  • Architect
  • Leader
  • Architect
  • Leader
  • Team

Presales architecture Final architecture 18

slide-19
SLIDE 19

Thank you!

  • Questions?
  • Humberto Cervantes

– hcm@xanum.uam.mx

19