Software IMprovement using Product LinEs

Project Final Presentation

Liana Lisboa – PMProject: Starship

2

Summary

SIMPLE Factory Domain Analysis Phase Architecture Design Phase Implementation Phase Testing Project Metrics Project Strong and Weak Points Project Learned Lessons Improvement

3

SIMPLE Factory

The factory started with 7 members and an collaborator, and ended up with one member less.

Members Jobs

Liana Barachisio Project Management (PM)/ Domain Analyst

Fernando Raposo Domain Analyst/ Tests Engineer

Leandro Marques do Nascimento

Architect (ARQ)

Alexandre Martins Quality Analyst (SQA)/ Architect (ARQ)

Aline Timóteo Quality Analyst (SQA)

Rodrigo Cavalcante Mendes Configuration Management/ Architect (ARQ)

Fred Durão Developer/Consultant/PM

4

Domain Analysis Phase

Artifacts Feature Model Feature Matrix Domain Requirements Doman Use Case

5

Domain Analysis Phase

Feature Model Changes occurred during the design and implementation

phases.

These changes reflected redundancy in the model (the implication relationships) and improvement of the relationships.

6

Domain Analysis Phase

Feature model before design and implementation

made in Requiline

7

Domain Analysis Phase

Feature model after design and implementation

made in Requiline

8

Domain Analysis

Activities Followed

Identification of existing, future and potential applications

X

Identification of domain features X

Evaluation functions X

Domain modeling X

Features and domain documentation X

Domain requirements based on the features X

Domain use cases based on the features X

Process Evidence

9

Domain Analysis Phase

Feature matrix – no changes

Domain requirements – no changes

Domain use cases – Its was further detailed with the inclusion of “alternative fluxes” during the design phase

10

Domain Analysis Phase

Learned Lessons Necessity of a domain expert for the identification of the

features;

Inclusion of the domain requirement documentation improved the documentation of the domain;

Feature documentation could become extremely complex as the domain grows, although its is helpful to identify if the feature is really a part of the domain;

11

Project Metrics

Domain Analysis Phase

Planning - Foresight X Done

0:00

4:48

9:36

14:24

19:12

24:00

28:48

Lica Alexandre Fernando Aline Rodrigo Leandro Cássio Outros

Team

Ho

urs

Team

foresight

done

12

Design Phase

Artifacts Domain Architecture Feature Dependency Matrix Component Specification Evidence Document

13

Design Phase

Domain architecture definition GRASP Patterns Gamma Patterns Component Grouping

14

Design Phase

Components identified before the implementation phase Game Presentation Game Core Audio Display End Game High Score Configuration Collision Screen Control

15

Design Phase

Problems identified in the component division The “component grouping” put together the majority of the

domain variability

The components were too connected

16

Design Phase

Components division – second round Audio Actions Entity Event Graphic Movement

17

Design Phase

Modifications Game Core divided in:

Entity Movement Actions Event

Audio and Configuration put together in: Audio

Game Presentation and Display became: Graphic

Collision is now part of Event

18

Design Phase

Components division – third round

Movement were further divided in:

Movement

Strategy -> The movement strategy for the enemies

19

Design Phase

Component Specification -> updated according to the new components

Feature Dependency Matrix -> Was left aside in the new components division

Evidence Document -> no changes

20

Design Phase

Process Evidence

Activities Followed

Module decomposition X

Module refinement X

Variability representation X

Component grouping *

Component Identification X

Component Specification X

Domain Architecture Representation

21

Design Phase

Learned Lessons

Each component has to be a unique kind of variability;

The components have to be “self-contained”

22

Project Metrics

Design Phase

Design - Foresight X Done

0:00

4:48

9:36

14:24

19:12

24:00

28:48

Lica Alexandre Fernando Aline Rodrigo Leandro Cássio Outros

Equipe

Ho

ras Team

foresight

done

23

Implementation Phase

Components implemented usually with java and latter with OSGi

The implemented components with and without OSGi: Audio Graphic Movement Strategies Core -> application that can be extended

24

Implementation Phase

DEMONSTRATION!!

25

Implementation Phase

How variability was implemented? Optional – with the Builder Pattern

Or-feature -> with the Strategy Pattern

26

Implementation Phase - Testing

Issues: 16 issues reported on issue tracker; Some Issues:

No documentation (Javadoc, component description); Components assigned as High and Medium not implemented; No exception handling;

It is not hard to validate a component contract if you have: Proper component specification; A process to validate then; Tools to support the activity.

27

Implementation Phase - Testing

Conclusion It is hard to create automated tests for components that

have basically user interaction (i.e. audio, image quality...) Ideally, the component must come with a test bed for

anyone who wants to see if that component fulfills its own acceptance criteria.

It is possible to test components!

28

Implementation Phase

Learned Lessons To create the OSGI services from the self-contained

components, it is necessary a minimum documentation Main test Classes Component Documentation of Use

It is strongly recommended the presence of the component developer in the first phases of OSGI creation

It is strongly recommended the presence a technical leader to get the wide angle view of implementation activities Avoid necklaces and dependencies Improve the communication among distant developers

29

Implementation Phase

Learned Lessons (cont.) The developers must be physically together (or at least

virtually together) in the initial and during critical phases of development Distributed implementation in these phases are a risk to the

project schedule

30

Traceability

31

Project Metrics

Implementation Phase – Construction #1

Construção #1 - Foresight X Done

0:002:244:487:129:36

12:0014:2416:4819:1221:36

Lica

Alexan

dre

Ferna

ndo

Aline

Rodrig

o

Lean

dro

Cássio

Outro

s

Equipe

Ho

ras Team

foresight

done

32

Project Metrics

Implementation Phase – Construction #2

Construção #2 - Foresight X Done

00,10,20,30,40,50,60,70,8

Equipe

Ho

ras Team

foresight

done

33

Project Metrics

Implementation Phase – Construction #3

Construction #3 - Foresight X Done

0:00:00

12:00:00

24:00:00

36:00:00

48:00:00

Lica Alexandre Fernando Aline Rodrigo Leandro Cássio outros

Team

Ho

urs

Team

foresight

done

34

Project Metrics

Closing Phase

Closing

0:00:00

4:48:00

9:36:00

14:24:00

19:12:00

24:00:00

28:48:00

Lica Alexandre Fernando Aline Rodrigo Leandro Cássio Fred

Team

Ho

urs

Team

foresight

done

35

Project Metrics

General View

0%

20%

40%

60%

80%

100%

Planning Design Const #1 Const #2 Const #3 Closing

TEST

IMPLE

ARQ

REQ

SCM

SQA

GP

36

Project Strong and Weak Points

Strong Points Coherent and well defined division of the activities in the Domain

Analysis Process; Software Architect experience in Games Domain; Reuse of information from other teams and areas; Team commitment at the beginning of the project;

Weak Points The process for the design phase was not very easy to

understand; It is strange that one of the most important documents for the

design phase is the use case document since it is not part of the domain analysis process proposed;

Team lack of commitment in the final phase; Lack of experience of the team with SPL;

37

Learned Lessons

The domain expert is necessary specially in the domain analysis and design phases;

The requirements and use cases should describe the common {how they are common to the domain} and an overview of the variability, and should not describe specifically functions {in our case, “play game” should not exist};

The architecture must be planned to the technology that it will be developed.

38

Improvements

Include the domain analysis documents to the process and set its relations;

Define the metric for the DA phase, and which evaluation functions should be considered to define the domain scope and how it influences the DA;

Clarify that features beside the ones extracted from the analyzed documentation can be included in the domain;

The phases should be more connected. Like in the DA process there is no mention of the use case document that is necessary for the design phase, which does not consider the technology to be used in the implementation phase;

39

Improvements

The architecture classes should be defined after the components identification, so that each components architecture can be more isolated;

Using the OSGi as the implementation technology, it would be interesting that each variability could be implemented as a service and its component would verify if the service is available or not. That way, the variability change in the application would be dynamic.