Introduction to SDP Methodologies

Introduction to Software
Development Process &
Methodologies
Shahul, Asar, Dinesh Garnet Consulting Management

What Is SDP?
A software development process (SDP) is splitting
of software development work into distinct phases
(or stages) containing activities with the intent of
better planning and management. It is often
considered a subset of the systems development life
cycle.

Features Of SDP :-
 Compatibility,
 Extensibility,
 Fault-tolerance,
 Maintainability,
 Reliability,
 Reusability,
 Robustness,
 Security,
 Performance,
 Portability,
 Scalability,
 etc,…,.

It Has Some Core Activities:-
I. Requirement Analysis,
II. Design,
III. Construction,
IV. Testing,
V. Debugging,
VI. Deployment,
VII.Maintenance

I. Requirement Analysis
• Requirements Analysis (RA) is critical
to the success or failure of a systems or
software project.
• It is an first phase of development
process to verify, validate and managing
the software or system project.

Overview Of RA
• RA include 3 types of activities
Eliciting Requirements - This is sometimes also called requirements gathering or
requirements discovery.
Analyzing Requirements - determining whether the stated requirements are clear, complete.
Recording Requirements - Requirements may be documented in various forms, usually including
documents, use cases, user stories, process specifications and a
variety of models including data models

Overview Of RA (continue)
It include some topics like Stakeholder identification, Joint Requirements Development
(JRD), Measurable goals, Prototypes, Use cases.
It has several types like Customer Requirements, Architectural Requirements, Structural
Requirements, Behavioral Requirements, Functional Requirements, Non-functional
Requirements, Core Functionality and Ancillary Functionality Requirements, Performance
Requirements, Design Requirements, Derived Requirements, Allocated Requirements.
It has 3 issues on SDP such as Stakeholder Issues, Engineer/Developer Issues, Attempted
Solutions.
For more…..

II. Design
• It is usually involves problem solving and
planning a software solution. This includes
both a low-level component and algorithm
design and a high-level, architecture design.

Principles Of Design
• The design process should not suffer from tunnel vision.
• The design should be traceable to the analysis model.
• The design should not reinvent the wheel.
• The design should "minimize the intellectual distance" between the software and the
problem as it exists in the real world.
• The design should exhibit uniformity and integration.
• The design should be structured to accommodate change.
• The design should be structured to degrade gently, even when aberrant data, events, or
operating conditions are encountered.
• Design is not coding, coding is not design.
• The design should be assessed for quality as it is being created, not after the fact.
• The design should be reviewed to minimize conceptual (semantic) errors.

Design Concepts
 Abstraction – It is the process or result of generalization by reducing the information content of a concept or an
observable phenomenon, typically in order to retain only information which is relevant for a particular purpose.
 Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement
of function in a step-wise fashion until programming language statements are reached.
 Modularity - Software architecture is divided into components called modules.
 Software Architecture - It refers to the overall structure of the software and the ways in which that structure
provides conceptual integrity for a system
 Control Hierarchy - A program structure that represents the organization of a program component and implies a
hierarchy of control.
 Structural Partitioning - The program structure can be divided both horizontally and vertically.
 Data Structure - It is a representation of the logical relationship among individual elements of data.
 Software Procedure - It focuses on the processing of each module individually.
 Information Hiding - Modules should be specified and designed so that information contained within a module
is inaccessible to other modules that have no need for such information.

Modeling Languages
Architecture description language (ADL) – Software Architecture
Business Process Modeling Notation (BPMN) - Process Modeling
EXPRESS and EXPRESS-G (ISO 10303-11) - Data Modeling
Extended Enterprise Modeling Language (EEML) - Business Process Modeling
Flowchart - algorithm or step-wise process
Fundamental Modeling Concepts (FMC) - Software-Intensive Systems
IDEF – (IDEF0 -Functional Modeling, IDEF1X - Information Modeling, IDEF5 - Modeling
Ontologies.)
Jackson Structured Programming (JSP) - Structured Programming
LePUS3 - Object-Oriented Visual Design Description Language ( Java, C++,C# )
Unified Modeling Language (UML) - General Modeling Language
Alloy (specification language) - General Purpose Specification Language
Systems Modeling Language (SysML) - New General-Purpose Modeling Language for Systems
Engineering.

III. Construction
• It is a software engineering discipline. It is
the detailed creation of working meaningful
software through a combination of coding,
verification, unit testing, integration testing,
and debugging.
• It is linked to all the other software
engineering disciplines, most strongly to
software design and software testing.

Construction Fundamentals
• Minimizing complexity
• Anticipating change
• Constructing for verification
• Reuse
• Standards in construction
• Managing construction
• Construction models
• Construction planning
• Construction measurement
• Practical considerations
• Construction design & languages,
• Construction testing & quality,
• Coding, Reuse, and Integration.

Construction Technologies
• Object-Oriented Runtime Issues,
• Assertions, Design by Contract, and Defensive Programming,
• Error Handling, Exception Handling, and Fault Tolerance,
• State-Based and Table-Driven Construction Techniques,
• Runtime Configuration and Internationalization.

IV. Testing
 It is the process of executing a program or application
with the intent of finding software bugs (errors or
other defects), and verifying that the software product
is fit for use.
 It is an process of evaluation of a systems or its
components with intent to find whether it satisfies the
specified requirements or not.
 It can be conducted as soon as executable software
(even if partially complete) exists.
 It is an investigation conducted to provide the
stakeholders with information about the quality of the
product or service under test.

Overview Of Testing
• Testing Methods:-
• Static vs. dynamic testing – (Reviews, walkthroughs, or inspections - static testing(verification), test cases - dynamic
testing(validation).)
• The box approach:-
• White-box testing - Function coverage, Statement coverage, Decision coverage.
• Grey-box testing - internal data structures and algorithms.
• Black-box testing –
• Visual testing - customer acceptance and usability testing.
Testing Levels:-
• Unit testing(Functional within code level), Integration testing(associate with architectural design-Modules),
Component interface testing, System testing, Operational acceptance testing.
• Types of Testing:-
• Installation testing, Compatibility testing, Smoke and sanity testing, Regression testing, Acceptance testing,
Alpha testing, Beta testing, Functional vs non-functional testing, Continuous testing, Destructive testing,
Software performance testing, Usability testing, Accessibility testing, Security testing, Development
testing, A/B testing, Concurrent testing, Conformance testing or type testing.
• Testing Process:-
• Traditional waterfall development model, Agile or Extreme development model, Top-down and bottom-up,
A sample testing cycle, Software verification and validation, Software Quality Assurance (SQA).

V. Debugging
• It is the process of finding and resolving of
defects that prevent correct operation of
computer software or a system.
• It involves numerous aspects, including
interactive debugging, control flow,
integration testing, log files, monitoring
(application, system), memory dumps,
profiling, Statistical Process Control, and
special design tactics to improve detection
while simplifying changes.

Debugging Techniques
• Interactive debugging – work with team.
• Print debugging (or tracing) – flow of execution process.
• Remote debugging - a debugger connects to a remote system over a network.
• Post-mortem debugging - debugging of the program after it has already crashed.
• "Wolf fence" algorithm - simple but very useful algorithm.
• Delta Debugging - a technique of automating test case simplification.
• Saff Squeeze - a technique of isolating failure within the test using progressive inlining of
parts of the failing test.

VI. Deployment
• It is all of the activities that make a software
system available for use.
• The general deployment process consists of several
interrelated activities with possible transitions
between them. These activities can occur at the
producer side or at the consumer side or both.
• The "deployment" should be interpreted as a
general process that has to be customized
according to specific requirements or
characteristics.

Deployment Activities
• Release - The release activity follows from the completed development process, and is
sometimes classified as part of the development process rather than deployment proper.
• Install and activate - For simple systems, installation involves establishing some form of
command, shortcut, script or service for executing the software (manually or automatically).
• Deactivate - Deactivation is the inverse of activation, and refers to shutting down any
already-executing components of a system.
• Uninstall - Uninstallation is the inverse of installation.
• Update - The update process replaces an earlier version of all or part of a software system
with a newer release.
• Built-in update - Mechanisms for installing updates are built into some software systems.
• Version tracking - Version tracking systems help the user find and install updates to software
systems.
• Adapt - The adaptation activity is also a process to modify a software system that has been
previously installed.

Deployment Roles
• In pre-production environments:
• Application Developers: see Software development process
• Build-and-Release Engineers: see Release engineering
• Release Managers: see Release management
• Deployment Coordinators: see DevOps
• In production environments:
• System Administrator
• Database Administrator
• Release Coordinators: see DevOps
• Operations Project Managers: see Information Technology Infrastructure Library

VII. Maintenance
 It is the modification of a software product after delivery to
correct faults, to improve performance or other attributes.
 A common perception of maintenance is that it merely
involves fixing defects.
 Over 80% of maintenance effort is used for non-corrective
actions.
 This perception is perpetuated by users submitting problem
reports that in reality are functionality enhancements to the
system.
 More recent studies put the bug-fixing proportion closer to
21%.

Maintenance Activities
• The maintenance activities classified into four classes:-
• Adaptive – Modification of a software product performed after
delivery to keep a software product usable in a changed or changing
environment (DBMS, OS).
• Perfective – Modification of a software product after delivery to
improve performance or maintainability.
• Corrective – Reactive modification of a software product performed
after delivery to correct discovered problems. .
• Preventive – Modification of a software product after delivery to
detect and correct latent faults in the software product before they
become effective faults.

Importance Of A Software Maintenance
• The key software maintenance issues are both managerial and technical. Key management
issues are: alignment with customer priorities, staffing, which organization does
maintenance, estimating costs. Key technical issues are: limited understanding, impact
analysis, testing, maintainability measurement.
• It is a very broad activity that includes error correction, enhancements of capabilities,
deletion of obsolete capabilities, and optimization. Because change is inevitable,
mechanisms must be developed for evaluation, controlling and making modifications.
• Software Maintenance Planning
• Software Maintenance Process

Maintenance Factors
Impact of key adjustment factors on
maintenance (sorted in order of maximum
positive impact)
Maintenance Factors Plus Range
Maintenance specialists 35%
High staff experience 34%
Table-driven variables and
data
33%
Low complexity of base
code
32%
Y2K and special search
engines
30%
Code restructuring tools 29%
Re-engineering tools 27%
High level programming
languages
25%
Impact of key adjustment factors on
maintenance (sorted in order of maximum
negative impact)
Maintenance Factors Minus Range
Error prone modules -50%
Embedded variables and
data
-45%
Staff inexperience -40%
High code complexity -30%
No Y2K of special search
engines
-28%
Manual change control
methods
-27%
Low level programming
languages
-25%
No defect tracking tools -24%

Software Development Methodologies
 It is a framework that is used to structure,
plan, and control the process of developing
an information system.
 It has several methodologies.
 They are such as,
 Agile  CM
 DSDM  XP
 FDD  JAD
 LD  RAD
 RUP/UP  Scrum
 Spiral  SDLC
 Waterfall  V / Dual V-model
 Prototyping  IID
 TDD  Etc,…,. Shahul, Asar, Dinesh Garnet Consulting Management

(CM)

The use of the word “crystal” refers to the various facets of a gemstone - each a different
face on an underlying core. The underlying core represents values and principles, while
each facet represents a specific set of elements such as techniques, roles, tools, and
standards. Cockburn also differentiates between methodology, techniques, and policies.
A methodology is a set of elements (practices, tools); techniques are skill areas such as
developing use cases; and policies dictate organizational “musts”.
Overview Of CM

(DSDM)

(FDD)

• In contrast to the Waterfall approach, JAD is thought to lead to shorter development times
and greater client satisfaction, both of which stem from the constant involvement of the
client throughout the development process. On the other hand, with the traditional approach
to systems development, the developer investigates the system requirements and develops an
application, with client input consisting of a series of interviews.
• Rapid application development (RAD), a variation on JAD, attempts to create an application
more quickly through strategies that include fewer formal methodologies and reusing
software components.

Rational Unified Process (RUP/UP) Methodology
• The Rational Unified Process attempts to capture
many of modern software development's best
practices in a form suitable for a wide range of
projects and organizations.
• This process recognizes that the traditional waterfall
approach can be inefficient because it idles key team
members for extended periods of time.

RUP represents an iterative approach that is superior for a number of reasons :
• It lets you take into account changing requirements which despite the best efforts of all
project managers are still a reality on just about every project.
• Integration is not one “big bang” at the end; instead, elements are integrated progressively.
• Risks are usually discovered or addressed during integration. With the iterative approach,
you can mitigate risks earlier.

The Rational Unified Process divides New Development Life Cycle in 5 Consecutive Phases :
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

Rational Unified Process Features
• Online Repository of Process Information and Description in HTML format
• Templates for all major artifacts, including:
• RequisitePro templates (requirements tracking)
• Word Templates for Use Cases
• Project Templates for Project Management
• Process Manuals describing key processes

Advantages of RUP Software Development
• The development time required is less due to reuse of components.
• There is online training and tutorial available for this process.
Disadvantages of RUP Software Development
• The team members need to be expert in their field to develop a software under this
methodology.
• The development process is too complex and disorganized.

Use Of RUP Software Development :
• Business Modeling,
• Analysis And Design,
• Implementation,
• Testing, And Deployment.

SCRUM METHODOLOGY
• Scrum is an agile method for
project management developed by Ken
Schwaber.
• Its goal is to dramatically improve
productivity in teams previously paralyzed
by heavier, process-laden methodologies.

Scrum is characterized by:
• A living backlog of prioritized work to be done.
• Completion of a largely fixed set of backlog items in a series of short iterations or sprints.
• A brief daily meeting (called a scrum), at which progress is explained, upcoming work is
described, and obstacles are raised.
• A brief planning session in which the backlog items for the sprint will be defined.
• A brief heartbeat retrospective, at which all team members reflect about the past sprint.

Limitations of Scrum Methodology:
• Teams whose members have very specialised skills.
• In Scrum, developers should be able to work on any task or pick up work that another
developer has started.
• This can be managed by good Scrum leadership.
• Team members with highly focused skills can contribute equally as well as those with
broader expertise.
• They can also contribute to the design by bringing a different perspective to the project.

Advantages of Scrum Methodology:
• Large projects are divided into easily manageable sprints
• Developments are coded and tested during the sprint review
Disadvantages of Scrum Methodology:
• The chances of project failure are high if individuals aren't very committed or cooperative
• Adopting the Scrum framework in large teams is challenging

Scrum Methodology Features :
• Project can respond easily to change.
• Problems are identified early.
• Customer gets most beneficial work first.
• Work done will better meet the customers needs.
• Improved productivity.
• Ability to maintain a predictable schedule for delivery.

Use Of Scrum model :
• Success is defined by achieving the planned scope.
• Requirements are well-understood and will not change
• Some steps may involve long lead times, or lots of specialized resources
• Incremental results (e.g, at 20% of scope) have little or no value

SPIRAL METHODOLOGY
• The spiral model combines the idea of
iterative development with the systematic,
controlled aspects of the waterfall model.
This Spiral model is a combination of
iterative development process model and
sequential linear development model i.e.
• the waterfall model with a very high
emphasis on risk analysis. It allows
incremental releases of the product or
incremental refinement through each
iteration around the spiral..

At a high-level, the steps in the spiral model are as follows:
• The new system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the external or internal users and
other aspects of the existing system.
• A preliminary design is created for the new system.
• A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics of the
final product.

spiral model are driven by cycles that always display six characteristics :
• Define artifacts concurrently
• Perform four basic activities in every cycle
• Risk determines level of effort
• Risk determines degree of details
• Use anchor point milestones

Advantages of Spiral model:
• High amount of risk analysis hence, avoidance of Risk is enhanced.
• Good for large and mission-critical projects.
• Strong approval and documentation control.
Disadvantages of Spiral model:
• Can be a costly model to use.
• Risk analysis requires highly specific expertise.
• Doesn’t work well for smaller projects.

When to use Spiral model:
• When costs and risk evaluation is important
• For medium to high-risk projects
• Long-term project commitment unwise because of potential changes to economic priorities
• Users are unsure of their needs
• Requirements are complex
• New product line

Use Of Spiral model :
• Prototypes are expected/needed.
• Large and high budget projects When risk assessment is very critical
• Requirements are not very clearly defined.
• Requirements are vague and even complex

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
• Software Development Life Cycle (SDLC)
is a process used by the software industry
to design, develop and test high quality
softwares.
• The SDLC aims to produce a high-quality
software that meets or exceeds customer
expectations, reaches completion within
times and cost estimates.

The various stages of a typical SDLC :
• Planning and Requirement Analysis
• Defining Requirements
• Designing the Product Architecture
• Building or Developing the Product
• Testing the Product
• Deployment in the Market and Maintenance

SDLC Models :
• Waterfall Model
• Iterative Model
• Spiral Model
• V-Model
• Big Bang Model

Advantages of SDLC:
• Formal review is created at the end of each stage allowing maximum management control.
• This approach creates considerable system documentation.
• This documentation ensures that system requirements can be traced back to stated business
requirements.
Disadvantages of SDLC:
• What may be seen as a major problem for some, end-user does not see the solution until the
system is almost complete.
• Users get a system that meets the need as understood by the developers; this may not be
what was really needed for them. There may be a loss in translation.

Strength of SDLC :
• Control
• Detailed steps
• Monitor large projects
Weaknesses of SDLC:
• Increased development time
• Increased development cost
• Rigidity

Use Of SDLC:
• software industry to design, develop and test high quality softwares.
• The SDLC aims to produce a high-quality software that meets or exceeds
• customer expectations, reaches completion within times and cost estimates.

WATERFALL MODEL
• The Waterfall Model was the first Process
Model to be introduced. It is also referred
to as a linear-sequential life cycle model.
It is very simple to understand and use.
• In a waterfall model, each phase must be
completed before the next phase can begin
and there is no overlapping in the phases.

Different phases of the Waterfall Model :
• Requirement Gathering and analysis
• System Design
• Implementation
• Integration and Testing
• Deployment of system
• Maintenance

History of Waterfall Model :
• The first known presentation describing use of similar phases in software engineering was
held by Herbert D. Benington at Symposium on advanced programming methods for digital
computers on 29 June 1956.
• This presentation was about the development of software for SAGE.
• In 1983 the paper was republished with a foreword by Benington pointing out that the
process was not in fact performed in a strict top-down fashion, but depended on a prototype.
• The earliest use of the term "waterfall" may have been in a 1976 paper by Bell and Thayer.

Advantages of Waterfall Model :
• Simple and easy to understand and use
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
Disadvantages of Waterfall Model :
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.

Application of Waterfall Model :
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.

Use Of Waterfall Model :
• Requirements are very clear and fixed.
• There are no ambiguous requirements.
• The client has high confidence in the organization.

V / DUAL V-MODEL
• The V-model is an SDLC model where
execution of processes happens in a
sequential manner in a V-shape. It is also
known as Verification and Validation
model.
• there are Verification phases on one side of
the ‘V’ and Validation phases on the other
side. The Coding Phase joins the two sides
of the V-Model.

Verification Phases :
• Business Requirement Analysis
• System Design
• Architectural Design
• Module Design
• Coding Phase

Validation Phases :
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

Advantages of V Model :
• This is a highly-disciplined model and Phases are completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Simple and easy to understand and use.
Disadvantages of V Model :
• High risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.

Application of V Model :
• Requirements are well defined, clearly documented and fixed.
• Product definition is stable.
• Technology is not dynamic and is well understood by the project team.
• There are no ambiguous or undefined requirements.

Use Of V Model :
• The V-shaped model should be used for small to medium sized projects where
requirements are clearly defined and fixed.
• High confidence of customer is required for choosing the V-Shaped model approach.

PROTOTYPING MODEL
• It is a working model of software with
some limited functionality.
• The prototype does not always hold the
exact logic used in the actual software
application and is an extra effort to be
considered under effort estimation.

Following is a stepwise approach explained to design a software prototype :
• Basic Requirement Identification
• Developing the initial Prototype
• Review of the Prototype
• Revise and Enhance the Prototype

Different types of software prototypes :
• Throwaway/Rapid Prototyping
• Evolutionary Prototyping
• Incremental Prototyping
• Extreme Prototyping

Advantages of software prototypes :
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily.
• Confusing or difficult functions can be identified.
Disadvantages of software prototypes :
• Risk of insufficient requirement analysis owing to too much dependency on the prototype.
• Users may get confused in the prototypes and actual systems.

Application of software prototypes :
• Software that involves too much of data processing and most of the functionality is internal
with very little user interface does not usually benefit from prototyping.
• Prototype development could be an extra overhead in such projects and may need lot of
extra efforts.
• Software Prototyping is most useful in development of systems having high level of user
interactions such as online systems.

• Use Of software prototypes :
• Screen generators,
• design tools,
• software factories

ITERATIVE AND INCREMENTAL DEVELOPMENT MODEL(IID)
• Iterative process starts with a simple
implementation of a subset of the software
requirements and iteratively enhances the
evolving versions until the full system is
implemented.
• At each iteration, design modifications are
made and new functional capabilities are
added. The basic idea behind this method is
to develop a system through repeated
cycles (iterative) and in smaller portions at
a time (incremental).

Overview Of Iterative and incremental Model :
• The basic idea behind this method is to develop a system through repeated cycles
(iterative) and in smaller portions at a time (incremental), allowing software
developers to take advantage of what was learned during development of earlier
parts or versions of the system.
• At each iteration, design modifications are made and new functional capabilities are
added.
• The procedure itself consists of the initialization step, the iteration step, and the
Project Control List.

Implementation guidelines :
• Any difficulty in design, coding and testing a modification should signal
the need for redesign or re-coding.
• Modifications should fit easily into isolated and easy-to-find modules. If
they do not, some redesign is possibly needed.
• Modifications to tables should be especially easy to make. If any table
modification is not quickly and easily done, redesign is indicated.

Advantages of Iterative and incremental Model :
• Results are obtained early and periodically.
• Parallel development can be planned.
• Progress can be measured.
Disadvantages of Iterative and incremental Model :
• More resources may be required.
• More management attention is required.
• Management complexity is more.

Application of Iterative and incremental Model :
• Requirements of the complete system are clearly defined and understood.
• There is a time to the market constraint.
• A new technology is being used and is being learnt by the development team while
working on the project.
• There are some high-risk features and goals which may change in the future.

Use Of iterative and incremental Model:
• software industry,
• many hardware
• Embedded Software development

Test-driven Development (TDD)
• It is related to the test-first programming
concepts of extreme programming.
• Programmers also apply the concept to
improving and debugging legacy code developed
with older techniques.
• Test-driven development is related to, but
different from acceptance test–driven
development (ATDD).
• BDD (behavior-driven development) combines
practices from TDD and from ATDD.

TDD Life-Cycle
• Add a test
• Run all tests and see if the new test fails
• Write the code
• Run tests
• Refactor code
• Repeat
for more details…

Overview Of TDD
• The development styles are using some principles like KISS (keep it simple, stupid), YAGNI (You
aren't gonna need it),FITYMI(Fake it till you make it).
• Best practices are commonly applied structure for test cases like (1) setup, (2) execution, (3)
validation, and (4) cleanup.
• Benefits are
• Programmers using pure TDD on new ("greenfield") projects reported they only rarely felt the need to
invoke a debugger.
• It offers more than just simple validation of correctness, but can also drive the design of a program.
• This leads to smaller, more focused classes, looser coupling, and cleaner interfaces.
• Limitations
•Test-driven development does not perform sufficient testing in situations where full functional tests are
required to determine success or failure, due to extensive use of unit tests.
•A high number of passing unit tests may bring a false sense of security, resulting in fewer additional
software testing activities, such as integration testing and compliance testing.

• Test-driven work changes are,
• "Add a check" replaces "Add a test"
• "Run all checks" replaces "Run all tests"
• "Do the work" replaces "Write some code“
• "Run all checks" replaces "Run tests“
• "Clean up the work" replaces "Refactor code“
• "Repeat“
• Software for TDD
• xUnit frameworks
• TAP results - Test Anything Protocol
•TDD for complex systems
•Designing for testability
•Managing tests for large teams
Overview Of TDD (continue)

Introduction to SDP Methodologies

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Introduction to SDP Methodologies

Similar to Introduction to SDP Methodologies (20)

Recently uploaded

Recently uploaded (20)

Introduction to SDP Methodologies