Shulou(Shulou.com)06/01 Report--

This article shows you what SLA refers to. It is concise and easy to understand. It will definitely brighten your eyes. I hope you can gain something through the detailed introduction of this article.

Service level Agreement, Service Level Agreement, (SLA)

Service level agreements define the basis for formal understanding and communication between developers and customers. Simon Jackson explores why your project needs a service-level agreement.

Service level agreements (Service Level Agreement,SLA) are used to manage the performance of services. Although it may not be a common part of your development project, SLA can be used to improve the quality of the development process, reduce the risk of project failure, and strengthen relationships with customers. SLA embodies professionalism-publishing and relying on acceptable standards shows that the company knows its business and customers. This article will explore service-level agreements in software development: why you need to use it, and the knack for creating such a protocol.

01 what is a service level agreement

SLA Information Zone's Web website describes SLA as "a document that defines the relationship between the two." SLA sets benchmarks for the elements of the development process, which is considered important to maintain the relationship between the development team and the customer.

Although it is not a formal contract, SLA can be used as part of a formal transaction. The difference between the contract and SLA lies in the purpose and rigor of the text. The purpose of a contract is to formalize the relationship and have legal effect, while SLA is used to improve the relationship and does not have legal effect. However, if the terms of the SLA cannot be fulfilled, you will hurt or destroy the relationship, which is the same as the consequences of non-performance of the contract.

02 Why should a service level agreement be implemented?

Software development has a bad reputation for delivery. According to the CHAOS report of Standish Group in 2003, more than half of the IT projects will be "questioned" when there are difficulties in development requirements and budgets.

There are a variety of reasons for project failure, but various studies have shown that standards are essential to the success of the project, such as user participation and clear requirements. SLA is a tool to take these principles out of books and put them into practice in practical projects.

It is also important to strengthen the relationship with customers. Writing SLA requires an understanding of professional software development and real responsibility to customers. You know what you want, and stick to it, giving customers reason to believe in your abilities and knowledge.

03 Why should service level agreements be included?

The main factors of project success include project selection, customer participation, formal project management and requirements management.

Depending on the size, planning, and risk of the project, you also want to consider best practices for software development, such as quality assurance and unit testing.

It is also important to add what the customer thinks is important. You may not always agree, but it's important to ask, listen and negotiate if you have to.

Remember, SLA defines relationships; it is based on protocol and understanding. By getting input from users, you are strengthening the relationship and improving the whole process.

04 Select project method

At first, it seems unreasonable to choose a project approach that is suitable for the project. Instinctively, we are looking for a real way, that is, the perfect way to achieve project success effectively. If you have heard enough of the rhetoric of the preacher in any process, you will begin to believe it. Nagging picky words are always there, but-if their processes are so good, how do so many other processes come from?

It is important to ignore the words of the pseudo-religious and focus on the customer and the project. Every customer and every project is different-no solution is a panacea.

There are many alternatives, so you should choose one that adapts to your specific requirements. Scott Ambler, a pioneer in agile software development methods, pointed out in his article "One Size Fits None" that "doing this requires an understanding of the project, as well as an understanding of the strengths and weaknesses of various methods."

SLA must declare the selected project methodology and the associated features and performance standards. Customers may not be very concerned about which method they choose, but they will care about how it affects the project.

05 customer participation

The motto "publish early, publish often" is often bragged about more but less done. What is hidden here is that customers should not hear any adverse surprises during the implementation of the project: such as "We are 50% over budget" or "it will take at least two more weeks".

Strategies for engaging customers include meetings, shared workspaces, and formal problem management.

06 meeting

Regular meetings, preferably once a week, are often ignored by developers, although they can be the pillars and saviors of the project. If used properly, they will help solve problems, strengthen relationships, and deepen the team's understanding of customer requirements. But if used improperly, they can waste time and undermine confidence.

SLA must determine the frequency and content of the meeting in order for the meeting to be effective. These include a fixed agenda, the appointment of a chairman, timekeeper and clerk, notification of action items and distribution of minutes of meetings.

For how to organize the meeting, visit your local (professional) host. These meetings have fixed rules; for example, if they all start and finish on time, the speaker should speak according to the schedule. As a result, they do not degenerate into talkative monologues.

07 shared workspac

The project brings a lot of information-documents, discussions, problem records, contact tables, and events. Centralization and sharing are key factors in coordinating projects and maintaining user participation.

To be truly effective, the entire project team must be able to get resources from possible sources-from the office, at home, or on site. The intranet based on Web is a good solution.

08 problem management

This is the most important part of customer relationship management with the least practice. In the course of any project, there will be a lot of questions, questions and suggestions. Capturing, saving, prioritizing, and dealing with these things is extremely important to promote a project that the customer considers to be successful. There are examples of delivering what the customer wants but still failing. This may be because the project requirements have changed, or because they are not fully stated in the document. Listen to customers' opinions and start to solve problems as soon as they arise, so that we can maximize our chances of success. E-mail is not a good tool to accomplish this task. I often see customer relationships deteriorate rapidly because of false content in emails. A single, centralized problem registration should be maintained, perhaps in an intranet. Technology is not that important, but everyone should be able to see the registration information for these issues and monitor and review them frequently.

09 formal project management

Generally speaking, project management requires different software development skills. However, senior developers are often required to manage budgets, plan resources, recruit people, manage customer relationships, and other matters in addition to leading development. This is not only unreasonable, it is often fatal to customer relationships.

Project management comes at an additional cost, including that clients are sometimes reluctant to hold meetings, especially if they have poor project management performance in the past. The SLA that defines project management results and standards will help allay their concerns to some extent.

10 requirements management

Understanding what the customer needs is an important part of delivering value. This is complicated because in some cases, customers may have only a fledgling idea of what they want. In all cases, they rely on the technical experts of the development team to give them advice. The method of requirements management is the basis of the software development method. For example, agile software development methods often assume that customers do not have a complete understanding of what they need. The so-called waterfall development approach starts with a formal and static and well-defined requirement. Requirements management is therefore closely related to the choice of project methodology.

SLA must recommend a method of requirements management and how to deal with changes in requirements during project implementation. This includes a change control process that puts forward functional requirements for the second release or re-quotation of the entire project.

11 Software "Best practices"

Software development has special practices; the correct use of these practices can improve software quality and production efficiency. These practices include nightly builds, functional reviews, defect measurement tracking, code comments, documentation, quality assurance, changes, colleague reviews, unit tests, and user acceptance tests.

Not every SLA needs to use all of the above; it depends on the technology, experience, and creativity of the project, the customer, and the project team. Don't be afraid of new ways of doing things-success is an innovative process.

12 Service level agreements in practice

Like most performance measurements, SLA should be SMART: Specific, Measurable, Achievable, Realistic, and Time-bound. I will use a benchmark for functional evaluation as a practical example to illustrate the above. The first part of the benchmark is quite simple: "We will evaluate the functionality of the software."

This raises some obvious questions: what is the functional assessment and why is it needed? Who will conduct the evaluation? How to carry out the evaluation? When will it be evaluated? So it certainly doesn't conform to the SMART standard-- because it conveys too much information.

To improve it, the first thing to do is to make this statement more specific, stating what to achieve, why, and how to achieve it. "functional assessment is used to check the integrity of the software to see if it meets established requirements and business needs. This ensures that the released software can meet customer expectations.

"before conducting the first evaluation, the supplier should summarize the requirements in the form of a little bit, accept the inspection of the customer, and get the approval of the customer.

"the functional evaluation includes a meeting of the entire project team-that is, the development team and the business team. During the meeting, the development team will state how each requirement is implemented in the software, which is explained by the latest development version of the software.

"the customer is responsible for determining whether each function has been implemented correctly." This is much more specific. Materializing the requirements also allows the development team to check whether the standards are achievable and realistic.

These measurements depend to a large extent on the capabilities of the development team-technology, knowledge, experience, and time. The above statement still does not fully meet the SMART standard: it does not have a time limit and does not provide a basis for performance measurement. More details are needed:

"three functional tests will be conducted: the first is when the code is 50 per cent complete, the second is 75 per cent complete, and the last evaluation is after the software enters formal testing (formal testing,QA). Of the functions to be resolved, 90 per cent will be recognized by the customer as completed."

In this case, the planning should be based on the milestones in the construction phase. More specific dates can be provided to the project planning through these points. We also need to express a clear and measurable standard. If you fail to do this, there may be problems in the development process, in the specification or communication process.

Now this is the goal of the project and an early warning system. It will once again ensure that customers know that they will be asked if they have met the project requirements and give them confidence that you will deliver value for money to them. By using it, you can show that you are aware of common problems in software development-- incomplete or incoherent requirements-- and that you are determined to solve the problem.

13 Service level agreements are applied every day

Of course you will "get what you measure", but SLA is not simply used as a method of measurement. By setting achievable and realistic benchmarks, it becomes a tool for improving software development and enhancing customer management. Although the quality of software development has improved in the past decade, there is still a lot of room for improvement; SLA is one way to solve the problem.

The above is what SLA refers to. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.