Software IMprovement using Product LinEs Project Presentation (I) - Domain Analysis Results Liana...

19
Software IMprovement using Product LinEs Project Presentation (I) - Domain Analysis Results Liana Lisboa - PM Project: Starship Games PL
  • date post

    20-Dec-2015
  • Category

    Documents

  • view

    213
  • download

    0

Transcript of Software IMprovement using Product LinEs Project Presentation (I) - Domain Analysis Results Liana...

Software IMprovement using Product LinEs

Project Presentation (I) - Domain Analysis Results

Liana Lisboa - PMProject: Starship Games PL

2

Summary

Team Members IXI Process Adaptation Planning Phase Activities Artifacts Metrics Strong and Weak Points Learned Lessons References

3

Team Members

Members Papéis

Eduardo Almeida Stakeholder

Liana Barachisio Project Management/ Domain Analyst

Fernando Domain Analyst/ Tests Engineer

Leandro Marques do Nascimento Architect (ARQ)

Alexandre Martins Quality Analyst (SQA)

Aline Timóteo Quality Analyst (SQA)

Rodrigo Cavalcante Mendes Configuration Management/ Architect

Cássio Melo Test Engineer

4

IXI Process Adaptation [1]

-CM plan

-Development model

-Project plan

Domain Engineering

Domain Analysis

Domain Design

Domain Implementation

Domain

knowledge

Domain

Model

System Family Architecture

Planning Design Construction Closing

IXI Process

Milestone

04/07/06

Milestone

25/07/06

Milestone

05/08/06

-Requirement document

-Features Matrix

-Domain Model

-Use case documents

Legend

Domain Engineering Artifacts

Development Process Artifacts

5

Planning Phase Activities

Domain Analysis Process [2] Identification of existing, future and potential applications; Identification of domain features; Evaluation functions; Domain modeling; Features and domain documentation;

6

Planning Phase Activities

New Activities: Identification of the domain requirements based on the

features; Identification of the domain use cases based on the

features;

7

Artifacts – Features Model Document

It involves the information that the Feature Matrix [3] does not focus on;

The Planning section identifies the information from the preparation phase: stakeholders, objectives, constraints, market analysis and data collection.

The Application section involves the domain applications, i.e., the existing, futures and potential ones;

The Feature Model section shows the final model for the domain;

8

The Domain Documentation section has the following information about the domain: Description, defining rules, example system, documentation and

genealogy; The Features Documentation section has the following

information for each feature of the domain, except the root one (“Game”): Semantic description, rationale, example application, constraints,

variation points and priority.

Artifacts – Features Model Document

9

Artifacts - Feature Model

10

Feature Model - divided

11

Feature Model - divided

12

Artifacts – Feature Matrix

It shows the domain features in a hierarchy form; Contains the results for the evaluation functions;

13

Artifacts – Domain Requirements Document

Involves the requirements identified for the domain based on its features;

The relationship between the features and the requirements are n X n;

We included the “Associated Features” field to the requirements document;

14

Artifacts – Domain Use Case Document

Involves the use cases identified for the domain based on its features;

The relationship between the features and the use cases are n X n;

We included the “Associated Features” field to the use cases document;

15

Metrics

SPM - Effort

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

16

Metrics

Time Foresight X Done

Planning

Project Planning 10:04:00

Process Planning 10:44:00

Scope Definition 38:14:00

Configuration Environment 2:30:00

Site Project Elaboration 3:20:00

Process Evaluation 6:37:00

Architecture sketch 0:00:00

Project Meeting 17:57:00

DoneForesight

89:26:00 134:45:00

17

Strong and Weak Points

Strong Points Team commitment; Reuse of information from other teams; Coherent and well defined division of the activities; Collaborators with experience in this kind of development; Reuse of OXE’s templates;

Weak Points Game domain unknown to the majority of the team; Lack of experience with domain analysis – difficult to

identify what should a feature and should not Lack of documentation about the evaluation functions

{which ones to use, what are they meant for...}

18

Learned Lessons

Necessity of a domain expert for the identification of the features;

Definition of the relation among features X requirements X use cases;

Domain X Requirements – Application X Requirements; 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;

Huge feature models becomes too complex and are not very representative, losing focus of its functionality {understand more easily the domain};

Modification of the IXI’s templates.

19

References

[1] IXI Process; [2] The Domain Analysis Concept Revisited: a Practical Approach; [3] Feature Matrix.