Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
3.4 Project Management:
Paul GRIFFATON in charge of OPC 5.4 has managed the project accordingly to this method. The kickoff took place in Atos Worldline at Frankfurt, two days after the beginning of my internship. Having the team members perform detailed impact analysis of different solutions have helped him to take the right decisions in order to fit the budget available. A meeting was planned every Thursday in order to make a status point on the DPs. A timesheet must be fulfilled per day (the granularity goes up to 1/8 day). At the end of the month all the timesheets are consolidated so that the Director and the project Leader can have an overview of the on-going projects.
3.5 Mission Description The OPC Team is in charge of a payment management solution, used by banks or payment processors. During the last two years, the existing platform has been redeveloped and new functionalities have been added. The contents of my job were: - Design, develop, test and document additional functions of the software ( OPC 5.4) - Supervise development in an offshore development center in Mumbai (ODC India).
3.6 Role Description The Information Analyst (IA) gives guidance on technical aspects of the SPoP project related development. He provides information and design of the solutions and guides the functional analysis to meet the defined business needs. Désiré BANSE | ESIAL Second Year
17
Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
He discusses solutions with the other members of the team is part of. The purpose of these discussions is to find the optimal solution that will fit the Business Requirements and be affordable given the resources allocated to the project realization. During the development phase the IA might instruct smaller teams of developers. Due to the special relationship between Atos Worldline and ODC India, he has to support the developers, listen to their concerns and pay attention to having them acquire and understand analysis methodology.
3.7 The development strategy Developing software requires following a process. Let’s call process, a sequence of ordered steps with the aim to develop new Software or to modify an existing one. Then, a Unified Process will be a process for supporting object oriented software lifecycle. AWL uses the Two Tracks Unified Process (2TUP). 2TUP is a process for Software development also known as Y-Process. Like in other UPs in the 2TUP the SW life cycle is spitted in cycles (i.e. iterations) in which the SW is developed incrementally. One development cycle is divided in four consecutive phases: Inception phase, Elaboration phase, Construction phase, Transition phase. Development Cycle Phases Inception Elaboration Construction Transition
Fields of knowledge Needs Acquisition Analysis Conception Implementation Test and Deployment
SPoP Project Model Phases Functional Phase
2TUP Phases Functional Technical Branch Branch
Design Phase Development Phase Handover Phase
Realization Phase
The 2TUP distinguish the technical from the functional aspects of the Software development. There is a join when realization phase is reached. The first step of the 2TUP is a Preliminary Study (Annexes 6.5). And then we have the following pattern.
18
Désiré BANSE | ESIAL Second Year
Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
The technical Specification includes the Generic Design. The technical architecture has to be compliant to the SPoP or customer Global Architecture. The next phase is the Functional Specification. In the picture, it matches Analysis. Dealing with high level concept and Business Services is mandatory. And finally the Realization Phase corresponds mainly to the Design Phase. It is focused on the detailed design, concept and several granular technical issues. It is preferable, once entered in the Design Phase to split the project into several parallel Subprojects. And every subproject could create an individual instance of the Y-model. The Y-Model refers to UML diagrams. The process has been reviewed frequently. Since the 2TUP is iterative and contains important milestones, critical decisions must be made, and key goals must be achieved at the end of each iteration. Software architectural reviews will be carried out by the Global System Analyst (GSA) (granularity, consistency regarding the SOA principles). The business functionalities will be reviewed by a Global Business Analyst: He is in charge release the Business Requirements Definition (BRD). And finally, the process is compliant to standards. A technical recommendation list stands for guidelines. The success of 2TUP is coming from these two points hereafter. Reutilization §
The upper left branch of the Y allows capitalizing the gained knowledge. It is an investment for the mid and long time, because the functional specifications are independent from the
Désiré BANSE | ESIAL Second Year
19
Offers Products and Contracts
Internship
§ § §
JUNE-SEPTEMBER 2010 OPC5.4
used technology and can be used when technologies change or when the system must be developed with another technology. Please notice that changes in legislations, practices, and/or in customer needs may lead to changes also in the functional specifications. The upper right branch of the Y allows capitalizing the technical know-how. It is an investment for the short and mid time. It allows to develop other systems (e.g. for another customer, in another field of business) using the same technology. As a matter of fact, the technical architecture can be reutilized at once for other functional components of the same system.
Iteration and Increment Iteration is a sequence of distinct activities with a basis plan and evaluation criteria, which produce a release. The iterations allow a progressive evaluation of the system and its utilization. An increment is the difference between two releases delivered at the end of two consecutives iteration.
Iteration2 may be focused on the architecture and consists in figuring out a prototype of the technical realization. Iteration3 will describe the functions and develop them according their priority. Example of effort repartition (Annexes).
20
Désiré BANSE | ESIAL Second Year
Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
4 Implementation process
Let’s focus on 2 major tasks I have achieved.
4.1 DP1 with AOI (Atos Origin India) The Design Package 1 contains technical enhancements. I was responsible for one the task. In order to explain the context, here is how is managed a product extension. An extension can be of three types - multiplicity: - 1 Card linked to 1 account : - 1 Card linked to several accounts - Several Cards linked to 1 account. The task description is hereafter. Add CardAccountRelationship entity and refactor AccountComponent and CardComponent. Both of them must have set of CardAccountRelationShip we need to have a real CardAccountRelationship entity to link card templates and account templates at product level, and card contract element and account contract element at contract level. the card (template) can be linked to one single account (template) or to several accounts (template) what is expected from AOI team: - impact analysis (propose an Excel spreadsheet with the list of places to change) - validation of this impact analysis together with Desiré (+Alex and me-Paul GRIFFATON) - actions in Eclipse (be careful to plan it desynchronized from other refactoring initiative to lower down the complexity and regressions) A preliminary study had me understand the way the relationship was managed. The management of the Relationship between Accounts and Cards was not really suitable. For instance the storage of the entities depends on the multiplicity. The purpose of this study was to provide a high level view of the existing management of the product extension. In order to explain, the database mapping will be also shown. Then a list of changes in order to perform the business requirement has been provided.
4.1.1 DESIGN With the needs expressed and clarified, it is time to go into Design Phase accordingly to Technical Architecture chosen for SPoP Projects. I created a JIRA issue in order to gather all information related to this task. JIRA is an issue tracking product. It is used for bug tracking, issue tracking and project management. Impact Analysis It is necessary then to take a closer look at the impact of the modifications I am proposing. The modifications are Business Layer. I added a new entity, re-organized the relationships between CardComponent and AccountComponent. I asked AOI Team to provide an impact analysis (an excel spread sheet listing places in the Désiré BANSE | ESIAL Second Year
21
Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
code requiring a change). I validated the impact Analysis with Paul, the Project leader and Alexander his deputy. Detailed Design The next step is a detailed design of the functionalities that will be implemented. Here we are dealing with modifications. I produced an excel sheet showing how the attributes moved from CardComponent to CardAccountRelationship must be retrieved. But the main point is that I did a classification of the changes required using a complexity criteria. Here is an extract of the implementation guidelines: Proj ect
class
Implémentation Nothing to change. Calling AccountContractElement
src.main.java.net.atos.wlp.opc.contract.CardAccountRelation.j See ava Using_Contract_Relationship src.main.java.net.atos.wlp.opc.contract.impl.ContractManager See Impl.java Using_Contract_Relationship There will be two steps: - first remove the CardComponent and mark as deprecated the getter (setter?) - then retrieve the CardComponents for a given AccountComponent(AC) src.main.java.net.atos.wlp.opc.product.AccountComponent.jav by the CardAccountRelationship a linked to this AC There will be two steps: - first remove the AccountComponent and mark as deprecated the getter (setter?) - Then retrieve the AccountComponents for a given CardComponent (CC) by the CardAccountRelationship linked to this CC. Reimplement some methods such as initializeRelationshipsFromAttac hedAccounts () ... src.main.java.net.atos.wlp.opc.product.CardComponent.java src.main.java.net.atos.wlp.opc.product.CardAccountRelationsh need refactoring, check the ip.java constructors … wlpAll the code this class will be opcrefactored. Refer to JIRA OPCcore src.main.java.net.atos.wlp.opc.util.ProductHelper.java 608
Désiré BANSE | ESIAL Second Year
22
Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
src.test.java.net.atos.wlp.opc.contract.CardAccountRelationTe See Using_Contract_Relationship st.java Just get src.test.java.net.atos.wlp.opc.product.CardAccountRelationshi CardAccountRelationship pTest.java implemented src.test.java.net.atos.wlp.opc.product.CardComponentTest.jav Just get CardComponent a implemented Get the classes above src.test.java.net.atos.wlp.opc.productextension.ProductExtensi implemented, and do extra onManagerTestCase.java tests
Then I scheduled the changes performing. I instructed ODC Team to deliver software taking into account half of the changes required by the end of July (I launched the task around mid-July). I pointed out critical points to be careful with and split the changes commits on CSV server. Some of them were: 1) Migration scripts happen to be important in order to get the information being stored in the old data structure and inject them into the new one. Let’s take for example an AccountComponent which contains some criteria and priority values; we need to move these values into the new CardAccountRelationship entity. 2) Some test schemes have to be planned in order to test the creation of several productExtensions and contractElements a. Creating with all the multiplicities through the GUI b. Checking if the data are being correctly stored in database c. Trying to retrieve them in the GUI Another point is to set the name of the entities. - In product level we will talk about CardAccountComponentRelationship - In contract level we will talk about CardAccountElementRelationship This last point is not time consuming since it can be done within Eclipse IDE but using the refactoring tool and setting the right parameters. But it’s worth paying attention to that. Time evaluation: I then asked a time evaluation in order to implement the task. Paul taught me many points of Program management. He provided me tips, and reviewed sometimes my validation of AOI documents release. I did also a time evaluation on my side. And then I provided the two estimations to Paul who validated the AOI team time estimation.
4.1.2 DEVELOPMENT AND SUPPORT
23
I then launched the development phase in India. The support consisted in resolving issues that happened and providing clarifications. It also included paying attention to other tasks implementation impacts. I used to work on Design phase of other DP.
Désiré BANSE | ESIAL Second Year
Offers Products and Contracts
Internship
JUNE-SEPTEMBER 2010 OPC5.4
The AOI team did many inputs in the JIRA issue I created for this task.
4.1.3 REVIEW AND TESTS Since I asked AOI Team to finish and commit the changes regarding the product level, I was able to review their work at the middle of the duration planned. Review the Code, the Data Layer (Database) and the GUI. Extract of the review: Taking the document ImpactAnalysis_OPC5.4_DP1_card_account_rel_changes_v5.xls as reference, I invite you to refer to the excelsheet you will find on JIRA OPC-609. I am very OK with the changes on the product level. I’m trying to get the application in my laptop in order to perform basic tests. There will be of course a set of tests performed by the team responsible for that. Can you: - Create a product? -
Create a productExtension ?
-
Add a productExtension to a product?
If these things are ok, the goal of this first pre-release is reached. I still working on getting the application running. Remarks: … There are 2 types of tests I used in general. JUnits and tests on GUI. I asked AOI Team to perform the entire JUnits test written for session beans, Entity managers … I defined some tests schemes and forwarded them to the Test Team. They did and sent me back the results. I contacted the team who has worked on the development phase, and asked them to take a look at the error logs.
4.1.4 VALIDATION Extract of my validation for DP1 CardAccountRelationship management: The code reviewing is definitely OK for me. I’m still unable to run the application on my laptop but it is due to local misconfiguration. I will rely on the test team. Here are some points that may impact my validation. Tests on all the topics of DP1 will start by the 12th of this month, and unless it happens to raise some problems, everything is OK. 2) There are some topics from DP4 (performance and tuning). I will discuss will Alexander and track any changes it can bring on CardAccountRelationshipManagement. The guidelines are not yet released. So far it will deal with – talking about CardAccountRelationship : a. The way the queries are built when retrieving data through more than 2 tables on the DB. 3) There will be some major changes on Contracts in order to implement (and enable)
1)
Désiré BANSE | ESIAL Second Year
24
