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

Slides:



Advertisements
Similar presentations
Armstrong Process Group, Inc. Copyright © , Armstrong Process Group, Inc., and others All rights reserved Armstrong Process.
Advertisements

Project Scope Management
Web Development Engineering Processes Introduction to Web Development Outsourcing Processes.
Domain Engineering Silvio Romero de Lemos Meira
Chapter 22 Product Line Engineering Week 1 CIS 673.
Copyright 2009  Develop the project charter: working with stakeholders to create the document that formally authorizes a project—the charter  Develop.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
® IBM Software Group © 2006 IBM Corporation PRJ480 Mastering the Management of Iterative Development v2 Module 4: Phase Management - Elaboration.
Rational Unified Process
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
Software IMprovement using Product LinEs Project Final Presentation Liana Lisboa – PM Project: Starship.
Software IMprovement using Product LinEs Project Presentation (III) - Implementation Liana Lisboa – PM Project: Starship.
Information Modeling: The process and the required competencies of its participants Paul Frederiks Theo van der Weide.
COMP 350: Object Oriented Analysis and Design Lecture 2
Software IMprovement using Product LinEs Project Presentation (II) - Architecture Design Alexandre Martins – SQA Rodrigo Mendes - Software Architect Project:
Software IMprovement using Product LinEs Project Presentation (III) - Implementation Liana Lisboa – PM Project: Starship.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software IMprovement using Product LinEs Project Presentation (III) - Implementation Liana Lisboa – PM Project: Starship.
Stoimen Stoimenov QA Engineer QA Engineer SitefinityLeads,SitefinityTeam6 Telerik QA Academy Telerik QA Academy.
SQA Architecture Software Quality.
Framework Project Concept Source – PMBOK®– 2008 Edition Project Management Professional Project Management Professional (P M P)
Configuration Management Avoiding Costly Confusion mostly stolen from Chapter 27 of Pressman.
Requirements Management
What is Business Analysis Planning & Monitoring?
S/W Project Management
RUP Fundamentals - Instructor Notes
Rational Unified Process Fundamentals Module 4: Disciplines II.
Computer Systems & Architecture Lesson Software Architecture in the Future.
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
Requirements Traceability: Planning, Tracking and Managing Requirements Presenter: Paula R. Maychruk, BV/TEd., CAPM, CBAP.
Student Portfolio Development. Portfolio Development Define the following: Portfolio Artifact Evidence Medium Annotation Design Analysis STUDENTS: Write.
T Final demo I2 Iteration Agenda  Product presentation (20 min) ‏  Project close-up (20 min) ‏ Evaluation of the results  Questions.
1-2 Training of Process Facilitators 3-1. Training of Process Facilitators 1- Provide an overview of the role and skills of a Communities That Care Process.
Rational Unified Process Fundamentals Module 5: Implementing RUP.
Component Based SW Development and Domain Engineering 1 Component Based Software Development and Domain Engineering.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
Search Engine Optimization © HiTech Institute. All rights reserved. Slide 1 What is Solution Assessment & Validation?
Software Engineering COSC 4460 Class 4 Cherry Owen.
System Context and Domain Analysis Abbas Rasoolzadegan.
PRJ566 Project Planning & Management Software Architecture.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Project Initiation at The Regence Group 12/19/2015John Garrigues1.
Software Project Management (SEWPZG622) BITS-WIPRO Collaborative Programme: MS in Software Engineering SECOND SEMESTER /1/ "The content of this.
1 Class exercise II: Use Case Implementation Deborah McGuinness and Peter Fox CSCI Week 8, October 20, 2008.
An organizational structure is a mostly hierarchical concept of subordination of entities that collaborate and contribute to serve one common aim... Organizational.
ICIST 2011 Mar , Nanjing, China Visualization in Software Architecture Helen Wu 1 Let’s Enforce a Simple Rule in Software Architecture Helen.
Software Reuse Course: # The Johns-Hopkins University Montgomery County Campus Fall 2000 Session 4 Lecture # 3 - September 28, 2004.
CSIS 4850: CS Senior Project – Spring 2009 CSIS 4850: Senior Project Spring 2009 Object-Oriented Design.
Rational Unified Process Fundamentals Module 5: Implementing Rational Unified Process Rational Unified Process Fundamentals Module 5: Implementing Rational.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
Software architecture is the high- level structure of a software system. It has no concrete definition but can be best described as an organizational.
1 Requirements Engineering for Agile Methods Lecture # 41.
University of Southern California Center for Systems and Software Engineering RDCR ARB CS 577b Software Engineering II Supannika Koolmanojwong.
TK2023 Object-Oriented Software Engineering
Process 4 Hours.
Review of last class Software Engineering Modeling Problem Solving
Software project management
INTRODUCTION.
Independent Study of Ontologies
Abstract descriptions of systems whose requirements are being analysed
SOFTWARE ARCHITECTURE AND DESIGN
9/18/2018 Department of Software Engineering and IT Engineering
Group #1 – Artifact Concept Model AUG 2018
Avoiding failure when implementing an enterprise system
X-DIS/XBRL Phase 2 Kick-Off
CSCI 360: Software Architecture & Design
Presentation transcript:

Software IMprovement using Product LinEs Project Presentation (I) - Domain Analysis Results Liana Lisboa - PM Project: 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 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 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 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

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 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.