Pie Chart Of Cre

Published Date: 02 Nov 2017

Here it shows that project B has used less reused code means the reuse of code by project B is less than the project A which helps in defining that the bugs will be less prone to this project as it has already been tested when it was used. It helps in making the software more efficient in accessing, which leads to the non functional requirement. It shows that the non functional requirement is also important comparative to only functional requirement. It helps to know about the efficiency of the system. As the system is more efficient which is using the code once for each project as the reused code becomes obsolete which make the user dependant as they rely on old code and do not try to make new code which may not give some new idea of programming which may degrade the efficiency as user which use less reused code is more efficient as in it new concepts of programming is there which leads to more efficient system.

Reliability:

In software development reliability plays the main role to response the user as he wants. The measurements taken by the user of same values provides consistency. Different Solutions' service center for on-demand applications ensures monitoring, administration and support for mission-critical software round the clock. The redundancy is ensured at every level, from network devices and firewalls to application software and databases. This includes data storage and back-up on site, as well as at off-site locations. If the measurements are highly consistent or identical, then the measurement has a high degree of reliability. If the variations are large then reliability is low. Reliability is measured by the mean time to failure and the failure rate. Reliability refers to the consistent variations of the values. It may be noticed that if the data is reliable it may be valid also which lead to high reliability. Reliability is the parameter use to check the consistency of data and tells about the performance of the system as about how much time it can work regularly.

4.2.1 Mean Time to Failure: Mean time to failure is the failure occurred while running the software. It helps in knowing that how much failures occur while accessing the software. It can be measured by dividing the operating time of the software by the user to the number of failures occurred during the usage of the software. Whereas operating time can be measured as difference between the current day to the day when we first operate the software at the time of production.

Mean time to failure = Operating Time / Number of failures

Where operating time = Current date- date of first production

Table 2: Variations of project A for MTTF

Operating Time

Number of Failures

Mean time to failure

5

3

1.66

6

3

2

7

4

1.75

8

4

2

9

4

2.25

10

5

2

11

5

2.2

12

6

2

13

6

2.16

14

7

2

15

9

1.875

Table 3: Variations of project B for MTTF

Operating Time

Number of Failures

Mean time to failure

5

2

2.5

6

2

3

7

3

2.33

8

3

2.66

9

3

3

10

4

2.5

11

4

2.75

12

4

3

13

5

2.6

14

5

2.8

15

5

3

Table 4: Comparison of Reliability of Project A and Project B

Project A

Project B

1.66

2.5

2

3

1.75

2.33

2

2.66

2.25

3

2

2.5

2.2

2.75

2

3

2.16

2.6

2

2.8

1.87

3

Figure 9: line graph of reliability

Figure 10: Bar graph for Reliability

The above graph shows that mean time to failure in project B is less than project A which indicates that the project B is more reliable compare to project A as non functional requireemnt is defined in the project A. Project B is more reliable then project A as less failures occur in it while accessing, it shows its reliability as how much reliable it is to use project B in which non functional requirement is defined before the developing of the software begins.

4.2.2 Failure Rate: Failure rate is the rate at which the failures occur at given instance of time. It is the measure of how frequently the failures occur while accessing the software. It tells how many times failures occur whenever we try to access the software.

Failure rate= Number of failures/ Total number of trials

Table 5: Values of project A for failure rate

Number of failures

Total number of trials

Failure rate

3

5

60%

3

6

50%

3

7

42%

4

8

50%

4

9

44%

4

10

40%

5

11

45%

5

12

41%

5

13

38%

6

14

42%

Table 6: Values of project B for failure rate

Number of Failures

Total number of trials

Failure rate

2

5

40%

2

6

33%

2

7

28%

3

8

37%

3

9

33%

3

10

30%

4

11

36%

4

12

33%

4

13

30%

4

14

28%

Table 7: Comparison of Failure rate of project A and project B

Project A

Project B

60

40

50

33

42

28

50

37

44

33

40

30

45

36

41

33

38

30

42

28

Figure11: Line graph of Failure rate

Figure 12: Bar graph of failure rate

The above measurements show that Project B which is made by agile development is more reliable. As customer specifies in its requirement that the project should be 38% reliable which is almost 40% reliable whereas project A which is developed by the traditional method in which no non functional requirement is mentioned is 60% reliable only and is more complex. It shows how much important is to define the non functional requirement with the functional requirement.

Availability:

System availability means the system is operational when work has to be done. System availability means that the system is available for use as percentage of scheduled time. Availability refers to the amount of time that a system is actually available relative to the amount of time users expect it to be available.

MTTF for project A = 1.66

MTTF for project B = 2.5

Here MTTF is the Mean time to failure

Let us take the mean time to repair = 2 hour

For project A,

MTTF = 1.66 * 365 * 24 = 14541.6

Here MTTF is the mean time to repair

Availability= MTTF/ (MTTF+MTTR)

= 14541.6/14543.6

= 0.9998%

For project B,

MTTF= 2.5 * 365 * 24 = 21900

Availability = 21900/21902

= 0.9999%

Figure 13: Line graph of Availability

Figure 14: Bar graph of Availability

The above graph shows that the project B is more available then the project A which shows the availability of the software which is a part of non functional requirement. As the non functional requirement is defined before developing the software it gives higher availability as compare to project A. It shows that both the functional and non functional requirement are equally important in defining the requirement.

Robustness:

It is an ability of software as to behave according to the needs of the customer. The Hosting Systems by Different Solutions deliver peak performance at any time and for any utilization ratio.As customer had defined functional and non functional requirements and his project/ software is working according to his requirement means more reliable, available and correct which shows that that the agile based development project in which non functional requirement is defined is more robusted as compare to project A as in it customer told about functional requirement only and the project is according to that but it gives errors afterwards i.e. more failure which customer do not want in the project. . Sometimes user make changes in the software which makes the input variations very large but the system should work as before without showing any error. When user or customer gives their requirements and the development team develops the software and the customer feels that the developed software is according to his need which he had mentioned in the requirements then the customer feels satisfied as the software is behaving as the customer wants it to work.

Table 8: Comparison of non functional requirement on both projects

Project A

Project B

Efficiency

It seems to be efficient but it does not provide the required quality as it is more complex after it has been developed.

It is efficient as the complexity is resolved at every iteration as the user has given the non functional requirement which helps to know about the quality of development.

Reliability

The system has the reliability to show that the failure rate and the failures occurred while accessing which is at low extent.

The system has the reliability as the stakeholder tells that upto which level the failure can be considered accordingly the system is developed by the team which fulfills the need of the user.

Availability

It is available when it is required by the user without having concern about the failures occurs in the system while accessing.

It tells about how much the system is available when is required by the user by knowing the failures of the system which is considered by user before development of the software.

Robustness

The system is developed which works as mentioned by the user but the quality of the system may degrade as it was not mentioned by the user at the time of development.

The system is robust as it works according to the needs of the user as they had given all the requirements as when the failures can be considered and accordingly the system works.

CHAPTER 5

CONCLUSION AND FUTURE SCOPE

5.1 Conclusion

Non functional requirements are to be considered initially while defining the functional requirements as shown through the metrics. In project A where no non functional requirement is defined the software is more prone to errors and the complexity of the software increases whereas as in project B non functional requirements are defined initially with the functional requirement which takes less time to develop the whole software and no complexity is generated. It has been observed that if the project requires fixed time to develop, this method is best suited because it defines fixed time to handle project and control risk in each iteration. The system should be reliable enough so that the data found in the database system is consistent at any point. The system should be able to handle loads of requests from different users around the world at the same time. If the project needs high quality, it will be done by defining the non functional requirement with the functional requirement to improve quality of the project. If a project tends to grow bigger in response to the needs of customers, we would choose Agile as a development method as it provides better framework for the scalable project. It has been observed that defining non functional requirement with the functional requirement tends to be better then defining only the functional requirement. It has been proved that non functional requirements are equally important in the project as the functional requirement. Everyone wants his software to work accordingly as user wants. Everyone wants his software to be reliable, adaptive which is a non functional requirement but if define only functional requirement than how can we get a good working software as we do not pay much attention to non functional requirements so it has been proved that non functional requirements are equally important as functional requirements as only with the help of them only our software has something to show to us. It has been observed that having reliable software makes the users burden of work less. Defining non functional requirement makes the software less complex as compare to other software in which only functional requirements are defined. Metrics are used to show that non functional requirements are equally important which helps to prove in showing it.

5.2 Future Scope

The results of this thesis work point to following directions of research that are likely to be needed for further improvement.

A more enhancement is required for non functional requirements to be defined while developing the software.

Other requirements other than reliability used to expanding the search space.