1. Prepared by Yelda ErdoanSupervised by Egemen zdenBaheir UniversityGraduate School of Natural and Applied SciencesEngineering ManagementMaster of Science Project

2. Contents Introduction Overview of Software Development Models Predecessors of Agile Development by Examples Software Testing Traditional Testing Process Test-Driven Development Testing in Agile Software Development Application Data and Method Result and Discussion Conclusion References 3. Introduction There are two mainstream methodologies which aretraditional and agile software developmentmethodologies in the software development world. People started to find these steps heavy. Industryveterans demanded lighter processes that can be easilyfollowed. A group of industry experts calling them theAgile Alliance came together in 2001. (TDD) will be discussed. The TDD Cycle and mantragive importance testing, when there is no written code.Moreover the TDD has core place communicatingcustomer, business, and software project teams. 4. Introduction Cont. Traditional software development employs extensivefacilities and methods to make sure that the final productmatches the requirements defined at the beginning of theproject. Software testing is placed at the end of the traditional wayof software development. On the other hand newlightweight methodologies have emerged in the last decadeand contradicting the traditional way, these agilemethodologies increasingly focus on software testing. TDD methodology software testing is even used as anintegral part of the design process. 5. Overview of SoftwareDevelopment Models Evolution of the SDLC has been continued for it wasstarted. Software is very major and important item in systems.Software development is originated in defensesystems. Spending money for software is growth very importantportion. It was claimed that 12% for a year in 1980s by(Humphrey, 1989). Software often adversely affects theschedules and effectiveness of weapon systems. Quality and maturity has become subject in softwaredevelopment. 6. Overview of SoftwareDevelopment Models - Cont. Waterfall, the first known presentation describing useof similar phases in software engineering was held byHerbert D. Benington at Symposium on advancedprogramming methods for digital computers on 29June 1956 7. Overview of SoftwareDevelopment Models - Cont. Waterfall was draw by (Royce, 1970) A model of the softwaredevelopment process in which theconstituent activities, typically aconcept phase, requirements phase,design phase, implementationphase, test phase, and installationand checkout phase, are performedin that order, possibly with overlapbut with little or no iteration.Contrast with: incrementaldevelopment; rapid prototyping,spiral model. (IEEE, 1990) 8. Overview of SoftwareDevelopment Models - Cont. Gerald M. Weinberg suggested Egoless Programmingthat suggests more technical review, more preventiveapproach in software development on 1971 in(Weinberg, 1998). In 1974, SDLC was described in seven steps by(Wolverton, 1974). 9. Overview of SoftwareDevelopment Models - Cont. 10. Overview of SoftwareDevelopment Models - Cont. Barry B. Boehm suggested spiral model for the softwaredevelopment process in the International Workshop on theSoftware Process and Software Environments on 1986. Spiral model was presented as a candidate for improvingsoftware process model situation. The major distinguishingfeature of the spiral model is that it creates a risk-drivenapproach to the software process rather than a primarilydocument-driven or code-driven process. (Boehm, August1986). In that case risk management is started being veryimportant place in projects. 11. Overview of SoftwareDevelopment Models - Cont. Boehm indicates that a typical cycle of thespiral is described that each cycle of thespiral begins with the identification of The objectives of the portion of theproduct being elaborated (performance,functionality, ability to accommodatechange, etc.); The alternative means of implementingthis portion of the product (design A,design B, reuse, buy, etc.) The constraints imposed on theapplication of the alternatives (cost,schedule, interface, etc.). 12. Overview of SoftwareDevelopment Models - Cont. Spiral Model is described as: A model of the softwaredevelopment process in which the constituentactivities, typically requirements analysis, preliminaryand detailed design, coding, integration, and testing,are performed iteratively until the software iscomplete. Contrast with: waterfall model. (IEEE, 1990) 13. Overview of SoftwareDevelopment Models - Cont. DOD-STD-2167A Military Standard: Defense System SoftwareDevelopment was published on 1988. Standard suggests waterfall software development model.Following statement has conflict because of strictly respectproject schedule with formal reviews and audits even if iterativedevelopment selectioneach CSCI shall be compatible with the contract schedule for formalreviews and audits. The software development process shall includethe following activities, which may overlap and may be appliediteratively or recursively:System Requirements AnalysisSystem Design,Software Requirements Specification,Preliminary Design,. 14. Overview of SoftwareDevelopment Models - Cont. ISO/IEC 12207 was published in 1995 in first time.IEEE/EIA 12207.0 was published on 1996 in first time. Intime, they merged in one standard as ISO/IEC 12207-2008.The standard states respectively in 6.1.2.3.4.8 and 7.1.1.3.1section that following:The supplier shall monitor and control the progress and thequality of the software products or services of the projectthroughout the contracted life cycle for an ongoing, iterativetask Software implementation strategy related activities and tasksmay overlap or interact and may be performed iteratively orrecursively. 15. Overview of SoftwareDevelopment Models - Cont. Agile Alliance published Manifesto for Agile SoftwareDevelopment besides twelve principles in February 2001which are given below: (2001) Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doingit and helping others do it. Through this work we have cometo value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we valuethe items on the left more. 16. Overview of SoftwareDevelopment Models - Cont. 12 Principles behind the Agile Manifesto1. Our highest priority is to satisfy the customer through earlyand continuous delivery of valuable software.2. Welcome changing requirements, even late in development.Agile processes harness change for the customerscompetitive advantage.3. Deliver working software frequently, from a couple of weeksto a couple of months, with a preference to the shortertimescale.4. Business people and developers must work together dailythroughout the project.5. Build projects around motivated individuals.6. Give them the environment and support they need, and trustthem to get the job done. 17. Overview of SoftwareDevelopment Models - Cont.7. The most efficient and effective method of conveying informationto and within a development team is face-to-face conversation.8. Working software is the primary measure of progress.9. Agile processes promote sustainable development. The sponsors,developers, and users should be able to maintain a constant paceindefinitely.10. Continuous attention to technical excellence and good designenhances agility.11. Simplicity--the art of maximizing the amount of work not done--isessential. The best architectures, requirements, and designsemerge from self-organizing teams.12. At regular intervals, the team reflects on how to become moreeffective, then tunes and adjusts its behavior accordingly 18. Predecessors of Agile Developmentby Examples Agile software development became popular beginningof this century. People perceive agile as new, modern,and replacement of waterfall model. Although it is anew approach, there are some predecessors. In time,there were some projects that executed by usingiterative and incremental development (IID).1950 IID X-15 hypersonic jet (not just sw project)1960 Project Mercury ran with every short, half-day, iterations. TR for every changes by conducting all team members, writing testbefore development1972 IBM FSD application with IID, majorly documented1972 TRW Ballistic Missile Defense project with IID1977 - 1980, IBM FSD built NASAs space shuttle software was an application of IDD.1977 - 1980, System Development Corp. built an air defense system was an application of IDD1982- IBM built military command control project using evolutionary prototyping1987- TRW launched a four-year project to build the Command Center Processing and Display System Replacement, a command andcontrol system, using IID methods 19. Software Testing Software test is an activity in which a system orcomponent is executed under specified conditions, theresults are observed or recorded, and an evaluation ismade of some aspect of the system or component. Software test activity is conducted to find bugs andfaults in order to have software product meetscustomer needs. It is expected that bugs and faults are fixed in adequatetime such as before customer acceptance. 20. Software Testing Cont. Test results provide information on degree of meetingsystem requirements which are expected by customerin quality manner. Software test activity has interaction within softwaredevelopment life cycle. Finding bugs in early stage ofsoftware development life cycle is very important. 21. Software Testing Cont. In one of traditional andvery old approachwaterfall softwareproduct development,test activity is executedafter requirementallocation, designallocation and coding. 22. Software Testing Cont. Other traditional respectivelynew approach is V modelwhich based on verificationand validation concept. While a phase is executing,testability of items areconsidered. For example, in requirementspecification phase, whilerequirements are specifiedtheir testability is considered.Related test cases areprepared and documented.Execution of test cases isperformed later. 23. Software Testing Cont. Importance of early phase bug fix The more bugs you can fix immediately, the lesstechnical debt your application generates and the lessdefect inventory you have. Defects are also cheaper to fix the sooner they arediscovered. The cost to fix an error found after product release wasfour to five times as much as one uncovered duringdesign, and up to 100 times more than one identified inthe maintenance phase. 24. Software Testing Cont. The cost to fix anerror found afterproduct release wasfour to five times asmuch as oneuncovered duringdesign, and up to100 times more thanone identified in themaintenance phase. 25. Software Testing Cont. Verification and validation by Boehm in 1979: Verification: "Am I building the product right?" Validation: "Am I building the right product? Verification and validation is the name given to thechecking and analysis process that ensure thatsoftware conforms to its specification and meets needsof the customers who are paying for that software 26. Software Testing Cont. Static testing is a test activity without executing thecode with reviews, walkthroughs and inspections. Items which are subjected to review can be documentsor code. For example syntax correctness and code complexityanalysis. By using static testing method faults can be found inan early phase of software development because thetesting can be started before any code is written. 27. Software Testing Cont. Dynamic testing is a test activity that executing codewith a set of test cases. In dynamic testing, test activities are started almostcode writing finalized. Static testing and dynamic testing are opposite of eachother. 28. Software Testing Cont. Functional test is a testing activity that intends toverify that behavior/action/activity of the software testitem as specified for software system. Features of software system are verified regardingentered inputs and expected outputs. The concept of functional testing is quite similar to allsystems, even though the inputs and outputs differfrom system to system. 29. Software Testing Cont. Non-functional test is a testing activity that intends toverify quality attributes of software test item asspecified for software system. Some quality attributes are usability, security,portability, reliability, performance, stress, load,maintainability, modularity, etc. Non-functional tests are executed case based. Testoutputs gives information about product quality. 30. Software Testing Cont. White-box test is to verify the correct behavior ofinternal structural elements. When code is known andaccessible for testing activity and code is inspectedinternally, line by line, white-box test activity isperformed. Black-box test is to verify software item works asspecified when software under test by given inputs.Software item is seen as a closed box. Onlyfunctionality/feature is known. Gray-box test is a hybrid approach using both white-box and black-box test. 31. Software Testing Cont. The objective for any review meeting is to identifyproblems with the design. It is not to solve them. Review meetings should be small (about sevenpeople). They should include people who did not workon the design. Reviewers should read design documents in advanceand challenge or question them in the meeting. Many companies dont consider a design completeuntil it is approved in a formal review. A design isreworked and re-reviewed until it is finally abandonedor accepted. 32. Software Testing Cont. Three common types of review meetings (Kaner, et al., 1999): Walkthrough:The designer simulates the program. She shows, step by step, what theprogram will do with test data supplied by the reviewers. The simulationshows how different pieces of the system interact and can exposeawkwardness, redundancy, and many missed details. Inspection:Reviewers check every line of the design against each item in a checklist.An inspection might focus on error handling, conformity with standards,or some other single, tightly defined area. If time permits, an inspectionchecklist might cover a second area of concern. Technical Review:Reviewers bring a list of issues to the meeting. During the meeting, theydescribe their objections and point out things that are ambiguous orconfusing. The purpose of the review is to generate a list of problems andmake sure that the designer understands each one. Deciding whatchanges to make, and designing them, are not part of this meeting 33. Software Testing Cont. Generally software testing is divided into unit testing,integration testing, system testing, and acceptancetesting regarding aim and objective of testingactivities. Test levels activities are performed in softwaredevelopment and maintenance phases. 34. Software Testing Cont. 35. Software Testing Cont. Verification of low level design is performed mostly inunit testing activity. Unit testing activity is the very effective test level inorder to find failures in early phase of the softwaredevelopment. At the end of unit test phase, verifiedunits are ready for system testing 36. Software Testing Cont. Verification of high level design is performed mostlyin integration testing activity. At the end of integrationtest phase, verified subsystems are ready for systemtesting. 37. Software Testing Cont. Verification of system requirements is performedmostly in system testing activity. At the end of systemtest phase, verified software system is ready foracceptance testing. 38. Software Testing Cont. Software system is tested whether meets customersrequirements. The main idea of acceptance testing issoftware system evaluation in terms of customerexpectations within installed/deployed environment 39. Software Testing Cont. Regression testing activity mostly is performed afterbug fixing. Purpose of regression testing is to ensurethat software part is functional in conformance withspecified and expected after bug fix activity. Regression testing can be performed in every testingphase in software development. 40. TraditionalTestingProcess 41. TDDThe test-driven development (TDD) is described in(Beck, 2002):In Test-Driven Development, you: Write new code only if you first have a failing automated test. Eliminate duplication. The motivation of TDD is second value of Manifestofor Agile that Working software over comprehensivedocumentation. Writing tests first help definefunctionality, a key task of software development. 42. TDD Cont. TDD was named as Test First Programming in thebeginning. Tests are considered first. Tests areprepared in user perspective, run and usually failedbefore coding because of there is no lacking code. 43. TDD Cont. TDD can also extend beyond the unit or developerfacing test. There are many teams that use customerfacing or story tests to help drive coding. These testsand examples, written in a form of understandable toboth business and technical teams, illustraterequirements and business rules. Customer facingtests might include functional, system, end-to-end,performance, security, and usability tests.Programmers write code to make these tests pass,which shows the product owners and stakeholdersthat delivered code meets their expectations. 44. TDD Cont. In TDD a programmers prepare automated unit teststhat define code requirements then immediatelywrites the code. The tests include assertions that areeither true or false. Passing the tests confirms correctbehavior as developers evolve and refactor the code.Programmers mostly use testing frameworks, forexample JUnit, in order to create and automaticallyrun sets of test cases. TDD approach is about specification of needs and/orfunctionals rather than validation. 45. TDD Cont. TDD cycle sequence Quickly add a test Run all tests and see thenew one fail Write code and make alittle change Run all tests and see themall succeed Remove duplication byrefactoring 46. TDD Cont. Quickly add a test Test is written by programmer for every new feature or functionality.New feature or functionality is clearly understood by programmer.In this stage programmer focuses on requirement. Run all tests and see the new one fail Prepared tests are run and failed. Write code and make a little change Code is written or changed by developer regardless to test. Run all tests and see them all succeed All prepared and updated tests are run until successfully passed. Remove duplication by refactoring In this stage code is cleaned, duplications are removed, someinternal changes are done. Changes do not affect code functionality. Refactoring is changing code, without changing its functionality, tomake it more maintainable, easier to read, easier to test, or easier toextend. 47. TDD Cont. TDD Mantra gives tasksperformed during TDD Cycle: Red write a little test thatdoesnt work perhaps doesnteven compile first. Green Make the test workquickly, committing whateversins are necessary in theprogress. Refactor Eliminate all theduplication created in merelygetting the test to work. 48. TDD and DesignCode for tomorrow, design for today. TDD is not about just testing activity. By using TDD,software system is detailed in the smallest part whichis units. Software units are detailed by consideringfunctionality. Design activity is performed in that case. User stories are gathered. Every story is investigatedregardless functions. By the way, software system isdesign in very low level. Code implementation is doneby applying TDD. If any inadequate situation such asfailures will appear in following phase, then failurescan be traced back. 49. TDD and Automation The test-driven development approach requires writingautomated test prior to developing functional code insmall, rapid iterations. Test automation is core agilepractice. Agile projects depend on automation. Goodpractice of automation provides teams in compliance withworking framework. Source code control, automated buildsand test suites, deployment, monitoring increasefunctionality, and quality of product. Tests are new documentation. Moreover, they are livingdocument about how a piece of functionality works. WhenTDD process is in green, and then refactor, updateddocumentation exists. Besides, code is updated in everytime. 50. Testing in Agile SoftwareDevelopment Purpose of software testing still has as same goal astraditional software testing is that finding failures ofsoftware in order to have reliable software product.Main characteristic of agile testing is that test activityis started consideration almost in the beginning of thesoftware development. In agile test, there are two roles in developmentprogrammer and tester. 51. Testing in Agile SoftwareDevelopment Cont. Purpose of software testing still has as same goal astraditional software testing is that finding failures ofsoftware in order to have reliable software product.Main characteristic of agile testing is that test activityis started consideration almost in the beginning of thesoftware development. In agile test, there are two roles in developmentprogrammer and tester. 52. Testing in Agile SoftwareDevelopment Cont. Agile testing quadrantsshows how each of the fourquadrants reflects thedifferent reasons testing. On one axis, matrix isdivided into tests thatsupport the team and teststhat critique the product. The other axis dividesthem into business-facingand technology-facingtests. 53. Testing in Agile SoftwareDevelopment Cont. In Quadrant 1 and 2;supporting developmentteam is the main objective. Units, components and thehigher level parts ofsoftware system are testedautomated except GUI andthese tests supportsdevelopment teams. Quadrant 1 and 2 arerelated more requirementspecialization and designaids. Tests are runautomated in all codechange and addition. Testsguide development infunctionality. 54. Testing in Agile SoftwareDevelopment Cont. In Quadrant 3 and 4; critiqueproduct is main objective. Gathered customerrequirements should beunderstood by programmers. Critique product shouldinclude praise andsuggestions for improvement.Product is reviewed inconstructive manner. Tests are run to verify allsystem in every aspect,including quality attributes. Obtained results increaseteam knowledge aboutcustomer requirements.Meeting degree of customerneeds is increased. 55. Testing in Agile SoftwareDevelopment Cont. Quadrant 1 represents test-driven development whichis a core agile development practice: Tests are derived from customer examples. Unit tests are done in order to verify functionality. Component tests are done in order to verify behavior ofsystem. TDD is main test practice. TDD helps programmersdesign code to deliver a storys feature which isintended. Software system functionality is implemented in verydetailed level, in unit and components level. 56. Testing in Agile SoftwareDevelopment Cont. Quadrant 2 supports the work of the developmentteam, in high level. Tests are derived from customer examples. Examples are produced from gathered user stories. Gathered stories are verified. Prototypes and simulations are prepared. They helpprogrammers to understand customer needs. User interfaces are verified. 57. Testing in Agile SoftwareDevelopment Cont.Major objective of Quadrant 3 is to find the most seriousbugs. Tests are performed to ensure whether customerneeds are understand. Misunderstandings are removed byusing examples. At the end of UAT, most of stories arefinalized. User acceptance test (UAT) is mostly performed by usersand customers. With UAT execution, customer still has chance to claimnew features and also future expectations. Gathering requirements are continued in this phase. Gathering information from focus group is also continued.It provides advantages in usability test execution. Defined constraints are tested in exploratory testing phase. Also, each story and scenario is tested in exploratorytesting phase. New scenarios are considered. Test results are analyzed. 58. Testing in Agile SoftwareDevelopment Cont. Quadrant 4 tests are intended to critique quality attributesof product such as performance, robustness, robustness,and security. Customer requirements can be specified as functional andnon-functional requirements. When requirements areprioritize, non-functional requirements might be moreimportant than functional requirements. For example,most of functional requirements are implemented,sometimes absence of one non-functional requirement,such as security might be more critical for customer. InQuadrant 4, tests help to specification all kind offunctional requirements are met. 59. Application Data and Method A real world scenario is implemented using TDD. TheMonitoring and Control module of a RiskManagement System has been developed using TDDmethodology. The other modules of this riskmanagement system are not implemented in the scopeof this work. 60. Application Data and MethodPROBLEM DEFINITIONA fully functional Risk Management application may have thefollowing modules: Risk creation, classification, responsible definition userinterface, Mitigation Plan/Contingency plan creation user interface, Risk Impact Analysis module, Activity Reporting interface, Monitoring and Control module, Warning publishing module, to send E-mails or integrated withthe office productivity suite.The focus of this work is the implementation of test modules andthus developing the "Monitoring and Control" module accordingto these tests developed. The "Monitoring and Control" moduleis implemented at a basic level to provide enough memberfunctions and variables to cover the tests defined, leavingdetailed functionality incomplete. 61. Application Data and MethodREQUIREMENTSSix major requirements were gathered for the "monitoring andcontrol" module, these requirements are as follows: Risks with "HIGH" classification should be monitored weekly. Awarning should be published to the user for each monitoringrequest. Risks with "MEDIUM" or "LOW" classification should bemonitored upon milestones. A warning should be published tothe user for each monitoring request. The risks are to be reviewed on Risk Review Meetings and untilthe risk is reviewed a warning should be published to the user foreach newly identified risk. The risks should have a Mitigation/Contingency plan ready andif not a warning should be published to the user for new risks. A warning will be published to the user if a risk takes place. A warning will be published to the user if the contingency plan,for a risk that has occurred, is executed. 62. Application Data and MethodTEST CASES A total of six tests were designed to cover these sixrequirements. The tests were implemented using the JUnit classes ofJAVA and merged under a single test suite. 63. Application Data and Method The JUnit classes and the "Monitoring and Control" class 64. Application Data and Method "new_risk_introduced_case" test case: In this test case the monitoring and control module is testedagainst the emergence of a new risk. The module issupposed to publish a warning and set a warning publishedflag. The test checks for this flag to be true. "new_risk_not_introduced_case" test case: In this test case the monitoring and control module is testedagainst the emergence of a new risk. The module issupposed to not publish a warning when there are no newrisks. The test checks for this flag to be false. 65. Application Data and Method "mitigation_plan_check_test_case" test case: In this test case the monitoring and control module is testedagainst the availability of a mitigation plan for new tests. Themodule is supposed to publish a warning when there are nomitigation or contingency plans related with the risk. The testfails if there is a new risk without a plan and the module does notpublish a warning and set the flag to true. "periodic_risk_warnings_check" test case: In this test case the monitoring and control module is testedagainst the first two requirements. If a risk has a "HIGH" prioritythen the module is supposed to publish weekly warnings for theuser to monitor the risk. If a risk has a "MEDIUM" or "LOW"priority then the module is supposed to publish warnings for theuser upon milestones to monitor the risk. Two separate flags areset for weekly periodic warnings and milestone based warnings. 66. Application Data and Method "identified_risk_takes_place" test case: In this test case the monitoring and control module is testedagainst the occurrence information of the identified risks. Ifa risk occurs the module is supposed to publish a warning tothe user. "plan_performed" test case: In this test case the monitoring and control module is testedagainst the execution information of the contingency plan.If a risk occurs and the plan is put under motion the modulesupposedly publishes a warning for the user to monitor theplan execution. 67. Application Data and MethodAPPLICATION Once the tests were complete the implementation of the"Monitoring and Control" module was started. This module isdesigned to enable the previously defined tests to succeed. The data type "RISK" is developed to match the requirements of thetest functions. The Boolean variables defined in this class are definedto represent the information needed by the test classes. The "Monitoring and Control" module implemented the necessarycalculation and warning functions to match the functionalitydefined in the test classes. This module is designed to call the evaluation function once everyperiod but the calling mechanism is not implemented. The handling of the various flags and the processing of an identifiedrisk are collected in a single function called the "evaluate_risk"function. The periodic processing of this module is supposed to be called byanother mechanism that has not been implemented. 68. Result and Discussion Even though the application being implemented inthis work is not a major one, the aim is to show that bydesigning the tests before-hand; the requirements arebetter matched to the tests and functions. Thispractice enabled the developer to better define thework to be done even when all the requirements arenot known. Upon defining the test cases andimplementing the source code to work with thesetests, even the smallest functions required by theapplication are handled in a result oriented manner. 69. Result and Discussion When all the tests are completed successfully the softwareunder development is guaranteed to cover all therequirements and there is not any chance of leaving arequirement out-of scope. By applying the TDD methodthe software is thoroughly tested at every development stepand this ensures that no unnecessary development isperformed at any point in the development cycle. Althoughthe code is already compact and working, the final step ofTDD is to re-factor the already complete software to havean even better source code. This results in a final collectionof the desired results and removal of any unnecessaryvariables, loops, controls etc. 70. Conclusion It has been observed in this work that softwaredevelopment methodologies are continuously improvingand the developments in the software lifecycle area are farfrom completion. The same critic also stands for thesoftware testing. Also the importance of software testing isincreasingly emphasized by the software methodologiesproposed in the last decade. Software Testing is now notonly an integral part of the software development lifecycle,but also an emerging new way to develop software. Whiletraditional software methodology employs software testingat the end of the development lifecycle, Agile SoftwareDevelopment methodologies evolved to employ softwaretesting from the beginning of development. 71. Conclusion In this work, as the test cases were developed incrementallyto better cover the atomic functions defined by therequirements, it has been observed that the "WorkingSoftware over Comprehensive Documentation" item of theAgile Manifesto holds an important role in the TDDpractice. The software documentation process has beentransformed from intensely writing enormousdocumentation to using up-to-date test functions that areeasily readable and living. The test cases are used both toeasily document the software under development and totest it. The future of software development leads to lesserbugs and higher quality standards by the improvements inCASE tools and the increasing importance of the unit tests. 72. References Abran Alain and Moore James W. SWEBOK [Book]. - Los Alamitos, California : IEEE, 2004. Alain Abran (Editor) James W. Moore (Ed.), Pierre Bourque (Ed.), Robert Dupuis (Ed.) SWEBOK [Book]. - Los Alamitos, California : IEEEComputer Society Press, 2005. - p. Chapter 5 Page 3. Beck Kent Test Driven Development by Example [Book]. - [s.l.] : Addison-Wesley Professional, 2002. - pp. viii-ix. Beck Kent Test Driven Development by Example [Book]. - [s.l.] : Addison-Wesley Professional, 2002. - p. viii. Benington Herbert D. Production of Large Computer Programs [Journal] // IEEE Annals of the History of Computing. - 1983. Boehm Barry A Spiral Model of Software Development and Enhancement [Journal] // ACM SIGSOFT Software Engineering Notes. - August1986. Boehm Barry W. Guidelines for Verifying and Validating Software Requirements and Design Specifications [Journal] // Euro IFIP 79. - 1979. -pp. 711-719. Crispin Lisa and Gregory Janet Agile Testing Practical Guide For Testers and Agile Teams [Book]. - Boston : Pearson, 2009. Crispin Lisa Driving Software Quality: How Test-Driven Development Impacts Software Quality [Journal] // IEEE Software. - 2006. - pp. 70-71. Humphrey Watts S. Managing the Software Process [Book]. - [s.l.] : Addison-Wesley, 1989. IEEE IEEE Standard Glossary of Software Engineering Terminology [Book]. - New York : IEEE, 1990. Iivari J A hierarchical spiral model for the software process [Journal] // ACM SIGSOFT Software Engineering Notes. - Jan. 1987. - pp. Volume12 Issue 1, . Kaner Cem, Falk Jack L. and Nguyen Hung Quoc Testing Computer Software [Book]. - [s.l.] : Wiley, 1999. Larman Craig and Basili Victor R. Iterative and Incremental Development: Brief History [Journal] // IEEE Software. - [s.l.] : IEEE ComputerSociety, 2003. - pp. 47-56. Manifesto for Agile Software Development [Online]. - February 2001. - http://agilemanifesto.org/. Royce Winston W. MAnaging The DEvelopment of Large Software Systems [Journal]. - [s.l.] : TRW, 1970. - pp. 328-338. Sommerville Ian Software Engineering, 6th Edition [Book]. - Edinburg : Pearson, 2000. Waterfall Model [Online] // Wikipedia. - http://en.wikipedia.org/wiki/Waterfall_development. Weinberg Gerald M. The Psychology of Computer Programming: Silver Anniversary Edition [Book]. - [s.l.] : Dorset House; Anl Sub edition,1998. Wolverton Ray W. The Cost of Developing Large-Scale Software [Journal] // IEEE TRANSACTIONS ON COMPUTERS, VOL. c-23, NO. 6. 1974.