Project Name
Final Project Report
Version 1.0
Doc. No.:
Software Merge
Final Project Report
Version:
1.0
Date: 2016-03-06
Revision History
Date
Version
Description
Author
2006-01-18
0.1
First draft
Mathias Alexandersson
2006-01-19
1.0
Added worked hours, updated requirements
Mathias Alexandersson
Page 2
Software Merge
Final Project Report
Version:
1.0
Date: 2016-03-06
Table of Contents
1.
Introduction
4
1.1
1.2
1.3
1.4
Purpose of this document
Intended Audience
Scope
Definitions and acronyms
1.4.1 Definitions
1.4.2 Acronyms and abbreviations
1.5 References
4
4
4
4
4
4
4
2.
Background and Objectives
4
3.
Organization
5
3.1
3.2
3.3
3.4
3.5
5
5
5
5
5
4.
5.
6.
7.
8.
Project Manager
Project Group
Steering Group
Customer
Others
Milestones
6
4.1
Remarks
6
Project Results
6
5.1
Requirements
5.1.1 Requirement Compliance Matrix
5.1.2 Requirements Compliance Summary
5.1.3 Remarks
5.2 Work Products and Deliverables
5.2.1 Remarks
6
6
7
7
7
7
Project Experiences
7
6.1
6.2
7
7
Positive Experiences
Improvement Possibilities
Financials
7
7.1
7.2
7
8
Project Cost Summary
Work per Member
Metrics
8
8.1
8.2
8
8
Milestone Metrics
Effort Metrics
Page 3
Software Merge
Final Project Report
Version:
1.0
Date: 2016-03-06
1.
Introduction
1.1
Purpose of this document
1.2
Intended Audience
Project members, steering group.
1.3
Scope
1.4
Definitions and acronyms
1.4.1
Definitions
Keyword
Plug-in
Branch
Model
System
Workspace
1.4.2
Definitions
Eclipse plugin
Branch history
The model of the system
The system we work on
Various sources and resources and work with the user
Acronyms and abbreviations
Acronym or
abbreviation
TBD
CVS
GEF
EMS
XSD
XML
GUI
SA
SB
Definitions
To be decided
Concurrent Version System
Graphical Editing Framework
Eclipse Modeling Framework
XML Schema Infoset Model
Extensible Markup Language
Graphic User Interface
Input system A
Input system B
1.5
References
[1]“Process Patterns for Software Systems In-house Integration and Merge — Experiences from Industry ” by
Rikard Land, Ivica Crnkovic, Stig Larsson http://www.idt.mdh.se/~rld/
[2] “Architectural Reuse in Software Systems In-house Integration and Merge – Experiences from Industry” by
Rikard Land, Ivica Crnkovic, Stig Larsson, Laurens Blankers http://www.idt.mdh.se/~rld/
[3] “Architectural Concerns When Selecting an In-House Integration Strategy – Experiences from Industry” by
Rikard Land, Laurens Blankers, Stig Larsson, Ivica Crnkovic http://www.idt.mdh.se/~rld/
2.
Background and Objectives
Nowadays, different software systems developed in-house are growing; companies or organization is facing
problems of new collaborations and mergers. Therefore there should be a system which could help the
developers to discuss how to merge two or more software systems. And this system, we are going to design, is
Page 4
Software Merge
Final Project Report
Version:
1.0
Date: 2016-03-06
just aiming at this problem, our software would allow developers to “combine” a new system from the previous
systems, there will be alerts and suggestions given when different modules are connected. We will give a
detailed description in this document.
The main goal of our project is to provide users a tool which could help them to merge two or more different
systems. With the help of our system, the developer will know the time effort as well as some suggestions when
he wants to make the new system or modify the old systems. Our system should provide users a friendly GUI
and easy way of using it.
The system is mainly aiming at helping user to discuss how to merge two or more software systems. It should be
able to let the user input the structures of two systems, and then let the user choose module instances from
either system, or build new ones in order to complete fit the target system. After the target system is modified,
the user could modify the two input systems to fit the target system, meanwhile, they will get different types of
alerts when they are connecting module instances from different systems.
3.
Organization
3.1
Project Manager
Mathias Alexandersson
3.2
Project Group
Mathias Alexandersson
Name
Initials
MA
Sebastien Bourgeois
Lei Liu
SB
LL
Marko Burazin
Mladen Cikara
Miroslav Lakotic
Marko Pecic
MB
MC
ML
MP
Responsibility (roles)
Project manager, Monitor progress of the project.
Project description, Acceptance testing plan
Implementing GUI
Requirements definition, Designing GUI, Backing up
CVS
Designing Plug-in
Implementing the Plug-in
Designing the Model, Backing up CVS
Implementing the Model
3.3
Steering Group
Rikard Land
3.4
Customer
Rikard Land
3.5
Others
Page 5
Software Merge
Final Project Report
4.
Version:
1.0
Date: 2016-03-06
Milestones
Milestone
Description
Id
Responsible
Dept./Initials Plan
M001
M002
M003
M004
M005
M006
M007
Project description (document)
Requirements definition (document)
Project design draft (document)
Project design (document)
Acceptance test plan (document)
Final delivery (software)
Final project report (document)
4.1
Remarks
Remark
Id
1
Actual
46
50
49
50
1
3
3
Metr. Rem.
0
+3
0
0
+2
0
0
1
Changes of the requirements delayed the final requirements definition
Project Results
5.1
Requirements
5.1.1
Requirement Compliance Matrix
SM-1
SM-2
SM-3
SM-4
SM-5
SM-6
SM-7
SM-8
SM-9
SM-10
SM-11
SM-12
SM-13
SM-14
SM-15
SM-16
SM-17
SM-18
SM-19
SM-20
SM-21
SM-22
Forecast
Week +/46
0
49
+2
49
0
50
0
1
+2
3
0
3
0
Description
5.
Id
46
47
49
50
51
3
3
Finished week
Requirement
Description
Input the systems
Select module instances from existing systems
Add a new module instance
Input time effort
Give alert
Give suggestions
Provide history operation
Save the new model
Load the model
Saving workspace
Loading workspace
Eclipse plug-in
GUI
UNDO REDO
Branch history
Compare branches
System editor
Save inputs
Add module instance
Removed module instance
Modify module instances
Module can have multiple instances
completed
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Dropped
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Dropped
Yes
Yes
Yes
Yes
Rem
1
1
Page 6
Software Merge
Final Project Report
5.1.2
Version:
1.0
Date: 2016-03-06
Requirements Compliance Summary
Total number of requirements
Number of requirements implemented
Requirements partially fulfilled
Requirements not fulfilled
Requirements dropped
5.1.3
Remarks
Remark
Id
1
5.2
22
20
0
0
2
Description
As requirements from the customer changed, and the new system should not be explicitly
modeled, no complete system could longer be saved.
Work Products and Deliverables
To
Output
SG
SG
SG,CSM
CSM
5.2.1
Project Plan
Final project design
Final presentation
Final delivery
Planned
week
Promised
week
Late
+/-
Delivered
week
46
50
3
3
46
50
3
3
0
0
0
0
46
50
3
3
Rem
Remarks
Remark
Id
6.
Project Experiences
6.1
Positive Experiences
6.2
Improvement Possibilities
7.
Financials
7.1
Project Cost Summary
Description
Page 7
Software Merge
Final Project Report
7.2
Version:
1.0
Date: 2016-03-06
Planned Cost
0
Actual Cost
0
Work per Member
Member
Mathias Alexandersson
Sebastien Bourgeois
Lei Liu
Marko Burazin
Mladen Cikara
Miroslav Lakotic
Marko Pecic
Total
8.
Metrics
8.1
Milestone Metrics
8.2
W46
19
5
23
3
3
8
10
71
W47
15
10
18
12
9
22
10
96
W48
18
20
23
9
9
18
10
107
W49
13
7
13
10
10
15
20
88
W50
11
12
11
9
8
24
20
95
W51
8
10
6
5
10
18
10
67
W52
0
0
10
5
8
24
0
47
W01
7
20
10
8
3
18
20
86
W02
10
30
6
8
7
25
20
106
W03
21
15
3
7
4
30
20
100
Completed as planned or earlier
Total
Timeliness
5
7
71%
Total
122
129
123
76
71
202
140
863
Effort Metrics
Activity
Project preparation
Project plan
Requirements analysis
definition
Eclipse preparation
System design
Implementation
Editor
Testing
Deployment
Delivery
Actual Effort
&
Planned Effort
Deviation (%)
7
14
15
7
14
7
0
0
+215
80
14
55
7
1
1
1
14
14
35
7
7
3
1
+570
0
+150
0
-600
-200
0
Effort estimation accuracy (%)
(100*(1 - abs(Actual – Planned)/Actual))
21%
Page 8