The Agile Based Development

Published Date: 02 Nov 2017

An Agile based development is a methodology which is very famous technique used in the industries now a days. It is a technique of developing the software in very less time. It is the technique in which the customer is involved during the whole development of the software. In Agile development the requirement is given by the customer and accordingly before developing the software team decides how to develop the software, they set their goals of development. In agile both the requirements functional and non functional are considered. During the development initially the team only focuses on functional requirement and after the development during the test they consider the non functional requirement which should also be taken initially with the functional requirement. As non-functional requirement like reliability, adaptability, security is the main issues to be considered during the development of the software. Non- functional requirement should also be considered initially so that the software should be reliable to use wherever required. Each company needs software which does not fail to deliver the intended objective due to the lack of consideration of non-functional requirement. As Agile considers non-functional requirement at implementation level, it may cause problems. There is a need for agile methods to include techniques that make it possible to identify non-functional requirement early and describe them in a manner to indicate that an analysis may happen before implementation. Equal attention should be given to both functional and non-functional requirements.

Table of Content

CHAPTER 1…………………………………………………………………………………..4

1 INTRODUCTION…………………………………………………………………………..4

Scrum……………………………………………………………………………6

The Sprint……………………………………………………………...7

Extreme Programming(XP)……………………………………………………….7

Adaptive software development…………………………………………………8

Agile model driven development(AMDD)………………………………………8

Crystal……………………………………………………………………………..9

Dynamic systems development method(DSDM)…………………………………9

Feature- driven development(FDD)……………………………………………10

CHAPTER 2…………………………………………………………………………………11

LITERATURE SURVEY………………………………………………………………11

CHAPTER 3…………………………………………………………………………………17

PRESENT WORK………………………………………………………………………17

Problem Formulation……………………………………………………………17

Objectives of Problem……………………………………………………………18

Methodology……………………………………………………………………19

CHAPTER 4…………………………………………………………………………………23

RESULTS AND DISCUSSIONS………………………………………………………23

Software development product metrics…………………………………………25

Development Productivity…………………………………………25

Code Reuse…………………………………………………………27

Reliability………………………………………………………………………28

Mean Time to Failure………………………………………………29

Failure Rate…………………………………………………………32

Availability………………………………………………………………………34

Robustness………………………………………………………………………36

CHAPTER 5…………………………………………………………………………………38

CONCLUSION AND FUTURE SCOPE………………………………………………38

Conclusion………………………………………………………………………38

Future scope……………………………………………………………………39

REFERENCES………………………………………………………………………………40

ANNEXURE…………………………………………………………………………………42

List of Figures

IT department of entity S………………………………………………………….…..10

NORMAP window……………………………………………………………….…...12

Agile development requirement hierarchy……………………………………...…….16

Problem Formulation……………………………………………………………...…..17

Line graph of DevP………………………………………………………………...…25

Bar graph of DevP…………………………………………………………………….25

Bar graph of CRe………………………………………………………………...........26

Pie chart of CRe……………………………………………………………………....27

Line graph of Reliability………………………………………………………..........30

Bar graph for Reliability……………………………………………………………....30

Line graph of Failure rate………………………………………………………..……32

Bar graph of Failure rate……………………………………………………………....33

Line graph of Availability………………………………………………………….…34

Bar graph of Availability……………………………………………………………34

List of Tables

Comparison of functional and non functional requirements…………………………..24

Variations of project A for MTTF…………………………………………………….28

Variations of project B for MTTF…………………………………………………….29

Comparison of Reliability of project A and project B………………………………...29

Values of project A for failure rate……………………………………………………31

Values of project B for failure rate……………………………………………………31

Comparison of failure rate of project A and project B………………………………...32

Comparison of non functional requirement on both projects………………………….35

CHAPTER 1

INTRODUCTION

An Agile development is a methodology to develop software in which the whole software is divided into small modules. Each module is built by applying whole cycles of development such as requirement gathering, designing, coding and testing. Each module is built and known as iteration as developer iterates each module until the development is complete. In agile development the requirement changes at any time which do not affect the whole product as in this the programmer and the professional tester both are present to identify the bugs in the software. In this way the bugs are removed while developing the software. Agile takes less time to develop the software compare to other development methodologies as agile takes just few weeks to develop the software. It is a methodology which is being used by all the companies now-a-days.

In agile development customer is involved throughout the development so that they can tell the developers what they really want. In this methodology there is no team leader, all the members work on the same platform on the same designation. They together take the decisions while making software. In this less documentation is used. Face to face communication is done every day among the team members. They set their goal every day and try to fulfill it in a time they selected to finish the task. When one module is completed it is released and customer check for it whether it is good enough for their use and according to their requirement, so that when all the modules are combined there is no effect on the whole software to be used. Various types of agile development are used to develop the software. Agile means a fundamental change as how we manage our projects. The working software that we will deliver and measure our progress by how much we are right. We can change our management working on getting our working software done a tiny at a time. Instead of managing the activities and waiting for the project to end for software, we manage our requirements and demonstrate each innovative version to the customer. Agile software development have proven ability in delivering high value software products though maintaining high customer satisfaction, brilliant team spirit, and better project visibility to all project stakeholders. It is the development which is used by more companies as it does work in iteration which helps in faster development of the software. It helps the team members as stakeholders are with them throughout the development of the software. Agile is a development methodology which helps in the development of the software faster.

Some of the characteristics of agile development is:

It provides frequent delivery of software.

In this there is more iteration while developing the software.

Testing is done frequently.

Less defects.

1.1 Scrum

Scrum is centered on the persons; the customer must have all the needs satisfied. Its most important characteristic is the fact that changes in the requirements are considered in a dynamic way. Thus the customer is allowed to test and provide feedback for the project as soon as possible. This method is also iterative and incremental, and it has short development cycles. Scrum adopts four principles:

It prioritizes the persons and their interaction

It priorities the functionality

It is flexible and adaptable to changes

It considers collaboration

This method is very dynamic and allows quick reactions for the changes in the requirements. In such a way, it is recommended for highly dynamic environments characterized by fast changing requirements where development teams are required to build complex products. The core roles are dedicated to the project in Scrum process—they are the ones which helps in the development of the product.

Customer: Customers are the stakeholders which tell the requirements of the software. The customer writes whole requirements, accordingly prioritizes it and adds them to product backlog. Customer is one of the team members as he is present throughout the development of the software for any changes required in between.

Development Team: Development team is responsible for delivering the software on time. The team is made of 3 to 8 people having skills to analyze, design, develop, test and document. The team is self-organizing.

ScrumMaster:  The ScrumMaster is not the team leader, but act as a safeguard between the team and every disturbing influence. The ScrumMaster ensures that the Scrum process is worn as planned. The ScrumMaster is the enforcer of system. A main part of the ScrumMaster is to protect the Development Team and keep them focused on the work they are doing.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a done, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work, the Sprint Review Meeting, and the Sprint Retrospective. During the Sprint:

No changes are made that would affect the Sprint Goal;

Development Team composition and quality goals remain constant; and,

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product. Each sprint precedes by a meeting for planning, where the tasks for the sprint are known and an expected commitment for the sprint goal is made, and followed by a review or demonstration meeting, where the progress is reviewed and instruction for the next sprint are identified.

1.2 Extreme programming (XP)

It emphasizes teamwork. Managers, customers and developers are all equal partners in a collaborative team. It implements a simple yet effective environment enabling team to become highly productive. The team self-organizes around the problem to solve it as effectively as possible; it improves a software project in five essential ways: communication, simplicity, feedback, respect and courage. Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practice, with adequate reaction to facilitate the team to notice where they are and to refrain the practices to their exclusive situation. XP planning addresses two key questions in software development:

Predicting what will be accomplished by the due date

Determining what to do next.

1.3 Adaptive Software Development (ASD)

Adaptive Software Development (ASD) was developed in 2000 by Jim Highsmith which has grown out of the Rapid Application Development (RAD). Like other agile methodologies, ASD aims to increase a software organization’s responsiveness while decreasing development overhead. It embodies the belief that continuous adaptation of the process to the work at hand is the normal state of affairs. ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, time boxed, risk driven, and change tolerant. The word ―speculatel refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to define it. Collaboration refers to the efforts for balancing the work based on predictable parts of the environment (planning and guiding them) and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes, thus leading to greater experience and eventually mastery in the problem domain.

1.4 Agile Model Driven Development (AMDD)

AMDD is the agile version of Model Driven Development (MDD).  The initial modeling activity includes two main sub-activities, initial requirements envisioning and initial architecture envisioning.  These are done during cycle (iteration) 0, the first iteration before you start into development cycles.  The other activities – iteration modeling, model storming, reviews, and implementation – potentially occur during any cycle, including cycle 0.   The time indicated in each box represents the length of an average session: perhaps you’ll model for a few minutes then code for several hours. The fundamental idea is that you do just enough modeling to determine your strategy for proceeding.  In the case of initial envisioning you want to model just enough to identify and agree to the initial scope of your work as well as the potential architecture for your solution.  During iteration modeling, part of your iteration planning efforts, you will do just enough modeling to understand what you need to do that iteration.  With model storming you will work through higher level issues that are not well addressed with code.  This might be an inclusive modeling session with your stakeholder(s) to understand their requirements, or could be a quick design session with other developers to determine how to build something.

 1.5 Crystal

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics. Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as reflection to frequently adjust and improve the process. Like other agile methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions. 

1.6 Dynamic Systems Development Method (DSDM)

DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling Agile and iterative software development projects. DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out "fitness for business purpose" as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time. Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations. All critical work must be completed in a DSDM project. It is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that if necessary, they can be removed to keep from impacting higher priority requirements on the schedule. The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.

1.7 Feature-Driven Development (FDD)

The FDD variant of agile methodology was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occured as a result of collaboration between De Luca and OOD thought leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using the following eight practices:

Domain Object Modeling

Developing by Feature

Component/Class Ownership

Feature Teams

Inspections

Configuration Management

Regular Builds

Visibility of progress and results

FDD recommends specific programmer practices such as "Regular Builds" and "Component/Class Ownership". FDD's proponents claim that it scales more straightforwardly than other approaches, and is better suited to larger teams. Unlike other agile methods, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.

CHAPTER 2

LITERATURE SURVEY

Malik Qasaimeh et al., (2008) states that it helps software engineers and project managers understand the key characteristics of the software processes and therefore select the most suitable process with respect to the type of software projects being developed. A software process is defined as a set of activities, methods, practices, and transformations that are used to develop and maintain software and its associated products. Agile processes have been proposed to overcome the flexibility issues of traditional processes. They have been developed by practitioners based on their experience working on several software development projects.

Hassan Hajjdiab et al., (2011) presented the experience of performing a case study for adopting Scrum agile practices in a government entity in the United Arab Emirates. It showed how the agile teams faced the challenges during the adoption process. It assumes that change in requirements expected and the software development cycle have to adapt and the teams have to deliver value product to the customer as quickly as possible with less concerns on extensive planning and documentation. The main challenges are requirements, scrum implementation, organization learning. In this the government entity as entity ’S’ which consists of an IT Department that includes around 200 employees. Challenge faced in this case study were missing the Agile Master Role, The Absent of a Pilot

Figure1: IT Department of Entity S

Project, Scrum Implementation, Current Work Pressure, Upper Management Concerns, Governmental bureaucratic System, Documentation requirements.

Peter Wendroff (2011) states the need for joining the entire framework to clarify the distinguishing aspects of agile software development methods. Agile software development avoids large collection of information; instead it relies on the closer joining of subsystems. In this the application of system thinking to agile software method focuses on the delays faced in software processes. In this paper two delays are identified, one is on the separation of process definition and process execution that is frequent practice in software engineering management. Agile development method proposes an integrative approach toward process definition and process execution. The second delay is caused by buffering strategies that are widely used. Agile method wishes at reducing the number, size and complexity of buffers.

Vikash Lalsing et al., (2012) is based on agile methodology and within an organisation that is making use of scrum. It is imperative that before any organisation decides to adopt an Agile Method, it needs to assess whether the company’s culture, operating structure, business processes and projects are suited for the use of an Agile Project Management Methodology. This study was aimed at evaluating the people factors that can affect the performance of an agile team. The research was made with a small group of similar projects that differed by size and team size only. It advocates a small and collaborative team that work closely together, but team size is a factor that is in turn constrained by people factors. Agile principles require that team members work in intense collaboration and have face-to-face communication so that the problems can be faced together can decide how they collaboratively work on the specific task to achieve a common goal.

Weam M. Farid/ Frank J. Mitropoulos (2012) tell about the java based NORMATIC tool for modelling non-functional requirements for semi-automatic agile processes. NORMATIC is the semi-automatic tool that supports the more general Non-Functional Requirements Modelling for Agile Processes (NORMAP) Methodology. The research show that the tool can potentially help agile software development teams in reasoning about and visually modelling non-functional requirements as first-class objects early on during requirements gathering and analysis phases. The tool can also aid project managers and Scrum teams in user story estimate and risk calculations as well as risk-driven planning and visualization of the proposed plans. User stories are one of the primary development artefacts for scrum and XP project teams. A user story is a very high level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. This paper presents how NORMATIC supports the three building blocks of the lightweight engineering-based yet agile NORMAP methodology for identifying, linking, and modelling NFRs with FRs in an attempt to potentially improve software quality without compromising agility. NORMATIC was built as a semi-automatic tool on top of its underlying foundational framework, namely, the NORMAP Methodology. NORMATIC automatically calculates how many times a requirement has changed. NORMATIC captures important requirements quality metrics that are used in calculating per-requirement risks as well as overall aggregate risks. This research addressed NORMATIC as a viable modelling tool that simulated the underlying NORMAP Methodology.

Figure 2: NORMAP window

Weam M.Farid/ Frank J. Mitropoulos (2012) shows agile methodologies have not adequately modelled Non-Functional Requirements and their potential solutions (operationalization) with functional requirements in early development phases. The three artefacts are combined in a visual framework to promote agile modeling of non-functional requirement (primarily) and how they are linked to functional requirement. The artifacts are the building blocks of a more comprehensive framework for modeling non-functional requirement in agile software development processes. Non-functional requirements are ignored in agile environment. This research study is part of the NORMAP Methodology which was concerned with the identification, modeling, and linking of agile non-functional requirement and their potential solutions with their functional counterparts. A visual modeling simulation tool, NORMATIC, was designed and developed in a Java-based environment that utilized visualization frameworks, such as JUNG and Perfuse. This research study hypothesized that agile processes can still benefit from lightweight engineering processes that can capture non-functional requirement as first-class artifacts early on, and not treating them as an afterthought process. It supported the claim that was conducted when it is stated that agile development methods are sometimes criticized for not having explicit practices for non-functional requirement. The authors proposed the Performance Requirements Evolution Model (PREM) but it focused more on the specification and testing of non-functional requirements as opposed to modeling requirements and it only focused on one non-functional requirement (performance) as opposed to a generic framework that could be easily adapted to most non-functional requirements.

Neil A.Ernst et al., (2012) shows that Innovative companies need an agile approach for the engineering of their product requirements, to rapidly respond to and exploit changing conditions. It proposed a systematic approach to agile requirements evolution where it is easy to change requirements and automatically evaluate the consequences of these changes. It showed that this reconciliation also makes it possible to delay decisions about conflicting requirements until more information becomes available. This paper examines how to support a combination of lightweight, agile requirements which can still be systematically modelled, analysed and changed. While this lightweight approach to Requirements Engineering has become popular in many segments of industry software requirements uses words like correct and unambiguous to describe its recommended practice for requirement engineering. Two operations for reasoning par consistently on requirements models, searching for minimal solutions to the requirements problem despite the existence of contradictory or missing information. Requirement changes are very expensive to accommodate and constitute the most frequent cause of project failures. These requirements are often manifested as very brief user stories, which serve as conversation starters with business representatives. A major concern with such lightweight requirements engineering is that non-functional requirements, such as security, are often neglected since system functionality is the focus.

Donna D. Gregorio et al., (2012) states that Agile teams need the Business Analyst to clearly define and communicate the detailed user stories to ensure a successful product. Unlike the detailed requirements documentation of more traditional, waterfall-based projects, it has been found the streamlined user stories inadequate for developers or testers. Business analyst activities include grooming the backlog, documenting user stories with detailed contracts, and performing user story verification through testing. Objects from other agile projects and documenting recommended agile process guidelines can help projects to be successful through reuse and collaboration. Using a Business analyst on an agile project can provide minimal structure and process where the agile approach tends towards ignoring the techniques. Helping the agile projects to collaborate can be facilitated through the use of a sharable agile repository, in addition to a specific project repository. Plan for issues related to scalability, since agility works best in smaller groups and can get harder to manage with a huge backlog. The enhanced communication results in a better product based largely on improved stakeholders expectations. The development team delivers software frequently, but the production release process runs at a different pace, picking up the software at the intervals. Tasks such as risk management, system integration, system design, unit/performance/ regression testing are still part of the package, though not necessarily called out differently within the process. The items are identified as user stories within the backlog and are prioritized against other activities for time in the sprint.

Ani Liza Asnawi et al., (2012) observed that members are using Scrum and have a maximum of five years’ experience. It categorised the findings in terms of awareness, introduction and challenges they are facing, together with the suggested and practiced solution. There is a change in mind set when practicing Agile was identified to be helpful in reducing the challenges. A survey was conducted in Malaysia in which several challenges have been encountered when introducing Agile in the organisations. It aimed to provide awareness and knowledge about Agile methods to the practitioners in the country and the nearby region. The perceptions have been identified from the awareness, the way they introduced the method and the challenges they are facing serves as the guidelines for adopting the agile methods. A low perception from Agile users towards the methodologies and that there is difficulty of getting everyone in the team to take responsibilities. The findings also showed that people need to be confident when trying to use agile methods. The challenges are mostly found from the organisations having hierarchical approach. Agile is hard to be accepted or taking time to be accepted. The challenges from lack of documentation, organisational aspect, involvement, knowledge and culture are all based in or related to people factor where the mind-set change is needed to overcome the challenges.

Oscar Nierstrasz (2012) stated that in software maintenance much time is spent. So they present a platform for software and data analysis, known as moose, which enables the rapid development of custom tools for the assessment of software. Moose is a platform for analysing the data and software. A typical use case for moose is to use one of the several available importers to parse source code in one of many languages. It has been explored several innovative techniques to speed up the process, such as generating parsers automatically. Although software architecture is perhaps the most important technological driver of a complex system, its presence is only implicit in the source code.

D.Duka (2012) stated how the development of software changed the using of traditional waterfall model to agile model and how the team members are reduced and they work together to achieve common goal without having any leader. They work in a team by interacting each other in the meetings and decide their everyday goal to achieve. The team they used are of very few members but they work so smoothly that they get their task done in few weeks. Agile approach creates many added values since it enforce creating self-organizing and cross- functional teams capable to develop the whole software, from systemization through coding to functional testing. Agile wants every team member to be involved throughout the development of the software.

CHAPTER 3

PRESENT WORK

3.1 Problem Formulation

The problem focuses on Non-Functional requirement in agile environment. As Agile considers non-functional requirement at implementation, it may cause some problems. There is a need for agile methods to include techniques that makes it possible to identify non- functional requirement early and describe them in a manner to indicate that an analysis may happen before implementation. Non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. The plan for implementing non-functional requirement is detailed in the system architecture. Non-functional requirement are often called qualities of a system. The research on the use of non-functional requirement during requirements engineering and how software teams deal with quality issues as requirements.

Figure 3: Agile development requirement hierarchy

The study focuses on the requirement which is the essential thing to be considered while developing any software. It is the major part which plays vital role in developing software. As the development goes on sometimes requirement changes so agile provides flexibility of changing requirements. As the requirement changes frequently so the issues like reliability, security, performance, scalability, and usability are to be considered during the development so that no constraints are raised.

Incomplete

Requirements

Required

Requirements

Step by step

Planning

Developed Authentic

Software Plans

Communication

Among team

Members

Figure 4: Problem Formulation

3.2 Objectives of Problem

The following objectives are to be achieved through this research:

To Demonstrate the importance of non-functional requirements in Agile development for the better development of a software.

Impact of considering Non-functional requirements on software development.

Process of implementing and considering non-functional requirements in Agile development.

3.3 Methodology

To show the work done two projects were taken, one Library management system (Project A) which is developed by using waterfall and the other Student Management System (Project B) using agile based development. On both the projects some metrics are applied to show my work.

Software development product metrics: In software development the software process is defined using development productivity. It tells about the use of software by the customers. Management of the software development process has the ability to identify measures that characterize the basic parameters to control and assist continuous improvement of the project. While developing the software it is mandatory to find bugs in them and resolve them accordingly. Metrics are the important part while developing the software as it comprises of telling the user how your software is good in working or how can it be used while in crucial times. Software development follows the various phases while developing the software as planning, designing, coding, testing, implementation and documentation. These phases are important while developing the software. These phases help in developing the software in specific manner or to follow some path to develop the working software. The aim is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments. The software during development follows the iteration and accordingly the metrics are applied to get better working software. It helps in enhancing the development of the software. The software developer is required to provide customer service by defining the development productivity and the code reuse.

Development Productivity: The development productivity is calculated by dividing the development time spend on development of software by the lines of code which are used to develop the software. The production of the developing software enhances the production to some extent. It helps to know the average efficiency of the developing software.

Development Productivity=Development Hours/Line of code

Here Development hours is the total working hours invested in the development of the software system.

Code Reuse: Code reuse is calculated by dividing the number of reused lines of code with the total number of lines of code. It helps in calculating the code which is reused or the code which is already used by other programs using which we are making some new program which helps in less complexity. It helps the users time of developing the software. It helps in fewer bugs in the software as they are removed when used earlier.

Code Reuse= Reused Line of code/Line of code.

Reliability: In software development reliability plays the main role to response the user as he wants. It is the consistency of a number of measurements taken using the same measurement. If the measurements are highly consistent or identical, then the measurement has a high degree of reliability. Reliability refers to the degree of change in the output due to fluctuations in the input data. Yielding the same or compatible results in different situations. The developed software when measured under different situations give almost the same result which shows reliable data or output. It tells us how much the software is reliable to use in different critical situations. It helps in knowing its usage in the complex situations where sometime the system fails when it is been used by various users simultaneously. It helps in knowing the complexity of the software which is being developed. Reliability helps in measuring the failures which makes the software more reliable to use. If the variations are large then reliability is low. Reliability is measured by the mean time to failure (MTTF) and the failure rate.

Mean Time to Failure (MTTF): 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. It helps in knowing how frequently the failures occur while accessing the software.

MTTF= Operating time/Number of failures

Where operating time = Current date – Date of first production.

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. It is measured by diving the number of failures to the total number of trials we made to access the software.

Failure rate= Number of Failures/ Total number of trials

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. It is the measure of system availability to the user whenever user requires the software for accessing. Whenever the user wants to update something in the software at that time system should be available for its use by the user and after doing modifications system should not fail, it should work in the same manner as it was working before without causing more failures to occur while accessing the software. It is the probability the software will operate satisfactorily when required by the user at a given point of time when used under given conditions. It is measured by ratio of mean time to failure to the sum of mean to failure and mean time to repair. Mean time to repair is the time which is required to repair any device while it fails which helps us to get the availability of the system to the user. Whereas mean time to failure indicates as how many time failures occur while accessing the software at a given instance of time means at about how much time the system fails which helps in knowing the availability of the software to the user which every user wants even in very critical situations also. Software should be available to use whenever the user want it to use which helps in getting the faith of the software which can help the developing team which are developing the software for the use by the user. It is usually referred in terms of percentage.

Availability= Mean time to failure/ (Mean time to failure + Mean time to repair)

Robustness: Robustness is the ability of software as to behave according to the needs of the customer. It is the capability to manage the errors through execution or the capacity to continue to operate in spite of abnormality in input. 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.

CHAPTER 4

RESULTS AND DISCUSSION

To initiate the non functional requirement to be used with the functional requirement, two projects were taken Library management system (project A) and Student management system (project B). Project A was developed using the waterfall model and project B was developed using agile based development methodology. In project B the non functional requirements were defined by the customer at the same time when functional requirements were defined.

Project A i.e. library management system, which is used to automate the existing system of manually maintaining the record of the Book Issue, Book Return from the student, Stock Maintenance, Catalog and Book Search to be computerized. So the Book Issue, Return, Searching will be faster. Records will be easily edited and the database will easily be updated at the time of entering a record. It will be much easier to find particular record rather than opening such huge files and finding a single record from them. It is made using traditional model in which no non functional requirement is given only functional requirements are defined. The Library Management System is an application for assisting a librarian in managing a book library in a university. The system would provide basic set of features to add/update members, add/update books, and manage check in specifications for the systems based on the client’s statement of need. Library management system is developed to maintain the record of whole library easily and reduce the burden of the librarian which helps the students also as no queue will be maintained for the issuing and returning of the book. It helps the staff also to get the book from library easily as they has very less time. It helps the student as they can get to know if the book is available in the library or not rather then they have to hush in the library in search of book and waste their more time in search of book. It helps the librarian to maintain the weekly record to show to their higher authorities. The whole records of books are kept to check whether the book is available or the book is not in the library. It easily calculates the fine as if any student returns the book after due date which helps the librarian. This system is being maintained by all the educational institutes now as it helps them in many ways. Here is the process of library management system which is being explained in the form of entity relationship diagram and logic flow diagram.

Project B which is a Student management system deals with maintaining a physical contact with the academy management dept. for filling all the details and the documentation work. The management doesn’t needs to visit the academy management dept. and collect the assignment and submitting his/her documents directly. According to the current system, the management has to fill in the forms manually, go to the account management dept., and submit him the form. The applicant needs to visit the academy portal now and then in order to get his work accomplished. The admin also has to manage all the users. He needs to maintain records of all the users, their activity status, submission methods and installation details on paper. The Manual process is more error prone and also slow. Moreover Students in the academy can interface his/her work area only. But if an online application is available then they can communicate whole system. Thus a simulation of this entire process can be a boon to the applicants as well as the admin. Following functional requirements are given by the customer:

Registration details of the applicant.

Login details of the applicant.

Personal details of the applicant.

Information of all the members of the applicant’s group.

Information of all the friend list of the applicant’s account.

Educational and employment information

All information and rules regarding the e-forms must follow.

Certain legal details of the applicant.

Details regarding the purpose of user visit to academy.

The statutory declaration of the applicant.

Answers to the questionnaire for skill assessment of visitor.

Communication with whole system.

Non Functional requirement which the customer defines before the development was reliability, availability, robustness.

Considering both the projects, project A and project B some metrics was used to show that defining non functional requirement is equally important with the functional requirement.

Table 1: Comparison of functional and non functional requirements:

Functional Requirement

Non Functional Requirement

It tells us about the features of the software.

It tells about the properties of the software.

It lets us know about the working we are performing.

It lets us know about the quality of the work we are performing.

It helps the user to know about the performing of actions about the concerned work we are doing.

It helps the user to know from the experience while performing the work.

Software development product metrics:

In software development the software process is defined using development productivity. It tells about the use of software by the customers. The software developer is required to provide customer service by defining the development productivity and the code reuse. The aim is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments. It mainly tells about the efficiency of the system. Efficiency tells about the performance of the system which can be calculated by the development productivity and the code reuse.

4.1.1 Development productivity (DevP): The production of the developing software enhances the production to some extent. It helps to know the average efficiency of the developing software.

Development Productivity = Development Hours/ Line Of Code

Here Development hour is the total working hours invested in the development of the software system.

In project A, Line of Code= 7364

In project B, Line of Code= 6758

In project A, development days=49 days

In project B, development days=53 days

Development hours are calculated by multiplying the days with 8 as per day 8 hours are spend on developing the project.

Development hours on project A= 392 hrs

Development hours on project B=424 hrs

Development productivity of project A= Development hour/Line of code

= 392/7362

= 0.053

Development Productivity of project B = Development hour/Line of code

= 424/6758

= 0.062

Figure 5: line graph of DevP

Figure 6: Bar graph of DevP

Here the development productivity of project b is less than project a which helps in observing that the project b is more efficient than project a. The efficiency of project b is more which shows that by defining the non functional requirement makes the software more efficient. It shows that non functional requirement is equally important to functional requirement in defining the requirement before the developing of the software. Efficiency leads to the performance of the system which helps to know about the working of the system.

4.1.2 Code Reuse (CRe): It helps in calculating the code which is reused or the code which is already used by other programs using which we are making some new program which helps in less complexity.

Code Reuse = Reused Line of code/ Line of code

Code Reuse for Project A= Reused line of code/Line of code

= 2342/7364

=0.318

Code Reuse for Project B= Reused line of code/Line of code

= 1738/6758

= 0.257

Figure 7: Bar graph of CRe

Figure 8: Pie chart of CRe

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. It is the consistency of a number of measurements taken using the same measurement. 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 requirem