1. Software IMprovement using Product LinEs Project Presentation (I) - Domain Analysis Results Liana Lisboa - PM Project: Starship Games PL

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

3. 3 Team Members MembersPapéis Eduardo AlmeidaStakeholder Liana BarachisioProject Management/ Domain Analyst FernandoDomain Analyst/ Tests Engineer Leandro Marques do NascimentoArchitect (ARQ) Alexandre MartinsQuality Analyst (SQA) Aline TimóteoQuality Analyst (SQA) Rodrigo Cavalcante MendesConfiguration Management/ Architect Cássio MeloTest Engineer

4. 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 PlanningDesign ConstructionClosing 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. 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. 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. 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. 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. 9 Artifacts - Feature Model

10. 10 Feature Model - divided

11. 11 Feature Model - divided

12. 12 Artifacts – Feature Matrix It shows the domain features in a hierarchy form; Contains the results for the evaluation functions;

13. 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. 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. 15 Metrics SPM - Effort

16. 16 Metrics Time Foresight X Done Planning Project Planning10:04:00 Process Planning10:44:00 Scope Definition38:14:00 Configuration Environment2:30:00 Site Project Elaboration3:20:00 Process Evaluation6:37:00 Architecture sketch0:00:00 Project Meeting17:57:00 DoneForesight 89:26:00134:45:00

17. 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. 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. 19 References [1] IXI Process; [2] The Domain Analysis Concept Revisited: a Practical Approach; [3] Feature Matrix.