Omega.

NET Complete Reference

Introduction to Omega.NET
Omega.NET

Microsoft Solutions Center of Excellence

Visit: https://gto/codenizant/OmegaDotNet
https://gto.cognizant.com/codenizant/OmegaDotNet

Page 1 of 10
Omega.NET Complete Reference

1. INTRODUCTION.............................................................................................................................. 3

2. OMEGA.NET PRACTICES (CEP 10) ............................................................................................ 4

2.1. CODING STANDARDS ................................................................................................................ 4

2.2. CODE REFERENCE SLICE .......................................................................................................... 5

2.3. CODE GENERATION................................................................................................................... 5

2.4. UNIT TESTING ............................................................................................................................. 6

2.5. CODE COVERAGE........................................................................................................................ 7

2.6. CODE ANALYSIS .......................................................................................................................... 7

2.7. CODE PROFILING ....................................................................................................................... 8

2.8. CHECK IN POLICIES ................................................................................................................... 9

2.9. AUTOMATED BUILD & CONTINUOUS INTEGRATION .................................................... 9

2.10. CODE PROMOTION .............................................................................................................. 10

Page 2 of 10
Omega.NET Complete Reference

1. Introduction
Quality of the code is of paramount importance not only to our customers but even to Cognizant stake-
holders. Better quality code helps in increasing the trust level of our customers. It establishes the fact
that Cognizant follows mature development practices and produces higher quality of code compared to
competition. Adoption of best practices during initial stages of project development reduces
considerable effort in code refactoring, maintenance, performance tuning, troubleshooting at any stage
of the project.
As per the McKinsey report, Cognizant productivity is approximately 30% lower compared to the
competition. Many of the customers/prospects have become more demanding and many of the critical
deals are decided based on attractive price point.
Omega.NET is a framework for enabling Cognizant developers deliver better quality code to our
customers with minimal cost. It helps in building a performance oriented, maintainable and secure code
and aims to address critical software quality issues earlier in project lifecycle. Quality is something that
needs to be looked into during the early stage of the project rather than after thought. An example for
this would be a reference implementation to convey guiding principles and standards to development
team. Quality is not something that can be easily added later. Problems that are too complex, too
obscure, or are discovered too late in the product cycle are usually not fixed and cost of fixing is
unusually high.

Omega.NET addresses following

concerns from our customer concerns
about the application code quality:
1. Functional Correctness
2. Adaptable Code
3. Secure and Reliable Code
4. High Performance Code

Omega.NET consists of 10 core engineering practices to ensure that code developed by our developers
passes through various quality gates set internally or by our customers. These engineering practices
cover all critical aspects related to application development and helps in establishing governance
process as well to ensure better code quality. This finally results in improved developer productivity.

Page 3 of 10
Omega.NET Complete Reference

2. Omega.NET Practices (CEP 10)

2.1. Coding Standards

Coding standards help in setting guidelines for the development team to ensure that code quality is not
compromised. Entire team follows similar standard so that consistency is maintained. Establishing
coding standards earlier in the project lifecycle is critical to ensure health of the project continues to
improve. A coding standards document provides details to the developers about how they need to write
code. This helps in creating standards for the entire project, ensuring that individuals in the team do not
write code in their own style.

It is important that entire team uses the same standards and the team is upto date with the latest
changes in standards. The team should be re-iterated on these standards on a regular basis. This is
important as it cant be assumed that team members will refer the document on regular basis. New
entrants to the team need to undergo learning boot camp before getting started on the development
tasks.
There have been some instances where one programmer creates UI differently than the entire team.
When code goes to customer, customer likes the code of that individual and wants the entire code to be
modified in the same manner. Certainly the intention here is to improve the UI design but it can cause
major rework for the entire team. If anyone in the team has better idea, it is better to get acceptance
from the project lead before going ahead with the change.

Following a set of coding standards helps to

- Improves the maintainability of the code
- Bring consistency and predictability in the implementation
- Easier to identify and fix any defects
- Any changes impacting large section of the code can be managed better

Code Documentation - It is an important aspect of code development, it helps in understanding the

code better and makes the code self explanatory.

XML style comments should be used in the code to describe the classes and its members. Tools such as
Doxygen or Sandcastle can auto-generate the code documents by parsing the xml comments directly
from the source code and create reference manuals in such forms as text or HTML files. Code
documents are often organized into a reference guide style, allowing programmers to quickly look up
specific function or a class.

Auto-generating documentation has various benefits; because it is extracted from the source code itself
(for example, through comments), the programmer can write it while referring to the code, and use the
same tools used to write the source code to make the documentation. This makes it much easier to
keep the documentation up-to-date.

Page 4 of 10
Omega.NET Complete Reference

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodingStandards.a
spx

2.2. Code Reference Slice

Code reference slice practice is about implementing end-to-end functionality for set of business use
cases. It is primarily about analyzing solution elements, which are not somewhat ambiguous and need
exploration before embarking on actual solution development. Goal here is to come out with standard
implementation so that development team can use it as reference while developing other components
of system and come out with ready to use components for the development teams usage. This helps
the team understand the system boundaries, communication & transition points between various
architectural layers and understand the system constraints. This helps in reducing the risk for the project
and helps in improving the quality of the application and reduces time to market.
System quality attributes are also observed during the code reference slice implementation to arrive at
optimal architecture to meet quality of service attributes (NFRs). Decision about using 3rd party
components is also arrived at during the same stage and necessary evaluation can be performed. It is
critical that this activity is performed upfront before heading into the development lifecycle. This
ensures that development teams time is effectively utilized and amount of rework is reduced.
Another key aspect about architecture is that you need to follow the practice Prove It With Code to
communicate to stakeholders that model is not merely an abstraction, one that may appear to be very
good may not actually be so in practice. Only way you can know for sure is to validate your model
through implementation. Depending upon architects familiarity with application stack and various
layers/3rd party components, certain parts of architecture needs to be validated not all. Nonetheless it is
critical that important decision points and the rational is validated for example it is not sufficient to say
that each page will load in 3 seconds. Strategy for handling this should be defined and validated. It
might be that to meet certain quality of attributes, there might be multiple alternatives but appropriate
decision should be made and trade-offs are clearly validated.
The development of a Code Reference Slice helps to reduce risk to the project because architect can
discover whether approach is feasible, that he/she hasnt simply produced an ivory tower architecture.
Some of the teams refer to Code Reference Slice as prototype development but it is important to
understand the value it brings. As far as possible it should be used as basic building block for the
application and not use as throw-away implementation. It can rather accelerate the development of the
project and reduce the effort.
Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeReferenceSlic
e.aspx

2.3. Code Generation

Usually in software development there are lots of tasks which involve repetitive code with minor
changes. A code generator can automate the process of generating code based on these patterns

Page 5 of 10
Omega.NET Complete Reference

Automated code generation is the act of generating source code based on some model such as a
template and is usually accomplished with a utility. These tools allow the generation of source code
through various means. A simple form of code generation is template based code generation where in
the tool replaces patterns in source code according to simple rules. Most of the code generation tools
are either model-driven or template-driven.

Benefits
- Saves time and promotes consistency
- Gives a quick jumpstart to projects
- Allows to quickly re-using proven architectures
- Improve the developer productivity and makes his life easier
- Creates bug free, maintainable and quality code

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeGeneration.as
px

2.4. Unit Testing

The primary goal of unit testing is to take the smallest piece of testable software in the application,
isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each
unit is tested separately before integrating them into modules to test the interfaces between modules.
Unit testing has proven its value in that a large percentage of defects are identified during its use.

Unit tests are used to exercise source code by directly calling the methods of a class. Appropriate
parameters are passed and the return value or state is verified against expected values, using Assert
statements. Unit test methods reside in test classes, which are stored in source code files. You can
create unit tests by using a code generation feature that creates the initial source code of the test, or
you can write the test completely by hand. Either way, the test class and all test methods are identified
by using programmatic attributes.

The goal of unit testing is to isolate each part of the program and show that the individual parts are
correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it
affords several benefits. Unit tests find problems early in the development cycle.

NUnit
NUnit is an automated unit testing framework for .NET. It is an open source product. You can get this
tool along with source code and modify the source code if required for your specific needs. NUnit is free
to use with your .NET projects.

VSTS Unit Testing

Team Test is a Visual Studio integrated unit-testing framework that allows for automatic code
generation of test method stubs and Code coverage analysis once the tests have run.

Recommendation

Page 6 of 10
Omega.NET Complete Reference

For developers working with code held in VSTS/TFS it is recommended to utilize VSTS unit testing
framework. For non VSTS based development environments NUnit is the suggested tool.
Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeVerification
.aspx

2.5. Code Coverage

Code coverage is a measure used in software testing. It describes the degree to which the source code
of a program has been tested. It is a form of testing that inspects the code directly and is therefore a
form of white box testing.
Test engineers can look at code coverage test results to help them devise test cases and input or
configuration sets that will increase the code coverage over vital functions. Two common forms of code
coverage used by testers are statement (or line) coverage and path (or edge) coverage. Line coverage
reports on the execution footprint of testing in terms of which lines of code were executed to complete
the test. Edge coverage reports which branches or code decision points that were executed to complete
the test. They both report a coverage metric, measured as a percentage.
There are a number of coverage criteria, the main ones being:
Function coverage - Has each function (or subroutine) in the program been called?
Statement coverage - Has each node in the program been executed?
Branch coverage - Has every edge in the program been executed?
Decision coverage (also known as branch coverage) - Has each control structure (such as an IF
statement) evaluated both to true and false?
Condition coverage (or predicate coverage) - Has each Boolean sub-expression evaluated both to true
and false? This does not necessarily imply decision coverage.
Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeCoverage.aspx

2.6. Code Analysis

During the implementation process, building applications with consistent code is considered one of the
main objectives, which the development team aims to, because it affects the final product quality. Code
Consistency means, writing code that follows the defined best practices while conforming to rules and
standards. Code review can be considered as one of the methods to guarantee code consistency, but
would be again prone to human errors. Hence the need to look at tool based / automated code analysis.
The term Code Analysis usually applies to the analysis performed by an automated tool. Static Source
Code Analysis is the process by which software developers check their code for problems and
inconsistencies. It is performed on the source code without actually having the need for execution. Code
Analysis tools use rules to specify the kind of analysis that needs to be performed.

Page 7 of 10
Omega.NET Complete Reference

These rules perform actions like checking for:

- Hardcoded locale specific strings
- Appropriate disposal of objects

Code Analysis tools scan the source code to detect errors that typically pass through compilers and
become latent problems. They generate reports that graphically present the analysis results and
recommend potential resolutions to identified problems. Sophistication of the code analysis varies from
those tools that only consider the behavior of individual statements and declarations to those that
include the complete source code of a program in their analysis.

Main advantages of performing Code Analysis are ( not limited to):

- Integrates quickly and easily into the standard development process
- Static Analysis can suggest improvements to your code based on a wide range of checks
- Rules that Static Analysis uses are extensible
- Static Analysis works on both Managed and Unmanaged code
- Static Analysis Rules violations can be configured to be reported as an Error or as a Warning
- Rules exclusions can be configured on a per project basis

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeAnalysis.aspx

2.7. Code Profiling

Performance is a primary priority in most of the applications. To create great-performing applications,

early in planning itself you should add requirements for responsiveness and create prototypes to
identify possible technology restrictions. Throughout the development, different performance aspects
of the application should also measured to find possible regression.

Finding performance bottlenecks is not an easy task without a code profiler. You can use
trial and error, sometimes spending hours, days, and even weeks blindly chasing
performance issues. Additionally, you could waste even more time tuning code that is not the cause
of any problem. It is rare for a bottleneck to be in the obvious place.

Even with best planning, you may still have to investigate performance problems during application
development. Code profiling can be used to identify performance issues within an application; it is the
act of collecting performance data (metrics) while an application or portion of the application is running.
This data can be analyzed to identify sections of code which cause performance bottlenecks.

A code profiler is a performance-analysis tool that measures the frequency and duration of function
calls. Results are then presented in a variety of formats, allowing you to see what is happening in your
source code. It allows developers to pin bugs down to a specific line of code, or determine scope of
optimization.

A code profiler analyzes your code in minutes, and the results allow you to:

Know how your code performs

Page 8 of 10
Omega.NET Complete Reference

Locate performance bottlenecks quickly

Optimize your code only where it is necessary

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeProfiling.aspx

2.8. Check In Policies

Check in policies are important to control and improve the quality of code that is checked into the
repository. Policies are implemented using rules to allow or deny code check-in for a developer e.g.
Dont allow check-in if the continuous integration build fails. Rules are invoked when user is checking-
in source code or other artifacts into the repository

Check-in policies enable execution of rules whenever a developer tries to check-in code to the code
repository. A policy can range in complexity from something as simple as ensuring you enter a comment
at check-in, to something more complicated such as performing static code analysis and running tests.
The policy passes when the build is up to date and there are no code analysis errors. This document
provides details on configuring the check-in policies. It also talks about the list of available policies and
how to create custom policies.

Effective checkin policies ensure sanity and reliability of the code repository. It helps in establishing
governance process for development team. Additional information can be captured during check-in and
the same can be used for traceability aspects as well.

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodeControl.aspx

2.9. Automated Build & Continuous Integration

Continuous integration is a technique that encourages developers to check-in their code more
frequently, have it compiled by an Automated Build Process, run a suite of unit tests, and report on the
status. The idea is to tighten the feedback loop so that the effect of an integrated change is
communicated back to the developer as soon as possible. By reducing the time between check-in and
build status, developers find it much easier to identify faulty code.

A continuous integration server is responsible for monitoring the source code repository for changes
that are made during check-in. When a change is detected, the server automatically:

Performs a full check-out

Perform automated Code Analysis
Cleans the build output folder
Forces a complete rebuild of the entire project
Executes all unit tests (optional)

Page 9 of 10
Omega.NET Complete Reference

Executes Build Verification tests (optional)

Reports on the build and unit testing status

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/AutomatedBuild.as
px

2.10. Code Promotion

Code promotion is a strategy that uses branches to promote code through some stabilization phases.
For example, you might have a Development branch in which your team does active development, a
Main branch in which your team is integrating and testing, and a Production branch that your team uses
for final release stabilization.

Project teams without a Code Promotion strategy are vulnerable to the following risk

Inefficiency due to the significantly long time between; when the feature was developed and
when it was fully tested.
Deferring the stabilization of features to the end of the project lifecycle, makes it impossible to
predict the duration of stabilization, to make it release ready.
Inability to reduce the scope of features to hit a release date because it was difficult to scale
back on features which, although had been coded, had not been stabilized. Scaling back on
scope was further exacerbated by the fact that newly developed features had introduced other
dependencies around them that were hard to back out.

Reference
https://gto/codenizant/OmegaDotNet/Shared%20Documents/CodePromotion.as
px

Page 10 of 10