.

Net Development Methodology for Integration Team in

the Ecommerce Replacement Project
.Net Development Process

.NET DEVELOPMENT METHODOLOGY FOR INTEGRATION TEAM IN THE

ECOMMERCE REPLACEMENT PROJECT..............................................................1
INTRODUCTION.....................................................................................................................3
MAJOR CHALLENGES............................................................................................................3
SOLUTIONS..........................................................................................................................3
Developer Training.....................................................................................................3
OO development via Evolutionary Prototyping..........................................................5
Application Framework for the Integration Layer...................................................5
Evolution Prototyping..............................................................................................6
Initial Design........................................................................................................6
Prototyping Part 1 (Design).................................................................................7
Prototyping Part 2 (Development and Testing)...................................................7
System Testing and Production...........................................................................8
Overcoming risks in Evolution Prototyping........................................................8
Team Development Environment................................................................................8
Build Process.......................................................................................................9
QA Testing...........................................................................................................9
Team Environment Physical Infrastructure.......................................................10
CONCLUSION......................................................................................................................10

Page 2 2/7/2011
.Net Development Process

Introduction

Going forward, Microsoft’s platform of choice for application development is the .Net
framework and the Visual Studio .Net Integrated Development Environment. This new
direction gives the XXX.com Integration Development team great opportunities in
developing more robust applications using the Object Oriented (OO) design and
development technologies. We will leverage the tools provided by the new technologies
to create a “XXX Integration Framework”. This object framework will encompass all
functionalities to provide a comprehensive view of the entire Integration (Ancillary)
application layer.

However, with the advent of this new technology and its new design philosophy, our VB
developers will be greatly challenged in their ability to adjust and learn quickly and
become proficient in a short time in order to deliver quality results in the E-Commerce
Replacement project. In addition, our existing development process may also need to be
modified to mirror the type of development approaches recommended for .Net. This
document is intended to discuss approaches that should be taken when adopting the new
technologies in our design/development phases while minimizing the risks that hinder the
success of this project.

Major Challenges

• Developers are not proficient with .Net technologies

• OO design normally requires extensive period of time which may increase risk to
project timeline due to inexperience team and changing business requirements
• Current Team Development Environment is inadequate for developing under the
new platform

Solutions
Developer Training

Microsoft .Net development is fundamentally different from the current VB development.

Although VB .Net is one of the languages supported, the language construct and syntax
are very different from VB 6.0. In VB 6.0, actions are typically performed through
functions provided by the language. In the .Net world including VB .Net, an action is
carried out via a call to a method associated with a class/object. The functions so familiar
to the VB developers are now incorporated into the .Net framework. In addition, the .Net
framework provides a lot more functionalities that traditionally can only be accessed
through low-level API calls or have to be created by the developers themselves.

Page 3 2/7/2011
.Net Development Process

All these changes mean that the existing knowledge of VB cannot be leveraged for the
development in the new technology in most parts. The true learning curve lies on getting
familiarized with the .Net framework namespaces and classes and their functionalities.
As a result, we should focus on choosing a language that is going to be the language of
choice for future software development under .Net. At current time, the most popular
language is C# (currently used throughout Microsoft for its software developments). This
language is very similar to Java in its syntax and can be learned by a VB programmer
without much adjustment.

The real learning curve, as mentioned earlier, is learning the .Net Framework. There is
really no easy way to overcome this obstacle. Sending developers to training classes will
be helpful by providing a more complete overview of the technology and we should do
that when such opportunities are available. However, training classes alone will not be
sufficient for the level of expertise that will be required to develop complex systems.
Knowledge acquired through hands-on experience will be the only way our developers
can be come proficient with the technology.

There are risks, however, when trying to learn while developing at the same time. But
this is the nature of the fast-moving world we are in. Instead of avoiding taking risk, we
need to implement measures to control the negative effects. We have three things that
work in our favor:

• The presence of two MCS consultants who are both very technically capable and
have great deal of .Net development experience
• The additional Microsoft resources we can tab into for advices and answers
• The significant size of team members participating in this project

We need to take full advantage of the first two benefits by involving MS in all phases of
our development life cycle. In addition to leveraging their design / development advices
on the Commerce Server 2002 and BizTalk Server developments, we will involve them
in the design of our .Net Application Framework and in the review of our programming
practices.

Furthermore, we will promote group learning by leveraging the knowledge accumulated

by individual team members during the development life cycle. Individually, each of us is
limited in the amount of .Net knowledge we can acquire in such a short span of time.
However, the combined knowledge we acquire by learning from each other can be
exponentially larger. In order to achieve this benefit, the team needs to meet daily at
regular time. During these meetings, in addition to development review activities (more
on this later), one focus of these meetings is to allow team members to present any new
techniques on .Net framework application they adopted in their solutions.

Code review, besides controlling quality, is another opportunity to educate developers.

Since no member can claim expertise over others in this new platform, we must all be
open minded and welcome suggestions from our peers. The code review will be a peer

Page 4 2/7/2011
.Net Development Process

review format rather than done by the analysts as in the past. Suggestions from other
members for better and more efficient coding practices should be welcomed and adopted.

Finally, the team will follow the industry best practices on coding standards. Doing so
will enable the team to produce source codes consistent with the industry standard for
.Net developments. We will solicit such standards from Microsoft and adapt them for
XXX environment (but try to make as little changes to them as possible).

OO development via Evolutionary Prototyping

Object Oriented design and development has been around for a long time and has mainly
been used in commercial software development. Enterprise application development has
been lagging behind in this area until recently. With the advent of Java and now with
.Net, the traditional client/server development is finally moving into this arena. Besides
the many programming benefits of the OO approach, the implication to our own
development lifecycle is the discipline it brings to our development process.

Right now, in our Integration layer (Ancillary Applications), the various functionalities
are developed as individual applications implementing its own business logic from end to
end. There is no overall architecture and no published interfaces for these application
modules which make sharing existing functionality very difficult. Furthermore, with the
lack of an overall and comprehensive view of the various applications in this layer, there
is little chance to enforce consistency and discipline to the application development. The
quality of the application design and implementation depends entirely on the quality and
experience of the individual developers.

Application Framework for the Integration Layer

At the end of the E-Commerce Replacement project, a comprehensive object framework

will be established that will encompass the entire application layer. At the same time, an
architecture governing body (members TBD) will be established to oversee any changes
to this framework. Future applications developed for this layer are required to “fit” into
this framework. This means during the design of a future application, the developer will
need to review the framework first and identify existing classes that can be leveraged
(used or extended via inheritance) for the new application. After the design is completed,
the architecture committee will review the design with the designer to ensure the
consistency. The resulting class changes are then incorporated into the existing object
framework.

The E-Commerce Replacement project provides us a great opportunity to achieve the

objective of creating an OO application framework. We will be using .Net (C#) as the
development platform. We will use UML as the design-modeling tool. We will leverage
our existing OO experience and the expertise from Microsoft consultants. However, there
is still great risk in going through a large scale OO development effort for the first time.

Page 5 2/7/2011
.Net Development Process

To minimize this risk, we should adopt a development approach called “Evolutionary

Prototyping”.

Note: we will need to elaborate on this in the architecture design for the E-Commerce
Replacement project. Basically, we need to create a multi-tiered architecture for the new
Integration layer including “Presentation”, “Business Logic (Business Façade and
Business Rules)” and “Data Access” tiers. Each of these layers will consist of multiple
classes.

Evolution Prototyping

In Evolutionary Prototyping, you will still go through the analysis / design / development
phases. However, there is no clean separation between design and implementation. You
do not sit down and start designing to every details possible before the development start.
Instead, development (prototyping) is part of the design process and the prototype
continues to evolve into the final product though multiple iterations.

One key focus for Evolutionary Prototyping is addressing high-risk areas first and then
continues to evolve to include other areas of the application. So for the E-Commerce
Replacement project, we should start out by focusing on how functionality should be
divided and encapsulated (at a higher level sometimes) and the interface for each object
should be defined. The internal logic can either be simulated or left out until later
iterations.

Initial Design

We start by identifying the major functionality in each of the multiple tiers (Use Cases in
UML). Based on these functional blocks, classes are identified representing major
functionalities. The public interface for each class is also identified (Class Diagrams in
UML). Then the relationships and interactions among classes are added (Class Diagrams
and Sequence Diagrams in UML). The resulting classes are then grouped into
components for implementation (Component Diagrams in UML). This completes the
preliminary design (not the entire design) of the project. At this point, high-level
prototype development tasks are identified and rough time estimates are given and works
are divided among team members. All team members will participate in this effort to
contribute their knowledge of the existing functionality. Microsoft consultants will help
lead the discussion and provide guidance in the design.

While the object model design is taking place, the data model design is carried out as
well. For applications in the Integration layer, part of the data source will be defined
based on the Web site requirements (Commerce Server 2002) and the rest will be data
stores for internal usage. The data modeling effort will also be part of the Evolutionary
Prototyping process since there will be great inter-dependency between the object models
and the data models.

Page 6 2/7/2011
.Net Development Process

Prototyping Part 1 (Design)

After the initial design is complete, the development of the initial prototype then takes
place. Since the developers are working with new technology, it may take some time for
the developers to become proficient with the tools. Therefore, allowance needs to be
made to account for the learning curve during the initial prototyping effort. During
prototyping, developers need to examine the usage of the classes critically to identify any
shortcoming in the existing class design (interface, encapsulation of functionality). After
the initial prototype is created, the resulting modules are validated through the build
process (more on this in the Team Development Environment section). Any suggestion
for changes in the object model is first reviewed by the team and incorporated upon
acceptance by the team.

From this point onward, the prototype goes through continual iterations to refine its
design. At the same time, the data model will evolve accordingly. The completion of
design phase is when classes supporting all of the tiers (UI, Business, Data) are included
in the object framework and the object model is stabilized (no more changes to class
relationships and interfaces). At the completion of the design, the time line for the project
will be readjusted to provide a more accurate estimate.

Prototyping Part 2 (Development and Testing)

The development phase is simply a continuation of the iterative activities after the design
complete milestone. The emphasis for the development phase is to refine the prototype in
the following areas:
• Business logic finalized (from the previously more simplified version)
• Data access functionality Completed (from the previously simulated version)
• Code standard enforced
• Installation solutions finalized and incorporated into Build packages
• Rigid build / test processes established

In the beginning, the iteration frequency can be less rapid (weekly?) to accommodate to
the amount of code changes that need to be added initially. But as the prototype
approaching its completion (milestone TBD), daily build and the accompanying QA
testing will be required. Team members are required to make sure their portion of work is
well tested for the team builds to be successful. The testing of the applications should
start about two third into the development phase (TBD) as the majority of the
functionalities is taking shape.

Also, business users should be involved in the usability testing to provide feedback on the
UI functionality towards the later part of the development phase (after presentation layer
is taking shape).

Even during the development phase, shortcomings in design should still be identified and
object model adjusted accordingly. Code review by peers is conducted daily to safeguard
quality and consistency.

Page 7 2/7/2011
.Net Development Process

System Testing and Production

Since the QA process has been incorporated as part of the development process to
remove all of the bugs, only a final comprehensive testing for the applications in the
Integration layer will need to be conducted to verify the product quality. System
integration testing (end to end from Web to OrderPower order fulfillment system) will
take place subsequently (coordinated with the Web team’s development cycle) to ready
the applications for production.

The deployment / installation process should already been developed by launch time
based on the build process created and used in earlier phases. The deployment of the
applications and its required resources should all be part of an automated installation
package with little or no manual intervention.

Overcoming risks in Evolution Prototyping

One of the major risks for Evolutionary Prototyping in the traditional C/S development is
the poor design/ poor maintainability it may cause. RAD tools such as Visual Basic
enable easy prototyping but they often lead to undisciplined development practices such
as:

• Start coding without designing

• Completely deviate from the original design once coding starts
• Developing in a silo mode without knowing or caring about functionality is
already available.

The combination of OO (with UML) and Evolutionary Prototyping help remedy such
shortcomings by build into the process a comprehensive object framework and steps to
maintain accuracy of the object model. In addition, this life cycle help ensure mistakes
are uncovered and addressed earlier on through iterative testing and reviews.

Team Development Environment

By using Visual Studio .Net, our development team will be empowered with capabilities
far beyond what they currently have using Visual Studio 6.0. However, to truly take
advantage of this opportunity, the traditional in-house C/S development process
associated with RAD tools need to be upgraded to the level of commercial software
development. A team development environment optimized for .Net development needs to
be established. In addition, our team structure needs to be modified to resemble that of a
software development team.

Microsoft has published a detailed white paper covering the various aspects of the a
successful team development environment (http://microsoft.com/downloads/release.asp?
ReleaseID=35981 or \\dta01\!FIL_DIR\ECO_PUB\Integration Team Share\Team

Page 8 2/7/2011
.Net Development Process

Development Guide.doc) We should certainly rely heavily on Microsoft’s

recommendation on setting such an environment. As stated in the white paper, a team
environment is more than just the hardware arrangements; it encompasses a development
process and a team structure as well. One of the major components in the .Net
development environment is the Build process and the role of build engineer.

Build Process

In commercial software development life cycle, the Build/Test process is an integral part
of the development phase (See the Build section in the Microsoft white paper). Currently,
we have integration testing and QA testing that happen after the completion of the
development phase. However, in the new development cycle for .Net, the Build and Test
should be part of the development iterations. Also, the Build process is not the manual
installation/configuration we are performing today, but rather an automated process
based on the Visual Studio .Net Setup projects supporting the application projects plus
additional customized build scripts. In addition, there is a tight integration between
Visual Studio .Net IDE and Visual SourceSafe (VSS) to provide version control for
software builds.

All these new features require a person (team?) dedicated to support the build engineer
role. This person needs to
• Acquire the necessary knowledge and expertise required to create the VS .Net
setup projects
• Support the version control process using VSS and VS .Net
• Create and maintain the build package and support the regular build processes

There will be brand new learning curve for this “build engineer” for him to be
knowledgeable and familiar with the facilities that Visual Studio .Net provides. Currently
we have a role responsible for performing “integrations testing” which takes place at
code completion. There is similarity between this role and the “build engineer” role but
the current responsibilities need to be extended significantly to encompass the functional
responsibilities mentioned above.

QA Testing

Since the build process and the testing process work hand-in-hand during the
development phase, QA’s involvement will take place much earlier in the development
life cycle. Creation of the test plan and test cases need to start after the initial prototype is
completed. As the prototype evolves during its multiple iterations, the details of the test
cases should also continue to be updated. The test cases need to reflect the new features
added to the prototype in each iteration.

To ensure constant information flow between developers and QA, dedicated QA

resources need to be assigned for this project. Taking in consideration of the limited QA
resources available at XXX.com, outside contractors may be considered if internal QA
resource cannot be dedicated as members of the team. One workable approach to address

Page 9 2/7/2011
.Net Development Process

the limited QA situation is to have the QA members be responsible for creating test plans
and cases and to have the developers help out in executing some of the cases and report
back the results.

Team Environment Physical Infrastructure

In addition to team structure changes, changes to the existing physical development

environment need to be implemented to support the .Net development process.
According to Microsoft, the following configuration (refer to the white paper for more
detail) is recommended:

Stress Test
Environment

Stress Hub 100Mb Ethernet

DC Build Backup VSS

IIS MSDN

Server Server Server Server

100Mb Ethernet

SQL Servers Web Servers

Dev Test Dev Test

Workstation Workstation Workstation

Developer Workstations

Server Server Server Server

In addition to making sure the production server environment is satisfying the IDC
recommendation, the Infrastructure team also needs to help define and establish the team
development environment.

Conclusion

Moving to .Net development will yield tremendously benefits in upgrading the quality of
the team and provide us with a disciplined development process. The E-Commerce

Page 10 2/7/2011
.Net Development Process

Replacement project is a great opportunity for us to reach this goal. In addition to

upgrading our Web site to the latest MS platforms, we should also use this opportunity to
achieve the following objectives:

• Deliver a great system with a comprehensive application framework to

support future growth.
• Build a solid team of experienced .Net developers who can be the catalysts for
future .Net development by other teams.
• Build a development process that emphasizes discipline and ownership that
can be the blue print for other teams in the future.

We need to seize this opportunity and make the necessary changes in order to achieve
these objectives.

Page 11 2/7/2011