vender management sdscs.uccs.edu/~gsc/pub/master/cmarjani/doc/vendor... · web viewcontinuous...

Curt Marjaniemi Date: 4/26/2008CS 701 Masters Project Final Report of 18

Vendor Management Application and an evaluation of Scrum, Test Driven Development (TDD) and Continuous

Integration (CI)

CS701 Masters Project Final Report

Curt Marjaniemi

Project Advisor: Dr. ChamillardCommittee Member: Dr. ChowCommittee Member: Dr. Kalita


Table of Contents1. Executive Summary 32. Project Background Information 3

2.1. Customer 32.2. Technologies Employed 32.3. Challenges 32.4. Deliverables 4

3. Methodologies Employed 44. Scrum Development Process 4

4.1. What Problem Does Scrum Attempt to Resolve? 44.2. What is Scrum? 64.3. How Scrum Was Used On This Project? 74.4. Experience with Scrum 84.5. Conclusions 10

5. Continuous Integration (CI) 125.1. What Problems Does Continuous Integration Attempt To Solve? 125.2. What Is Continuous Integration? 125.3. How Continuous Integration Was Used On This Project 135.4. Conclusions 13

6. Test Driven Development (TDD) 146.1. What Problems Does TDD Attempt To Resolve? 146.2. What is TDD? 146.1. How TDD Was Used on This Project? 146.2. Conclusions 16

7. Summary of Conclusions 178. Works Cited 17


1. Executive SummaryIn today’s business environment, organizations utilize third party vendors for many essential services such as internet access, offsite storage, and data processing. With vendors that provide critical services that often deal with sensitive business data, managing these relationships is more important than ever (Chirasrota, 2007). A vendor that has a security breach and compromises sensitive data or that has an outage of a critical service provider, can negatively impact an organization.

In the financial sector, because of these risks there is an increase in regulatory oversight surrounding proper vendor management. The Vendor Management application is a tool that intends to fill this business need for effectively managing vendors and provide an audit trail for regulators.

A key element of this project was not necessary the technical aspects of the Vendor Management application, but how it was developed using methodologies such as: Test Driven Development (TDD), Continuous Integration (CI), and a lightweight agile software development process called Scrum.

This paper describes how these three methodologies were used in the development of this application and discusses their respective benefits and drawbacks.

2. Project Background Information

2.1. CustomerThe primary stakeholder for this application is the director of Risk Management at Ent Federal Credit Union. Ent sees this application as a way to improve our own internal vendor management, as well as a tool that could be shared with other Credit Unions to help them with their vendor management concerns. A key requirement for this application was to make it capable of supporting multiple institutions in a software as a service environment.

2.2. Technologies EmployedThe Vendor Management application was built using Visual Studio 2008, .NET 3.5 and the C# programming language. The database for the project uses SQL Server 2005. The application also made heavy use of LINQ (Language Integrated Query), a new Microsoft technology that provided all of the Object Relational Mapping (ORM) for the application.

2.3. ChallengesI actually started this project in September of 2006. Since this was a database driven application, I knew that a key challenge was going to be how to implement the ORM. In 2006, LINQ wasn’t even in beta form, so I went down the path of using CodeSmith™ to generate all of the business objects based directly off of the database. CodeSmith™ is a commercial code generation tool that generates code off of templates. I invested a significant amount of time getting the CodeSmith templates to generate the code from the database exactly how I wanted.

When LINQ came out initially in mid 2007, it changed the impedance mismatch between the code that lives on a database server and the code written with standard programming languages such as C#, in such a revolutionary way that I decided to rewrite the project using LINQ. This was


a setback but in the end was worth the extra time and effort required to learn this new technology.

The biggest challenge for this project was that I picked an application that will actually be used in production by Ent, rather than an exploratory application that I could more closely manage the scope. Because of this, I have spent a lot more time on building the application than I had anticipated.

2.4. DeliverablesThe key deliverables for this master’s project are:

Project proposal (Marjaniemi_ProjectProposal.doc) – The initial project proposal was submitted for the master’s committee approval in September of 2006.

Software Requirements Specification (Marjaniemi_SRS_VendorManagement.doc) – The Software Requirements Specification (SRS) was development in an evolutionary manner, true to the scrum agile principals. The high level features were defined and reviewed with the customer, and then as the project progressed the details of each feature were finalized. The SRS is 15 pages long, contains a listing of all of the high level features, detailed requirements, 5 use cases, actor surveys, and design constraints.

Software Design Specification (Marjaniemi_SDS_VendorManagement.doc) – The Software Design Specification (SDS) was also development in an evolutionary manner. It contains the high level system architecture, subsystem architecture, database design, and class designs. The SDS is 29 pages long.

The Vendor Management Software Application – The vendor management software application is composed of 7 visual studio 2008 projects, and has approximately 17 thousand lines of code.

Final Project Report (this document) and Presentation Materials – The final project report and all related presentation materials were created after the end of the project was completed, however the research on Test Driven Development (TDD), Scrum, and Continuous Integration (CI) was conducted throughout the project.

3. Methodologies EmployedOne of the more interesting aspects of this project was the research and use of three different development methodologies: Scrum, Test Driven Development (TDD), and Continuous Integration (CI).

The following sections give an overview of each of these methodologies and lessons learned from using these methods for this project. In addition, because Scrum and Continuous Integration are both methods that are usually used with development teams, I have included my experience and results of using these methods at Ent on larger projects.

4. Scrum Development Process

4.1. What Problem Does Scrum Attempt to Resolve?Before going into detail on what Scrum is, it helps to have a background on the specific software development problems that Scrum attempts to solve.

In a typical waterfall development process the requirements are fully developed during the first stage of the project, then the design, implementation, verification, and finally software maintenance (see Figure 1).


Figure 1: Waterfall development process.

The waterfall development process requires that accurate detailed up-front requirements can be obtained at the start of the project. For planning purposes it also assumes that you can define accurately how long each phase of the process is going to take.

A fair amount of research has been conducted on the challenges with the waterfall process. From Craig Larman’s book on Agile and Iterative Development: A Manager’s Guide, he cites the following research (Larman, 2004):

In a study of failure factors on 1,027 IT projects in the UK only 13% didn’t fail. Scope management related to attempting waterfall practices including detailed up-front requirements was the single largest contributing factor for failure, begin cited in 82% of the projects as the number one problem…

With virtually all medium to large scale software development projects, uncertainty is inherent and inevitable. The larger the project the more you can expect the requirements to change (C, 1997).


0

5

10

15

20

25

30

35

40

10 100 1000 10000

Requ

irem

ents

Cha

nge

(%)

Project Size in Function Points

Figure 2: The larger the project size, the greater propensity for the requirements to change

In addition to making it difficult to obtain accurate up front requirements, a large study also showed that 45% of the features created from early specifications were never used (Chatzoglou, 1996).

These high failure rates and challenges with capturing up front requirements are the impetus behind agile methods such as Scrum.

4.2. What is Scrum?Scrum and other agile development process attempt to solve the issue of gathering accurate, up front requirements by using evolutionary requirements capture. Requirements evolve over time, as the project progresses and details on features are hashed out. This does not mean that the requirements are forever unbounded or are always changing at a high rate. Rather, most requirements discovery and refinement usually occurs during early iterations.

With Scrum, all of the same phases involved in the Waterfall process are spread out over several iterations in sequence called sprints (see Figure 3Figure 1).


Figure 3: The scrum lifecycle (Larman, 2004)

Scrum contains the following characteristics:

Time boxed iterative development – A project is broken down into a series of Sprints, each of the same duration (usually 30 days). Each sprint ends with a working version of the software.

Evolutionary requirements – Unlike the typical waterfall development process, Scrum utilized evolutionary requirements capture where the requirements evolve over time as the project progresses.

Evolutionary and adaptive development – The development of the software evolves over time and adapts in response to feedback from prior Sprints.

Frequent client review – With Scrum the client reviews the software after each Sprint and provides feedback for the next Sprint.

Management best practices – Scrum includes a couple of management best practices, such as the daily Scrum meeting which is used to identify any impediments that need to be removed and to get all of the developers on board. Other management techniques such as the sprint planning cycle, sprint backlog, and product backlog are utilized in Scrum. These management techniques are discussed in more detail later.

4.3. How Scrum Was Used On This Project?The Vendor Management project was not the best way to test out Scrum and reach some conclusions on the benefits of this approach for the following reasons:

There was only one developer on the team, so the team collaboration and team dynamics would not come into play.

The amount of time I was able to reserve each month to work on this project was erratic. Some months I was able to devote a lot of time, and others I was not able to devote much time at all. This made it difficult to plan what features could be delivered in what sprints.

For the Vendor Management project I was able to utilize the sprint backlogs and product backlog to prioritize features and organize development. The requirements were also captured in an evolutionary fashion as well as the design.


However, to come up with accurate conclusions on the effectiveness of Scrum, instead I would like to draw on my experiences with using Scrum on a large project at Ent.

4.4. Experience with ScrumIn October of 2006 Ent decided to use Scrum for the largest and most complex development project Ent has ever embarked on, building an online banking web site for our corporate and business members that have specific online banking needs that differ from our consumer members, such as tiered authority, an approval mechanism, and account aggregation.

The project development team included three experienced developers, I as the scrum master and manager of the development resources, a project manager, a host of stakeholders, and various staff for performing QA.

True to the Scrum methodology, the project started with building the product backlog, which is a list of features for the new product. This backlog was then prioritized by the stakeholders (see Figure 4).

Figure 4: Product backlog example

We then took a more detailed look at some of the high priority, and high risk features first. Scrum advocates tackling some of the higher risk features of a product in order to reduce the overall risk of the project. With this first set of features we moved to the sprint planning stage. The first part of every scrum cycle includes a sprint planning stage which is usually about a 4 hour meeting where the developers take an initial guess at estimating each of the features. This estimate, combined with an accurate estimate of how many hours each developer has to dedicate to the project, are used in the sprint planning cycle to decide on what features are going to be developed during the cycle. This information goes into the sprint backlog (Figure 5).


Figure 5: Sprint backlog example

Every morning at 8:05 sharp we conducted the Scrum daily meeting. Scrum is very strict about starting this meeting on time and keeping it to just 15 minutes. This is to make the meeting as efficient as possible, and allow the developers to quickly get back to developing rather than wasting their morning in a status meeting.

The Scrum daily meeting is a standing meeting, literately. Each member of the team has to stand during the meeting to facilitate keeping the meeting as short as possible. Another mechanism for keeping the meeting short is to have very specific rules on dialog during this meeting. During the meeting each developer is asked the following questions:

What have you done since the last daily Scrum meeting? What impediments are getting in your way of meeting the sprint goals? What will you do between now and the next Scrum meeting?

The developers and the Scrum Master are the only ones allowed to talk, and conversation is limited to these three questions.

During the course of the Scrum cycle, developers are asked to update their estimates for each feature. The estimates can go up if necessary and do not always need to go down. This facilitates getting accurate estimates. These estimates are used for the sprint burn down chart to determine if the team is going to meet the sprint goals.


Figure 6: Sprint burn down chart.

The goal at the end of the sprint is to give a functional system to the end user to try out, even if it has minimal features. If everything is going well, the sprint burn down chart should have a regression line that intersects with the X access before the last day of the sprint. If during the middle of the sprint cycle, it is determined that a couple of features are taking longer than anticipated, other features in the sprint are removed and not started in order to make sure at the end of the sprint the system builds and is functional.

Delivering a working system, even with minimal features, to the client that so they can visualize and manipulate it, fosters feedback from the client as soon as possible, and shows progress. As the project progresses, future sprint cycles include more testing as the features mature. This spreads the testing of the product over the duration of the project rather than cramming testing at the end.

Another key feature of Scrum is having the developers demo each sprint release to the clients. This has a couple of advantages:

It motivates the developers to have an impressive product to demo. Close contact between the developers can and the clients, fosters a better end product. The morale of the developers is very high because they received a lot of positive attention from

the clients.

For our sprint demos we soon had a standing only crowd of people wanting to see the latest and greatest that the development team created.

4.5. ConclusionsAt Ent, the productivity of the development team was phenomenal. Within three sprint cycles we had a basic working web site, which is amazing considering the complexity of the project. As the scrum master, I removed any impediments which kept the amazing momentum of the developers going. However, after about the fourth sprint cycle we started running into issues.

After each sprint we installed the latest iteration of the site onto a test server to allow the clients and testers to start testing the application. At Ent we do not have professional testers that are dedicated to just testing software. We utilize staff that have other duties and have them test the


site when they have free cycles. We always got good feedback from the testers and very few reports of defects. After the fourth cycle we started realizing that the testers were not really testing the application, and were just looking at the features. Once the testers started actually testing the application, we started getting defect reports on features that were delivered a couple of sprints back. By the time we got to the fifth sprint cycle the majority of the cycle was spent fixing defects.

This had a negative impact on the team, as we were no longer turning out new features as fast as before. We also lost some efficiency as the developers were getting defects on features they had developed a couple of months back.

We also had some issues with requirements. We worked very closely with the clients to evolve the requirements to get an accurate description of what they needed, however very few details of these requirements were ever documented. This had a negative impact in that when we had to resolve issues and needed more details on the requirements that were decided, we often had to review emails and look through meeting minutes to find information on the agreed upon requirements.

Overall the project was a success, and after 6 months (or six sprint cycles) we were able to pilot the web site for a select number of members. However the loss of momentum from resolving defects that should have been found earlier in the process, and the lack of documented requirements, did negatively impact the project and impression of Scrum among management. Based on my own experience I found a great benefit with using Scrum, but what does the research say?

Most research on this subject is centered not specifically on Scrum, but the agile methods that Scrum encompasses. One study based on a two-year in depth analysis of projects came to the conclusion that there was evidence that the evolutionary approach to software development results in a speedier process and higher-quality products (MacCormack, 2001). However the same study indicated that if the customer needs are well known with certainty, the waterfall model suffices.

A follow up study by the same authors found that releasing a partial version of a system earlier in the process (as Scrum dictates by releasing a functional product every 30 days) resulted in a decrease in the defect rate (MacCormack, Kemerer, Cusumanu, & Crandall, 2003).

In a study conducted at Bell Labs of productive software organizations, the following common patterns for highly successful projects were identified(Harrison & Coplien, 1996):

Iterative development with customer evaluation and feedback each iteration. Simple organizational structure; fewer roles than average. Even distribution of communication among people, more direct involvement of developers with

other stakeholders, and more overall communication sharing

Scrum includes all of the above patterns. The Scrum sprint cycles provide the iterative development and early customer evaluation. The Scrum philosophy of not having a hierarchy among the developers and just having one Scrum master facilitates the simple organization structure. And the Scrum daily stand up meeting facilitates communication.

Lastly in a large study illustrating the value of iterative-related practices, one of the top factors that had a strong correlation to project success was small milestones, which is at the heart of the Scrum concept of 30 day sprints (Johnson, 1998). To quote the study:


We have long been convinced that shorter time frames, with delivery of software components early and often, increase the success rate. Shorter time frames foster an iterative process design, prototype, develop, test, and deploy small elements. “Growing” (instead of “developing”) software engages the user earlier and confers ownership.

5. Continuous Integration (CI)

5.1. What Problems Does Continuous Integration Attempt To Solve?Continuous integration is an attempt at solving the often painful process of multiple developers or teams integrating their separate components. Often this happens late in the development process and can add significant delays. Integration can also be painful since it is often unpredictable. If multiple systems are brought together to be integrated it is hard to determine how much time will be necessary to resolve all of the conflicts.

5.2. What Is Continuous Integration?Continuous integration solves this problem by integrating often, sometimes as soon as new code is checked in. The building process is often automated (however you can do continuous integration manually) so that if a developer checks in new code, they will get notification if it breaks the build. This shortens the time it takes to resolve integration issues, as the developer knows that the issue probably is in the code they just checked.

Some continuous integration implementations take this a step further and even run automated tests and static source code analyzers (such as FxCop) as soon as code is checked in. If new code is checked in and a test breaks, developers know that where to look to resolve the failed test.

There are a number of best practices to consider when implementation Continuous Integration (Fowler, 2006):

Maintain a single source repository – Keeping track of multiple source control systems can greatly complicate the process.

Automate the build – This saves resources from having to manually build the code. An automated server can also notify soon after a check in if the new code caused an issue.

Make your build self-testing – Just because code is compiling doesn’t always mean everything is OK. Running automated test after each build will also further signify that recent changes have not broken any existing functionality.

Everyone commits every day – If developers are not frequently checking in their code, they could still have large integration problems.

Every commit should build the mainline on an integration machine – Demonstrates that the mainline was not adversely affected by the recent check in.

Keep the build fast (under 10 minutes) - If users are waiting more than 10 minutes there is a loss of efficiency, especially if they are waiting for the deployment package to install on test.

Test in a clone of the production environment – Makes the tests more accurate. Make it easy for anyone to get the latest executable – Facilitates installing the latest

deployment. Everyone can see what’s happening – Shows progress if the teams status, and highlights issues. Automate deployment – Facilitates the installation of the latest build.


5.3. How Continuous Integration Was Used On This ProjectAgain like Scrum, the Vendor Management project was not the best way to test out Continuous Integration since I the only developer on the project and I was not actually integrating my code with anyone else. Still, I was able to setup the project in a Continuous Integration (CI) environment. I then applied this knowledge and setup of CI at Ent and was able to draw some conclusions from our experience by using CI for many projects.

The Continuous Integration build server I selected was CruiseControl.NET. CruiseControl.NET is an open source Continuous Integration build server that is very configurable. Its configurability is a blessing and a curse. It took me over 60 hours to get the CruiseControl.NET to build a .NET project, run the test cases, run FxCop, notify of any issues, and if everything was successful build a .msi executable to deploy the project. Most of this work was spent creating the various build scripts, customizing CruiseContro.NET, and debugging issues.

Figure 7: Screen shot of the Vendor Mgmt build in the CruiseContro.NET system tray application

5.4. ConclusionsBefore we started using Continuous Integration at Ent, we had situations where a developer would go on vacation and an issue would occur with production with an application the developer was recently working on. We would then go into our Source Configuration Management (SCM) system, retrieve the latest code only to find the project doesn’t compile. Most often the issue was that a project file or dependency was not checked into source control, and was just locally resident on the developer’s workstation. The basic problem was that our SCM system did not accurately reflect the code that was on production.

With CI using an automated build server, the SCM system does reflect the code that is on production since the automated build server deletes all local files, gets the latest from the SCM system, and then builds the solution. It then labels the build with a specific build number and builds an installation .msi file. This resulting .msi file is what is used to install on production. All of the compiled .dll’s version numbers contain this build number so at any point you can trace what is on a production server to the specific build on the CI server. The SCM system is also labeled with this unique build number so that at any point you can retrieve or view the code for that specific build.

Any pain of configuring and setting up CruiseControl.NET has been returned in reduced integration issues, a cleaner more accurate SCM environment, and easier deployment.


In my research I also found evidence that suggested by using CI practices the net result was a reduced defect rate (MacCormack, Kemerer, Cusumanu, & Crandall, 2003).

6. Test Driven Development (TDD)

6.1. What Problems Does TDD Attempt To Resolve?Most code follows the lifecycle where it starts out well organized and well designed. Throughout the lifecycle as new functionality is added and defects are fixed, the original design starts to degrade. Overtime the code gets harder and harder to maintain and eventually gets to the point where the entire system needs to be refactored because it is turning into a maintenance nightmare. It usually is cost prohibitive to do such a massive rewrite.

Test Driven Development attempts to resolve issue by promoting small refactorings of the code through the product’s life.

6.2. What is TDD?Test Driven Development (TDD) is the process where a developer first writes a test that covers the desired improvement or new functionality, than implements the code. This is repeated in short iterations. TDD uses the following simple mantra (Beck, 2003):

Make it fail. Make it work. Make it better.

TDD requires some type of automated testing framework, such as MSTest or NUnit. This is how a developer would start developing some new functionality using TDD:

First, create a test for the new functionality. Run all the tests and see the new one fail. If the test doesn’t fail, there is something wrong with

the test. Implement just enough code to minimally meet the new functionality requirements and pass the

test (also called make a little change). Run all the tests and watch them succeed. Refactor to remove duplication and repeat.

Since designs degrade over time, by having automated unit tests it supports small refactorings throughout the lifecycle of the code. By building a test first, the programmer is also in a sense, documenting the requirements, because the process of building the test requires the developer to understand what the code is supposed to do. Building the tests also exercises the interfaces and actually becomes part of the design process.

The intended result is better code, better tests, and better designs.

6.1. How TDD Was Used on This Project?After researching and reading about TDD, and attempting to use it on previous projects, I felt I was more than prepared to use TDD in earnest on this project. I am also very familiar with building programmatic unit tests using MSTest within the Visual Studio environment.

When building non UI related elements, in particular the services layer, I used the TDD approach. I first built the interfaces with no implementation behind them (these were necessary to build the test). I then built a test case that exercised these interfaces. I found that during this process


of calling the interfaces, I often changed the interfaces after writing the test cases that exercised them. From this regard, I can understand how TDD is considered part of the design process.

I would then run all of the test cases to make sure that the new test case would fail. This process was very interesting because in the end I found that this made my test cases more accurate. It forced my test cases to not only just call the new code, but to also make sure that the new code was actually doing what it was supposed to. In my previous experience with building programmatic unit tests it was an easy trap to get lazy and just call the code in some cases, expecting it to throw an exception if an error occurred. By making sure that the test properly fails first, before implementing any code, TDD made unit tests better that just building the unit test after the code.

The next step was to write enough code to successfully pass the test. I would then go back and update the test case to test a new aspect of the functionality that I know I had not taken into account yet. I would then repeat the cycle.

Here is a more concrete example of how I built test cases for this project when building the logon and authentication functionality for the Vendor Management application.

I first created a UserService component with the necessary methods (such as LogOn, etc). I then created the initial test case:

The first time I ran this application it correctly failed, since I had not yet implemented the UserService.LogOn method.

I then implemented the LogOn method, and after a couple of iterations I got the test to pass. I then wanted to try and test logging on with an invalid username, so I updated the test case.


The test failed, because I had not correctly coded the UserService.Logon method to handle a failed logon. I updated the code, and after a couple of iterations the failed logon code was implemented and working. I kept with this cycle until the test case grew to around 100 lines of code.

6.2. Conclusions For testing non UI components I found that I easily got into the cadence of creating test, make sure it fails, build a little code, making the test pass, and then refactoring to remove duplication. Because building the test case was part of the design process, I didn’t get the impression I had lost much efficiency from using TDD. Building the test also helped solidify the requirements before I even had them solidified in the requirements document.

However I did have some challenges with TDD. Because this is a database driven application, many of my tests had a fair amount of work in setting up the database state so that I could create a test. For example, for testing the logon process, I first had to create a user to logon with. This wasn’t very difficult, but in later tests I had to setup a lot of database objects which incurred a decent overhead when creating the tests. I also had to be careful to clean up after my tests and to leave the database in an unchanged state. Eventually I found out how to best do this using database transactions and rolling back any changes.

The biggest detriment to fully utilizing the full potential of TDD was that I could not create tests for user interface (UI) elements. With LINQ creating all of the business entities, my tests were


mainly at the services layer. As far as lines of code, the services layer of my project was only about 25% of the total codebase. The rest of the code was UI controls, pages, page flows, responding to page events, etc. None of these UI elements benefited from TDD because the control flows were married to the user interface.

I did find that what code was developed using TDD was of a higher quality and had fewer defects; however this came at a cost of spending the extra time development the unit tests. Although I had no empirical evidence my impression was that the extra time taken to use TDD was recouped in having fewer defects. I found some research that corroborated this.

In a study done at Microsoft they found that code created using TDD was significantly higher in quality at a cost of taking 15% extra upfront time for writing the tests (Bhat & Nagappan). Another study of using TDD at three different companies (John Deere, RoleModel Software, and Ericsson) came to the conclusion that TDD developers produced higher quality code at a cost of 16% more time required for development.

7. Summary of ConclusionsI found that Scrum is a very useful lightweight agile process and has many advantages over the typical waterfall process, for large projects with a high level of uncertainty. However some of the formal deliverables of the waterfall process, such as solid documented requirements, test plans, test cases, are all still very necessary. Some constraint should be shown when diving head first into Scrum because it is very different from the traditional waterfall method. In my experience, I found that even though I had communicated to all parties how Scrum works and is different from traditional methods, I found that our testers were still expecting to test the product near the end of development, just like the waterfall method.

The increasing amount of new automated build tools makes it easier than ever to setup a Continuous Integration (CI) environment. CI is a definite success with few negatives. There is a decent amount of effort in getting the build environment setup correctly, however new CI tools and software in the future should reduce this initial investment.

Test Driven Development (TDD) does help the design process and facilitates the creation of better test cases; however it is only realistic for non user interface related components. There is also some difficulty in setting up test cases that use relational databases. With regard to the Vendor Management application where the majority of the functionality was in the UI, TDD did not help for most of the code. Future technologies such as the implementation of the Model-View-Controller (MVC) software pattern in ASP.NET, which separates the UI control logic into separate components, could facilitate more TDD for heavy applications with a lot of UI.

8. Works CitedBeck, K. (2003). Test-Driven Development: By Example. Addison Wesley.Bhat, T., & Nagappan, N. Evaluating the Efficacy of Test-Driven Development: Industrial Case Studies. Chatzoglou, P. (1996). Requirements Capture and Analysis a Survey of current practice. Requirements Engineering Journal.Chirasrota, J. (2007, October 6). Vendor Management Is A Major Issue Facing Indian Banks. Retrieved from http://www.tech2.com/biz/india/news/bfsi/vendor-management-is-a-major-issue-facing-indian-banks/9621/0Fowler, M. (2006, May). Continous Integration. Retrieved from MartinFowler.com: http://martinfowler.com/articles/continuousIntegration.htmlGeorge, B., & Williams, L. (2003). An Initial Investiation of Test Driven Developmeng in Industry.


Gu, S. (2007, October 14). ASP.NET MVC Framework. Retrieved from ASP.NET MVC Framework: http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspxHarrison, N., & Coplien, J. (1996). Patterns of Productive Software Organizations. Johnson, J. (1998). ChAOS: A Recipe for success. The Standish Group.Jones, C. (1997). Applied Software Measurement. McGraw Hill.Larman, C. (2004). Agile and Iterative Development: A Manager's Guid. Addison Wesley.MacCormack, A. (2001). Product-Development Practices That Work. MIT Sloan Management Review.MacCormack, A., Kemerer, C., Cusumanu, M., & Crandall, B. (2003). Exploring Trade-offs between Productivity & Quality in the Selection of Software Development Practices. IEEE Software.

vender management sdscs.uccs.edu/~gsc/pub/master/cmarjani/doc/vendor... · web viewcontinuous...

Documents