To Act of Engagement
For the provision of services on IT Tool development
Technical Terms of reference
1. Introduction: Background to the invitation to tender
The Council of Europe (CoE) is currently implementing a project on “Strengthening the Capacity of Bar Associations and Lawyers on European Human Rights Standards” (SCoBAL), whose specific objective is to strengthen the capacities of Turkish bar associations and lawyers in the implementation of European human rights standards.
The Project estimates to achieve several results, amongst which
1. fostered communication and coordination between the human rights centres, the bar associations and the Union of Turkish Bar Associations through regular meetings and a web-based common communication network.
In the context of this expected result, a web-based IT tool will be developed to serve as a communication network and database for alleged human rights violations at local level. The IT tool will be a web-based communication network between the Union of Turkish Bar Associations (UTBA) and the Human Rights Centres (HRC) of 7 pilot bar associations taking part in the Project. This IT tool in Turkish, will facilitate the communication among the lawyers working in HRCs, serve as a reporting facility on alleged human rights violations to the UTBA, be a repository of data and will create statistics related to alleged human rights violations.
The pilot bar associations and the UTBA will have access to the database and the communication network. At the end of the Project, communication network will rest available for users on the main website of the UTBA. The database will help to identify risk areas in the field of human rights at the national level through recording of particular repetitive alleged violations reported by the HRCs of the bar associations.
The web-based IT tool shall serve as a standardised tool with templates of reports, guides for users and information on the amount of applications brought to the HRCs, reports produced by the HRCs, actions taken in relation to the applications and instances of alleged human rights violations and the results of such actions when available.
The web-based IT tool will be developed in line with the agreed suggestions on data collection, maintenance and analysis methodology, reporting templates, reach out strategies, examples of good practices, in cooperation and under supervision of the UTBA.
2 Contract Scope
The scope of the contract is software development services:
· Development of the web-based IT Tool,
· Basic Maintenance of the developed IT Tool during the warranty period and its update on the basis of feedbacks received from the users during the warranty period; and
· Handover of the developed IT Tool to the UTBA.
The following sections describe the terms of reference for the contract.
3 Work streams
Three work streams ((1) Development of the web-based IT Tool, (2) Maintenance of the IT Tool during the Warranty Period and its update on the basis of feedbacks received from the users during that period; and (3) Handover of the IT Tool to UTBA) are defined and are described in the following sub-sections.
3.1 General concepts
A. Product phases: The following list describes the high-level phases that the services shall include:
· Initiation and specification phase (on-site and off-site work):
o Contract initiation;
o Manage solution requirements lifecycle;
o Technical design;
· Implementation and test phase(mainly off-site activities):
o Implementation and test;
o Early validation feedback;
· Release phase: (mainly off-site activities):
o Release package;
o Acceptance of deliverables;
o Infrastructure change management;
o System integration test;
o Acceptance test;
o Deployment to production;
· Handover phase: (mainly off-site activities).
B. Stakeholder requirements: A document prepared by the UTBA as a part of the technical terms of reference for the Contract, which describes the needs (business requirements) of stakeholders that must be met in order to achieve the business goals. The stakeholder requirements can be found in Section “Technical Annex A - Stakeholder Requirements”.
C. High-level design document: A document prepared by the UTBA as a part of the technical terms of reference for the Contract, which provides an overview of the solution design and its key requirements, quality criteria, architectural considerations, dependencies and impact on existing and planned future systems. This overview includes high-level architecture diagrams depicting the components, interfaces and infrastructure components that need to be further specified or developed; and to ensure that the solution design will be compatible with the UTBA’s overall enterprise IT architecture. The high-level design document can be found in Section “Technical Annex B - High Level Design Document””.
D. Contract initiation: The Contract is expected to normally start with a phase aimed at development and agreement on a detailed plan for the Contractor to deliver the service, including an on-site kick-off meeting where key concerns are discussed as input to the planning.
E. Prototyping: The Contractor may be requested to prepare one prototype to allow potential users to evaluate the practicality of the eventual product by actually trying it out, rather than by being based on descriptions. After preliminary requirements have been defined, a simple working model of the system is constructed to show the users visually what their requirements may look like when they are implemented into a finished system.
F. Solution requirements: Detailed software requirements prepared by the Contractor in close collaboration with the UTBA, based on the stakeholder requirements (as set in Technical Annex A) and high-level design requirements (as set in Technical Annex B). The requirements shall describe the capabilities and qualities of the solution that meets the stakeholder requirements. The requirements shall include functional requirements and non-functional requirements (quality attributes). The requirements shall be reviewed and accepted by the UTBA before implementation can commence. The Contractor is expected to apply the MoSCoW method or a similar method to be agreed with the UTBA for all prioritisation during requirements analysis stages.
G. Test documentation: Detailed test plan and test case specification shall be prepared by the Contractor based on the Solution requirements. It shall be reviewed and accepted by the UTBA before implementation can commence. Refer to Section “4.3. Software Testing ” for more details related to software testing.
H. Technical design: Technical design prepared by the Contractor shall be based on the High-level design document and the Solution requirements. The technical design describes desired features and operations in detail, including screen layouts, business rules, process diagrams and other related documentation. The Technical Documentation deliverable will include textual description of the application design supported by diagrams as needed, such as Application Architecture, Application design, External Interface Specification. The Contractor shall create the Technical Design Document within three months after the signature of the order form and submit it to the UTBA. This part must be approved by the UTBA prior to implementation.
I. Environments: The following technical environments are expected:
· Environments under the Contractor’s responsibility:
o Development environment(s) – Used for implementation activities;
o Test environment(s) – Used for system testing activities;
· Environments under UTBA’s responsibility:
o Infrastructure test environment(s) – Used for system integration testing activities;
o UAT environment(s) – Used for acceptance testing;
o Production environment(s) – Production environment.
Refer to Section “4.3 Software Testing” for more information.
J. Implementation and test: The requirements and design to be translated into source code, configuration files, deployment script(s), migration tools, user interface and verified by successfully executing the defined test case specification. This activity shall include:
· Maintaining the technical development and test environments as needed;
· Translation of the defined requirements into source code;
· Maintaining the system configuration, deployment and migration scripts;
· Unit testing the source code;
· Code review (based on predefined rules and checklists);
· Producing technical documentation as well as end-user guide;
· Testing (refer to Section “4.3. Software Testing” for more information).
K. Early Validation Feedback: The Contractor should regularly organise demonstration/validation meetings where the UTBA is invited to validate the implementation and provide early feedback. These feedback provision meetings may be organised via email, on-site workshop or teleconference.
L. Release process: When the release has been fulfilled and released product verified (taking into account early validation feedback from the UTBA), the release is packaged, deployed to a test environment, and is re-verified by the Contractor before the release package is communicated to the UTBA.
M. Acceptance test (incl. UAT): The UTBA will perform acceptance testing in a production-like environment. The UTBA will document the results based on which the release may be either accepted, postponed or rejected (if any defects were identified). Lower severity defects may be accepted by the UTBA (to be fixed during the warranty period) and the release is considered ready to be deployed for production. However, if the defect(s) are of higher severity, the release may require an update and will trigger a repackage and resubmission of the Release Package. Refer to Section “4.3 Software Testing ” for more information.
N. Deployment to production: The UTBA will deploy the IT Tool to the Production environment and ensure that the deployment has been successful. The Contractor is expected to provide support and give input as needed. The deployment includes the execution of any defined smoke tests, in order to verify that the deployment was successful.
O. Help Desk and Support Line: This activity covers the expected involvement in the ticket (incident, request and problem) management processes. The Contractor will provide help desk and support line services and is expected to work in close and effective collaboration with the UTBA. The Contractor has to manage all tickets assigned for support. The Contractor is expected to provide a single point of contact for the Help Desk and support services and can be subject to Service Level Agreement (SLA) (see Section “4.7 Service Level Agreement (SLA)” for more information).
P. Corrective maintenance: Defects that are identified in the production environment, as a part of support line or differently, will be investigated and fixed by the Contractor. The corrective maintenance is subject to the Service Level Agreement (SLA) (see Section “4.7 Service Level Agreement (SLA)” for more information), based on the severity of the defect and the business impact priority of the product.
Q. Warranty period: Following the deployment of the release to the production environment, the Contractor will provide Basic Maintenance services (help desk, support line and corrective maintenance), at no cost for the UTBA for a duration of at least three calendar months. This period may increase up to 11 months (at least 31 March 2021 for warranty period of three months, at most 30 November 2021 for warranty period of eleven months.).
3.2 Work stream: Development of the web-based IT Tool
A. Contract initiation: The Contractor shall create a detailed Project Management Plan (PMP) to develop and deliver the solution by liaising with the UTBA for inputs. This normally includes an on-site kick-off meeting where key concerns are discussed as inputs to the planning. The PMP must be accepted by the UTBA.
· Project Management Plan (PMP)
B. Manage solution requirements lifecycle: The Contractor is responsible to elicit solution requirements for the IT Tool. This normally includes one or more on-site workshops with stakeholders identified in the PMP. The Contractor shall analyse and document requirements and keep them throughout the life cycle and ensure their traceability. The Contractor shall develop test documentation based on the requirements.
· Software Requirement Specification (SRS)
· Test Documentation (TS)
C. Technical design: The Contractor is responsible to establish a technical design for the IT Tool, in close collaboration with stakeholders identified in the PMP.
· Technical Documentation (TD)
D. Validate sub-deliverables: The UTBA reviews and provides feedback on the SRS, TS and TD deliverables as described in Section “5 Deliverables”. The Contractor updates the deliverables, as needed, based on the UTBA’s feedbacks.
E. Implementation and test: The Contractor builds and tests the IT Tool.
· Source Code (SC)
· User Guides (UG)
F. Release Process: The Contractor packages and tests the release.
· Release Package (RP)
· Release QA Report (RQAR)
G. Acceptance of deliverables: The UTBA reviews and accepts the deliverables produced, as described in Section “4.5 Acceptance Mechanism”.
The UTBA will verify compliance with established guidelines, standards and policies.
The Contractor updates the deliverables, as needed, based on the UTBA’s feedbacks.
H. Acceptance test (including User Acceptance Testing (UAT)): The UTBA verifies and validates the release and decides whether or not to deploy the release to the production environment. The Contractor provides support, as needed.
I. Deployment to production: The Contractor supports the UTBA in deploying the release to the production environment.
· Release deployed to the production environment
The (i) I-Deployment to Production and (ii) G-Acceptance of Deliverables are normally used as criteria for the formal acceptance of the IT Tool unless otherwise stipulated in the final signed contract.
J. Warranty period: The warranty period shall begin after all deliverables have been accepted by the UTBA. For the IT Tool, the standard warranty period will be at least three calendar months (i.e. three months following the day of deployment of the IT Tool) during which the Contractor must provide Basic Maintenance services (help desk, support line and corrective maintenance, see Section “3.3 Work stream: Maintenance of the IT Tool during the Warranty Period”) without additional cost for the UTBA. This period may increase up to 11 months (at least 31 March 2021 for warranty period of three months, at most 30 November 2021 for warranty period of eleven months.).
K. Handover: At the end of the Warranty period, the UTBA will order a handover where the Contractor shall to transfer the product to the UTBA, as described in Section “3.4 Work stream: Handover of the IT Tool to UTBA”.
3.3 Work stream: Maintenance of the IT Tool during the Warranty Period
The Basic Maintenance work stream is used to ensure that the Product in its entirety and its parts are operational and function as intended over time. The sub-stream can be broken down in two parts, provision of respective services related to each of these parts throughout the whole duration of the Warranty period shall be ensured by the Contractor:
· Help Desk and Support Line: Providing support to the UTBA in regard to incidents and requests as well as problem management.
· Corrective maintenance: As a defect or required correction is identified/reported, update the product solution and/or the related documentation to fix the problem and release the fix to the production environment.
The following activities are expected:
A. Start of Warranty Period: The Contractor is responsible to create a detailed Maintenance Plan (MP) to deliver the scope of the Contract. The MP must be accepted by the UTBA.
· Maintenance Plan (MP)
B. Service review: A Monthly Service Report is produced by the Contractor and submitted to the UTBA during the warranty period.
· Monthly Service Reports (MSR)
C. Support process: The support service process shall be triggered when the UTBA assigns a ticket to the Contractor for support. This may be in the form of an incident, a request or a problem.
The following activities are expected:
D. Ticket triage: The Contractor’s dispatcher (i.e. single point of contact) reviews and triages all tickets assigned for support, the following triage-scenarios are common:
1. Incorrectly assigned - The ticket refers to a product or IT Service not under the Contractor’s responsibility.
2. Defect - A defect is reported (typically in the form of an incident or a problem) with regard to the IT Tool.
3. Requirement - A new requirement (or functional change request) is communicated (typically in the form of a request).
4. User question - A user has question(s) about the usage of the product or experienced problems due to insufficient understanding of the product or its functioning.
5. Troubleshoot - An unplanned interruption of the IT Tool or a reduction in the quality of the product has been reported, but the cause or how to resolve it is unclear.
The Contractor investigates the ticket in terms of:
i. Is the ticket referring to the IT Tool under the Contractor’s responsibility?
ii. What is the ticket priority?
iii. Depending on the ticket priority, what are response and resolution target time?
iv. Is the description of the ticket sufficiently described?
v. Is there a known resolution/work around?
vi. Is the issue described caused by a defect in the code?
If needed the dispatcher will assign the ticket to the service delivery team for its follow up.
E. Troubleshoot: In case a ticket refers to scenario 5, the Contractor and the UTBA collaborates to troubleshoot and identify the cause.
F. Assess of requirement: In case of scenario 3, the Contractor assigns the ticket to the UTBA for assessment. If the UTBA agrees that the ticket refers to a request they will follow up accordingly, i.e. the process ends. In case the parties agree that the issue is in fact a defect, the Contractor will follow up as described below. In case of non-agreement, the UTBA reserves the right to decide.
G. Resolve/Provide feedback/Reassign ticket: In case the ticket refers to scenario 1 or 4, the Contractor updates the ticket with information as appropriate (e.g. resolution steps, feedback, workaround steps, or reason for reassignment).
· Ticket updated
H. Log and estimate: In case the ticket is suspected to be caused by a defect (scenario 2), the Contractor updates the ticket accordingly and logs a new defect work item for follow-up. The Contractor estimates the defect and proposes a severity. Severity is defined as the degree of impact that a defect has on the development or operation of a component or system:
The defect has a major impact on the correct behaviour of critical functionality or critical data. Prevents execution of a business process/function and there is no workaround.
The defect has a major impact on the correct behaviour of major functionality or major data. Requires considerable extra work/time to execute process/function or the results are not adequate.
The defect has an impact on the correct behaviour of minor functionality or noncritical data. It has a work-around. Requires extra work/time that can be coped with and doesn’t significantly impact results.
The defect does not affect functionality or data. It may not even need a workaround. It does not impact productivity or efficiency.
The defect estimation takes into account both the estimated time required to fix the defect and its complexity in regard to testing:
Implementation: Trivial or low effort fix that can typically be implemented (excl. testing and releasing) in less than one hour.
Affected area(s): One specific area and the fix is not expected to have any side effects.
Testing: The verification of the bug is straight forward.
Implementation: Medium effort that can typically be implemented (excl. testing and releasing) in less than one day.
Cause: May not be known and some time will be needed for investigation/ troubleshooting.
Affected area(s): One or more areas and the fix can have side effects in other parts of the application/product, or in other systems that the application/product integrates with.
Testing: The verification of the bug typically needs regression testing in the area(s) affected.
Implementation: Large effort and may require significant refactoring of the code base and will typically need several days for implementation (excl. testing and releasing).
Cause: May not be known and some time will be needed for investigation / troubleshooting.
Affected area(s): Typically, more than one area and the fix can have side effects in other parts of the application/product, or in other systems that the application/product integrates with.
Testing: The verification of the bug typically needs regression testing of all areas affected / whole application/product component.
· Defect work item (WI)
· Ticket updated
I. Validate defect: The UTBA validates the defect work item and confirms the severity and the estimation.
In case the UTBA does not agree with the Contractor’s proposal of severity and/or estimation, this will be raised, without delay, for discussion and alignment. If the parties are not be able to agree on the severity and estimation bilaterally, on the operational level, then the UTBA’s position will prevail for the purpose of not blocking the continued process.
· Defect work item (WI) updated
J. Implementation and test: The Contractor fixes the defect and tests the software (product). The Test Documentation is updated accordingly, e.g. by amending the regression test cases.
· Source Code (SC)
· Test Documentation (TS)
K. Package release: The Contractor packages and tests the release.
· Release Package (RP)
· Release QA Report (RQAR)
· Ticket updated
L. Acceptance of deliverables: The UTBA reviews and accepts the deliverables produced as described in Section “4.5 Acceptance Mechanism”. The UTBA will verify compliance with established guidelines, standards and policies. The Contractor updates the deliverables, as needed, based on the UTBA’s feedback.
M. Deployment to production: The Contractor deploys the release to the production environment.
· Release deployed to the production environment
N. Root cause analysis: The Contractor is expected to perform a root cause analysis for critical severity defects and include the output of the analysis in the next Monthly Service Report.
· Root cause analysis report
3.4 Work stream: Handover of the IT Tool to UTBA
The Handover work stream is used to transfer the responsibility for a product from the Contractor (the Handover party) to the final beneficiary (UTBA), or another maintenance contractor or third-party with the full written consent of the UTBA (the Takeover party). The following scenarios apply:
A. Handover initiation: The Contractor is responsible to take part in developing a detailed Project Handover Plan (PHP), under the responsibility of the Takeover party, to deliver the handover. This normally includes an on-site kick-off meeting where key concerns are discussed as inputs to the planning. The PHP shall be accepted by the UTBA.
The Contractor identifies, and includes in the PHP, all information required to allow a smooth and complete transfer of knowledge from the Handover party to the Takeover party.
All organisational aspects should be included in the PHP.
· Project Handover Plan (PHP)
B. Handover execution: The handover is executed as defined in the PHP.
The Contractor collects all relevant information and prepares relevant training material.
The UTBA will review and accept these deliverables as described in Section “4.5 Acceptance Mechanism”. The Contractor is responsible to organise and facilitate all the necessary training activities. All computer hardware, software, licences and other capital equipment, etc. which have been paid for under this Contract shall be included in the handover. This also applies to all information, documentation and or other artefacts produced as part of the Contract execution, unless otherwise agreed with the UTBA.
C. Handover closure: The Contractor closes the project by producing a Handover Report summarising the activities performed, as well as lessons learned and recommended improvement actions for the upcoming transfers. The UTBA will review and accept the deliverable as described in Section “4.5 Acceptance Mechanism”.
· Handover Report (HR)
The acceptance of the Handover Report is used as criteria for the formal acceptance of the handover, which (if applicable) is a ground for the final payment.
The objectives for the Handover work stream are:
i. To transfer the responsibility for Basic Maintenance and Further Development to the UTBA or designated Takeover party;
ii. The Handover party enables the UTBA or the designated Takeover party to build the capability to deliver services with high service quality;
iii. The UTBA or the designated Takeover party builds the capability to deliver services with high service quality;
iv. The transfer is executed cost-efficiently, and;
v. The quality of services is well managed during and after the transfer. The impact on users is minimized.
4 General Conditions
This section describes general conditions to the Contract.
4.1 Technical landscape
The UTBA technical landscape is mainly based on Microsoft technologies (e.g. Windows Server, Active Directory, SharePoint, SQL Server, Exchange, and Office). Most systems are hosted on premise, but cloud-based hosting is increasingly used.
4.2 Tools and technical infrastructure
The provision, maintenance and management of the technical infrastructure (including all licence costs and fees) required for the Contractor's internal needs, within the scope of this Contract, are under the responsibility of the Contractor, who is expected to work in close collaboration with the UTBA in order to ensure “production like” development and test environments.
The Contractor is expected to use the following tools:
Responsibility and Ownership
Source Control Versioning and Work Item Management (SCV/WIM)
Used to manage source code and work items (internal or shared with the UTBA), e.g. Release Plans, Requirements, Defects, Tasks, Release Packages, etc. The UTBA is expected to have full visibility on the source control, and should have full contributor rights (view, create, update, delete) on work items. The UTBA reserves the right to request and receive additional rights as needed.
Note: The UTBA is currently using Team Foundation Server and has a preference to keep using this product, yet alternative products can be proposed.
Help Desk Infrastructure
Used to manage tickets from incidents, requests and problems.
It is expected that during the system integration and acceptance testing the IT Quality Assurance, the UTBA can register defects in the SCV/WIM tool.
4.3 Software Testing
Software testing is defined as the process consisting of all lifecycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related technical environment to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects. It also includes to verify that a product continues to work when the technical environment is changed (patches, upgrades etc.).
The UTBA’s objectives of software testing are:
· Support the UTBA’s mission by ensuring that the delivered product fulfils the intention and expectations;
· Identify defects that can affect stakeholders/user’s satisfaction or jeopardize the security of the infrastructure, and to produce enough information about these defects so they can be fixed prior to release, resulting in:
o Good stakeholder and user satisfaction;
o Prevention of critical and high severity defects in compliance with the IT Product Quality acceptance criteria;
o Reduction of the defects with medium and low severity;
o Cost reduction on corrective maintenance;
· Identify issues that can affect the technical quality of the products (e.g. maintainability, integration, compliance with standards, security, etc.);
In regard to IT Tool development, the UTBA’s product software test methodology is based on the following framework:
· Test policy (why we test): One-page document provided by the UTBA describing e.g. the objectives and definition listed above.
· Test strategy (how we test): Document provided by the UTBA describing the test process including test levels and test types, roles and responsibilities, etc. The Contractor is expected to comply with the UTBA’s established test strategies.
· Test documentation (what we test): Produced by the Contractor and defines the test plan, test cases and test data to be used.
· Release QA Report (what was tested): Summary produced by the Contractor describing, review results, test cycles and results, test and requirements coverage, status on defects and their severity etc.
With regards to software testing, every release under the execution of the service, is subject to a test and/or quality assurance discipline under the responsibility of the Contractor. Unless the UTBA informs otherwise, the default position is that the Contractor has full responsibility to assure the necessary quality such that the product release is in a fit state to be released into the production environment. It is the Contractor's responsibility to ensure that they acquire sufficient business domain knowledge and sufficient testing capacity in their team such that they can independently from the UTBA, perform all the necessary testing (functional and non-functional), including software upgrade and data migration testing.
The UTBA’s test involvement would typically be limited to:
· Providing and maintaining the test policy and test strategy;
· Review and acceptance of the test documentation;
· Early validation feedback;
· System integration testing, and;
· Acceptance testing prior to go-live where the expectation is that no significant quality issues are uncovered.
4.4 Methodology and Standards
The Contractor is expected to present certificates, (e.g. software process development, quality management, IT security, business analysis).
The methodology used for software development and maintenance must support frequent releases, e.g. by an iterative or agile approach.
Alignment with the UTBA’s internal processes, interfaces, and standards will be a topic in the initial kick-off meeting. The UTBA will provide the Contractor with relevant technical standards, guidelines and policies in order to ensure that deliverables comply with the UTBA’s practice and relevant regulations, while also ensuring that they are built in a consistent manner.
4.5 Acceptance Mechanism
The review and acceptance process of deliverables will follow the review cycle as below:
1. The Contractor submits the deliverable for review to the UTBA.
2. The UTBA submits their consolidated feedback (no later than five (5) working days).
Note: the UTBA reserves the right to reject the deliverable in which case the approval process is restarted.
3. The Contractor has followed up the feedback received and submits a final version for acceptance (no later than five (5) working days).
4. The Council, upon consultation with the UTBA, accepts or rejects the final version (no later than five (5) working days). In case of rejection, The Contractor shall reopen consideration of feedbacks, make amendment of the deliverable and resubmit a final version for acceptance.
4.6 Service Delivery Team and Profiles
The Contractor should present its proposed Service Delivery Team and their profiles along with the tender documents, the following conditions applies:
i. The proposed team should difference between (i) the “core service delivery team” and (ii) “extended team(s)” including additional resources proposed to be used to balance peak demand, as needed. The core service delivery team is expected to be focused at the UTBA services and to remain stable over time.
ii. The core service delivery team vs. extended team(s) composition (i.e. which profiles and proportion between profiles) should be described in the offer presented to the UTBA. The core service delivery team shall typically comprise Contractor's staff, who has or is intended to acquire specific knowledge of the UTBA and the IT Tool to be developed.
iii. The tenderer is requested to provide in their offer the list of names and CVs of those resources that are to be considered as members of the core service delivery team for the implementation of the service.
iv. Turnover of the core service delivery team will be subject to SLA (Please see Section “4.7 Service Level Agreement (SLA)”).
v. The UTBA expects direct communication access to members of the core service delivery team. The tenderer is expected to propose such a communication mechanism in the tender offer.
Although the Contractor’s role names may differ, the service delivery team is expected to include the following profiles/competences:
· Project Manager
· Business Analyst
· System Analyst
· Web / UX Designer
· Application Tester
· System Administrator
4.7 Service Level Agreement (SLA)
A document of maximum of 20 pages (A4 format, font Calibri size 11) presenting the Contractor’s proposal for a Service Level Agreement, and related topics such as governance, quality management and reporting to be used during the implementation of the project will be presented along with the tender documentation.
The Service Level Agreement (SLA) will be part of the Contract and will become applicable once the Contract has been signed up to its contractual end.
4.8 IT and information security management
The Contractor shall have a defined and documented Information Security Management System (ISMS) including an information security policy and procedures in place, which shall be described in the tenderer’s offer and communicated to relevant contractor personnel.
The UTBA reserves the right to require any person involved with the provision of the services under a given project to attend security briefings, awareness or training given by the UTBA.
For access to the UTBA’s IT systems, the Contractor’s personnel must be controlled in line with the UTBA rules:
i. Each member of the service delivery team must read, sign and comply with the UTBA’s acceptable ICT use policy;
ii. Each member of the service delivery team that will provide development services to the UTBA will sign a Declaration on Confidentiality and Security Requirements.
The Contractor is obliged to provide signed declarations for all members of the service delivery team.
The Contractor is obliged to provide signed declarations for all members of the service delivery team.
Connection to the UTBA’s network (regardless of hosted by third party) shall be done only from a controlled environment, which is secured against intrusion and protected by antivirus software. The Contractor shall protect Information Processing Facilities against external and environmental threats and hazards, including power/cabling failures and other disruptions caused by failures in supporting utilities. This includes physical perimeter and access protection.
The UTBA has the right to monitor and examine any information stored on its information processing systems or communicated over its network or equipment. For several systems auditing is implemented to audit trail system changes and Internet browsing.
The Contractor shall inform the UTBA without delay and return any UTBA equipment when no longer needed. Any cost for returning the equipment will be carried by the Contractor. The Contractor is responsible for to physically protect and secure the UTBA equipment.
The Contractor shall have a defined and documented access control policy for facilities, sites, network, system, application and information/data access (including physical, logical and remote access controls), an authorization process for user access and privileges, procedures for revoking access rights and an acceptable use of access privileges for the Contractor Personnel in place.
In order for the Contractor to access and use the UTBA / Infrastructure Contractor tools and network, a site-to-site VPN connection will be established. This type of connection is configured when there is a requirement to access resources at a partner office. Here the connection is built up between the UTBA and the Contractor VPN device with access rules permitting access to the resources behind these VPN terminators. The site-to-site VPN connection at UTBA should be authenticated using a pre-shared key and with IKEv2.
The UTBA will provide visitors and temporary on-site consultants with a security badge for access to select areas at the UTBA premises. Everyone must visibly wear his/her identification card in the UTBA building.
The Contractor has the obligation to report all security incidents, software malfunctions, security weaknesses or threats to systems or services that their personnel notice or is made aware of to the UTBA.
The Contractor shall have documented processes and routines for handling risks within its operations.
The following deliverables are expected, but not limited to:
Deliverables during Development of the IT Tool
Project Management Plan (PMP)
A detailed Project Management Plan for how the services will be delivered, aligned with the UTBA Project Management Plan.
Business Analysis and Functional Requirements Document (BAFRD)
An analysis of the identified business processes, logic, workflows and objectives, forming the functional requirements defining what the system would do and how it will function to achieve these objectives.
Software Requirement Specification and Design Document (SRS-DD)
A formal description of the product including an up to date list of solution requirements, architecture, data model and functionality.
Test Documentation (TS)
A description of the test plan (what will be tested), test cases (how will it be tested) and test data (with what input will it be tested) covering and linking to the enumerated requirements in the SRS.
Technical Documentation (TD)
A description of the technical (low level) design of the product, including a mix between textual technical analysis (indicatively including UML diagrams) and documentation as generated from the source code.
Note: The technical analysis should be presented to the UTBA prior to implementation, while the generated output will be complemented later.
Source Code (SC)
Source code includes all aspects of making a software work including programming language code, configuration files, deployment script(s), migration tools, user interface, etc.
User Guides (UG)
Documentation targeted to the user of the developed IT Tool on how to use it and operate it.
Release Package (RP)
A Release Package can be categorised into:
· New Software release: First major version of a software;
· Maintenance release: A software increment intended to update an existing IT Product;
· Hotfix release: A hotfix is used for urgent changes (e.g. a critical defect fix) in the production environment. It is typically limited to a few files that the fix depends on;
· Patch: A patch is a change in the production that is not covered by a release, e.g. a script to correct production data.
A New Software and Maintenance Release Package includes everything needed to deploy and operate the IT Product, as well as miscellaneous information to understand the release. The Release Package typically includes:
· Configuration, deployment and migration tools;
· Software Requirements Specification;
· Test Documentation;
· Technical Documentation;
· Release QA Report;
· User Guides.
For Hotfix and Patch packages, only the necessary binaries and / or source code and / or scripts will be included.
The deployment mechanism of the release must comply with the UTBA deployment script guideline, unless otherwise agreed with the UTBA.
Release QA Report (RQAR)
A report summarising quality assurance activities and their results, which facilitates the assessment of release quality. The report includes, but not limited to: Review results, test cycles and results, test and requirements coverage, status on defects and their severity etc.
Release deployed to the production environment
A Release Package has been successfully deployed by the Infrastructure Contractor with support by the Contractor. The deployment process includes running a set of defined smoke tests to verify that the deployment was successful.
Maintenance Plan (MP)
A detailed plan for how the product maintenance services will be delivered.
Deliverables during Maintenance of the IT Tool
Service Desk Ticket (Ticket)
The UTBA will assign service desk tickets (e.g. incidents and requests) to the Contractor for follow up. Such tickets shall be maintained up to date including correct and appropriate documentation.
SCV/WIM Work Item (e.g. Defect Work Item)
The day to day interaction between the UTBA and the Contractor will be based on SCV/WIM work items (e.g. requirements and defects). In addition to the Contractor, work items may be created by the UTBA.
Monthly Service Report (MSR)
A monthly report document giving an overview of the help desk and maintenance services provided for the previous period, which will be presented in a meeting to management bodies. The template will be agreed with the UTBA.
The Monthly Service Report will cover (at least):
· Executive Summary
· Tickets and Work Items covered during the period
Deliverables during Handover of the IT Tool to UTBA
Project Handover Plan (PHP)
A detailed Project Handover Plan to be developed by the Contractor with all information required to allow a smooth and complete transfer of knowledge from the Handover party to the Takeover party with all organisational aspects.
Handover Report (HR)
A report summarising the Handover activities including concerns such as handover summary, list of deliverables, lessons learned, and post-handover actions.
General / Project Management Deliverables
Meeting agenda and presentation (MAP)
A slide set covering topics to be discussed, prepared and circulated prior to the meeting.
Meeting minutes (MM)
A document summarising the discussion and identifying decisions and action points for follow up (incl. responsibility and deadline). The minutes also includes a list of attendees.
Note: The format and template of the deliverables may evolve over the contract duration in mutual agreement between the UTBA and the Contractor.
A. The IT tool, in Turkish, shall be developed to serve as a communication network and database for human rights violations at local and UTBA level; although it is expected that the system is to be developed from the ground up, the bidders are welcome to provide a solution built upon an existing solution/software, as long as the bidder provides full disclosure of this underlying technology along with sufficient warranty on the suitability and availability of support (including the licenses, software fixes, updates and maintenance) of the offered solution/platform (including open source platforms) as an annex to the tender documents.
B. The IT tool shall serve as a web-based communication network and reporting tool for human rights violations between the Human Rights Centres (HRC) of the 7 pilot bar associations and the Union of Turkish Bar Associations (UTBA);
C. The IT tool shall facilitate the communication among the lawyers working in HRCs, assist them in following cases of alleged human rights violation, track and manage cases through their official Bar association decision and intervention workflow and ultimately providing a facility to forward/share these cases with the UTBA.
D. The IT tool is foreseen to cover all stages of HRC process, including but not limited to pre-interview, assignment of a tracking/case number, case review, assignment and selection process of a lawyer, case review by the assigned lawyer with progressive entry of information to a case as the case progresses through different stages.
E. The Contractor, prior to start of any development activities, shall provide a team of proficient business analysts to work in cooperation with the UTBA and Bar Associations from the pilot provinces to fully identify and agree upon the business logic and workflows required for the system. It should be noted that the language of communication for the forementioned analysis will be in Turkish and the tenderer is expected to provide a team with sufficient Turkish proficiency.
F. The IT Tool shall provide means in forming of a database for identification of risk areas at national level by recording the particular repetitive alleged violations detected by the HRCs of the bar associations. The database will be a standardised tool including reporting templates, guides for users and will provide information on a number of applications to HRCs, reports produced, actions taken and their results, when available.
G. The IT tool shall provide functionality for local HRCs to create and submit “synthesis reports” on alleged local human rights violations and provide and implement a framework for sharing of these reports with the UTBA.
H. The IT tool shall facilitate collecting of statistical data on specific alleged human right violation and provide and implement a framework for sharing of this data with the UTBA and reporting and analysis on this data at the local and UTBA level.
I. The IT tool shall provide a user-friendly reporting and analysis module (graphs, maps (geographic distribution among provinces and as heat map - in which the geographic distribution and concentration of each type of alleged HR violation can be visualised, charts, dashboards) configurable by each user to suit her or his purposes, assisting creation of various analytic reports on the collected data and information on both the local and UTBA level.
J. The IT tool shall provide a “Communication Module” for a broader scope of lawyers (not limited to HRCs) with interest in human rights and human rights violations for sharing of local and international best practices, experiences, documentation. The “Communication Module” shall also provide grounds for increased collaboration and communication between lawyers. The “Communication Module” should also have an optional administration/approval mechanism for all posts made.
K. The IT Tool shall provide a “Document Library” module with granular access that will act as a platform of sharing and storing reports on alleged human rights violation, relevant key documents, forms, templates and resources for use by the UTBA and HRCs. The “Document Library” module will be managed by the UTBA and shall be flexible to allow granular access to different folders/resources for different levels of users.
L. The IT tool shall be developed in line with the agreed suggestions on data collection, maintenance and analysis methodology, reporting templates, reach out strategies, examples of good practices; in cooperation and under legal guidance and supervision of the UTBA.
M. The Contractor shall provide integration capabilities with HUDOC database where appropriate as well as propose and prepare a framework to enable possible future integration with HUDOC.
N. The IT tool shall be compatible with the existing technical landscape of the UTBA and deployed in the servers of the UTBA. No hardware is to be purchased under this Contract.
O. The Contractor shall cover all license and development costs required for successful deployment of the developed IT Tool as well as all integration, license and development costs for data exchange with UTBA’s UHAP and any other external systems.
A. The IT Tool should be a designed as a web-based platform, developed using modern MVC or MVVM paradigms employing JSON communications to a secure RESTful APIfor the backend. The choice of frontend and backend technologies that employ these patterns shall be agreed by the Contractor and the UTBA at the Contract initiation stage to best match the UTBA’s technical landscape and existing know-how.
B. The IT Tool shall be in Turkish with full support for Turkish Language and alphabet where applicable (i.e. sorting, searching, etc.)
C. The Contractor should also provide a mobile version of the application compatible with both Android and IOS platforms with performing all basic functionalities.
D. For User Login and Authorisation: the IT Tool shall provide integration with BaroKart or UTBA’s UHAP system for authentication and authorisation of users.
E. The IT Tool should provide functionality to enter, report, track and manage alleged human rights violation cases at the local and UTBA level collecting at minimum the following information for each case:
· Identification Information
· Type of alleged Violation
· Subject of alleged Violation
· Category of alleged Violation (from a centrally managed, expandable list of categories)
· Case Summary
· Opinion Notes and Opinion Code (Archive, Track/Follow, Urgent/Commission)
· On-Screen Forms
· File Attachments (scanned documents, pictures, etc.)
F. The IT tool shall integrate with existing systems of the UTBA and bar associations to allow tracking and managing the cases through the official decision making and intervention workflow (Board Meeting, Meeting Agenda/Items, Meeting Decisions, etc.)
G. The IT tools shall be enabled to initiate alleged human rights violation cases from data sources integrating with UTBA’s UHAP system.
H. The IT Tool should provide statistical aggregation and reporting mechanisms (including charts, graphs and maps) on collected case information on both Local and UTBA level.
 An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service.
 A request derives from a user for information, advice, or for a Standard Change as well as Access to an IT Service.
 A problem is the underlying cause of one or more incidents. The cause is not usually known at the time a problem record is created and further investigation shall be perform in the problem management process.
 The HUDOC database provides access to the case-law of the Court (Grand Chamber, Chamber and Committee judgments and decisions, communicated cases, advisory opinions and legal summaries from the Case-Law Information Note), the European Commission of Human Rights (decisions and reports) and the Committee of Ministers (resolutions); available at http://hudoc.echr.coe.int
 MVC: Model-View-Controller is a software architectural pattern that separates an application into three main logical components: the model, the view, and the controller.
 MVVM: Model-View-ViewModel is a software architectural pattern that isolates the view from the model and the ViewModel is responsible for presentation separation and exposes methods and commands to manage the state of a view and manipulate the model.
 RESTful Web services (RWS) conform to the Representational State Transfer (REST), a software architectural style that defines a set of constraints to be used for creating web services generally employing HTTP/HTTPS requests to GET, PUT, POST and DELETE data.
 API: Application Programming Interface, a software intermediary that allows two applications to talk to each other via a set of functions and procedures that access data or another service.