Wednesday 27 November 2013

Extreme Programming

Extreme Programming (XP) is a lighter software development methodology or process which was developed to satisfy specific needs of small software development teams against constantly evolving requirements. In this methodology, quality software is developed and delivered quickly, then advancing it to meet the changing needs of the client.  Some of the characteristics of XP – continuous integration, small frequent releases which include continual customer feedback, pair programming, open workspace, simple design.

XP is tied up to specific values and roles as explained below:

XP Values

XP is based on four basic values:
  1. Communication: It is often noticed that projects fail due to lack of communication between the customer and team members or due to poor internal communication. XP favours different modes of rapid communication which also includes verbal communication where there is constant flow of communication / information between team members and customers.
  2. Simplicity: XP works on the philosophy of “Do the simplest thing that could possibly work”. This philosophy is followed not just in systems but also in methodology. The artifacts required are reduced to bare minimum – User Stories (requirements), Planning Game (plans) and Code (product). XP bets that it is better to do a simple thing today and make necessary changes tomorrow by a paying a little extra than to do something very complicated which may be never used in the future. 
  3. Feedback: Feedback is given a lot of importance in XP and is one of its critical components. Feedback from customers and developers is essential as it is crucial to understand what is wrong in the project as early as possible so that it is cheaper to make corrections. Continuous feedback ensures that the product is of high quality.
  4. Courage: IT takes a lot of courage to accept the XP methodology as it differs a lot from your traditional programming techniques. Courage and certain amount of aggressiveness are required from developers and customers. The role of customer differs in XP compared to other software development methodologies. A customer is much more involved in the project and spends more time onsite.

The XP Environment

  1. Extreme Listening: XP Planning is also known as Planning Game where the on-site customer and the other team members sit together and come up with desired features in the system. Each feature is written as a User Story which describes the feature and gives it a name. The development team provides an estimate of the effort and the time required for each User Story. Next, the business decides the priority of each User Story, the sequence of implementing them and the timelines of the system releases.
  2. Extreme Design: XP Design strictly follows the principle of simplicity. The software is designed in the simplest possible way. Designing in XP is not a one-time thing but a continuous process, there are improvements being made in the design for each release. Unnecessary complexity is avoided by following a test-driven approach in development. Programmers modify the design as and when required and refactor to create exactly what is required in the simplest possible way.
  3. Extreme Coding: The main practices of coding in XP are as follows:
    • Pair Programming – All the code in XP is written by two people working on a single machine. This practice ensures higher quality of code without hampering time to deliver. Another advantage of pair programming is the improvement in one’s knowledge area and skills.
    • Customer on site – XP insists that a customer must be present on site during the entire project as all the phases require constant communication with the customer.
    • Continuous integration – Developers must integrate the code and release it into the repository every few hours. Also, unit tests must be performed before and after integration so that there is always a releasable code available.  Integrating small units of code at multiple times during project saves time and complication of integrating complex code at a later stage.
   4.  Extreme Testing:
    • Code the Unit Test First – The test must be created before writing the code. This practice makes it much easier to write the code. The developer understands what exactly needs to be done.
    • Unit Tests – Unit tests are performed on individual modules before integration and after integration. This makes sure all the functionalities in the code are working.
    • Acceptance Tests – User Stories are used to create acceptance tests. Each of these tests represents an expected result from the system.

The XP Disadvantages

Some of the disadvantages of using Extreme Programming are as follows:
  1. XP assumes customer involvement at all times.
  2. Lack of proper documentation creates problems in big projects, especially when team members leave and new members join in.
  3. XP is code centric and not design centric approach. Lack of design can be a problem for huge projects.
  4. Too much refactoring can be a waste of time.
  5. Due to lack of structure in XP, it might be difficult for testers to find defects.
Extreme Programming is software development methodology based on values of feedback, communication, simplicity and courage. It provides a friendly, learning environment to maximize the team’s productivity. However, XP may not be a suitable methodology for huge projects.

About Author:
Kintu Racca is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at kintu.r@spluspl.com

Time when good Outsourcing contracts ends

One of the major concerns about outsourcing is that there may be “no way back” – but it can be done, in fact, decisions to continue a contract can be reversed early, however the right to do so can come at a high price.

Q: So what can be done to avoid high losses?
The answer is to recognize up front that everything comes to an end sometime, and to plan accordingly at the contract stage.

Q: First things first, what is recommendable?
Firstly, a long term deal should be avoided and should not be agreed to – 5 years is usually about right. Because one it can’t be told what the needs will be in the future: the organization will change, as will the outsourcer, as will the business and technology environment in which everything operates. It always costs more to exit mid-term than at the end of the term. For most deals 5 years works as it tends to take a year or so to complete the transition and ending the service, then a year or so to get into steady state, so it is not until the third year that a considered view can be taken as in how the deal is going.

Q: How long will exiting a deal in a controlled way take?
Exiting in a controlled way, especially if an organisation want to consider moving to another supplier, will take around 18 months… so 5 years works. Any longer and the company could be trapped in a deal which no longer works for it, and have to pay for the privilege of getting out.

Q: And what if there is a want to terminate before the end of an outsourcing contract?
It should be made sure that the company has a right to terminate for convenience at any time, and that you have agreed the costs of doing this in advance. Outsourcing providers will resist this strongly, arguing that both need to be committed to the deal, which, of course, is true. But the fact is that requirements change, and one may need to terminate early.

Q: What kind of rights does a supplier have in these circumstances?
If you do terminate early and you have no contractual right to do so, the outsourcing provider will be able to claim for damages, including loss of future profits. So agree in advance what you think would be fair – generally we recommend the principle that the supplier should be “made whole” (i.e., they should be able to recover reasonable trailing costs and unrecovered investments), but they should not be paid loss of future profits on work they have not delivered.

Q: What else can be done to prevent a difficult exit?
Construct a matrix setting out all of the possible circumstances in which the outsourcing contract could be terminated, and all of the possible costs which could be incurred by either party. Then clearly agree who should pay for what under what circumstances. Consider from first principles which party should bear which risks and construct the contract accordingly. For example, if you have to terminate the outsourcing contract early, should the outsourcing provider recover their pre-contract costs of sale? You might think clearly not, but many outsourcing providers seek to recover such costs.

About Author:
Prabhakar Ranjan works with Systems Plus Pvt. Ltd.  He is part of the consulting team that delivers Vendor Management Office projects. He can be contacted at prabhakar.r@spluspl.com

Monday 25 November 2013

Authenticate a service request based on username a nd password received

Steps for creating a secured service
  1. Create a blank solution; name it as wcf Security (not mandatory).
  2. Add two projects to it 1) Web application 2) wcf application.
  3. Add a service to wcf application and name.
  4. Add a method called “Dowork” and return a string.
public string DoWork()
{
return “Yes trying to do wcf authentication”;
}

Add a class to service application and name it as customvalidator.

public class CustomUserNameValidator : UserNamePasswordValidator
{
public override void
Validate(string userName, string password)
{
// peform
if (null == userName || null == password)
{
throw new ArgumentNullException();
}
if (!(userName == “test1″ && password == “1tset”) && !(userName == “test2″ && password == “2tset”))
{
throw new SecurityTokenException(“Unknown Username or Incorrect Password”);
}
}
}
}
  1. Inherit “UserNamePasswordValidator” this class.
  2. And override abstract method in the class. Use this class in service behavior.
  3. Add a new binding in web.config file of type ” wsHttpBinding” name the binding as your wish
  4. You can directly add this binding inside system.servicemodel .
<bindings><wsHttpBinding>
<binding name=”SampleBinding” closeTimeout=”00:10:00″ openTimeout=”00:10:00″ receiveTimeout=”00:10:00″ sendTimeout=”00:10:00″ bypassProxyOnLocal=”false” transactionFlow=”false” hostNameComparisonMode=”StrongWildcard” messageEncoding=”Text” textEncoding=”utf-8″ useDefaultWebProxy=”true” allowCookies=”false”>

<reliableSession ordered=”true” inactivityTimeout=”00:10:00″ enabled=”false” />
<security mode=”Message”>
<message clientCredentialType=”UserName”/>
</security>
</binding>
</wsHttpBinding>
</bindings>

Add behavior to your service

<behaviors>
<serviceBehaviors>
<behavior name=”Services.Products”>
<!– To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment –>
<serviceMetadata httpGetEnabled=”true” />
<!– To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information –>
<serviceDebug includeExceptionDetailInFaults=”true” />
<serviceCredentials>
<serviceCertificate findValue=”localhost” storeLocation=”LocalMachine”
storeName=”My” x509FindType=”FindBySubjectName” />
<userNameAuthentication userNamePasswordValidationMode=”Custom”
customUserNamePasswordValidatorType=”Services.SystemSecurityCustomValidator, Services” />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>


Add service configuration

<services>
<service name=”Services.Products” behaviorConfiguration=”Services.Products”>
<!– Service Endpoints –>
<endpoint address=”" binding=”wsHttpBinding” bindingConfiguration=”SampleBinding” contract=”Services.IProducts”>
<!– Upon deployment, the foll owing identity element should be removed or replaced to reflect the identity under which the deployed service runs.  If removed, WCF will infer an appropriate identity automatically.  –>
<identity>
<dns value=”localhost” />
</identity>
</endpoint>
<endpoint address=”mex” binding=”mexHttpBinding” contract=”IMetadataExchange” />
</service>
</services>

  1. Now create a certificate on your machine.
  2. You can use free certificate providers like plural sight’s makecert.
  3. Download tool and run as admin.
  4. Now create a certificate using the tool. Make sure you are creating a certificate which you are using in service behavior.
  5. Add certificate in IIS and host both the applications in IIS
  6. And you are ready with service, let’s work on client application.
  7. Add a new form to web application.
  8. Add a button to the form and a label.
  9. Keep text empty for label.
  10. Now add service reference to application.
  11. On button click add this code.
TestClient testservice = null;
public Default()
{
testservice = new TestClient();
testservice.ClientCredentials.UserName.UserName = “ECC”;
testservice.ClientCredentials.UserName.Password = “ECC”;
testservice.ClientCredentials.ServiceCertificate.Authentication.CertificateValidationMode =
System.ServiceModel.Security.X509CertificateValidationMode.Custom;
}
protected void Page_Load(object sender, EventArgs e)
{
}
protected void btnSubmit_Click(object sender, EventArgs e)
{
lblText.Text = testservice.DoWork();
}
  1. You can also retrieve credentials from db instead of hardcode values.
  2. If credentials are correct label displays the text, else throws an error.
About Author
Rachna Bagwe works with Systems Plus and is working on Dot net technology projects. She can be contacted at: rachna.b@spluspl.com

Friday 22 November 2013

Service Continuity Management

How can you protect your organization from disaster and minimize its impact on the day to day services? The simple answer is Service Continuity Management - also known as DCP (Disaster Contingency Planning), DRP (Disaster Recovery Planning) or just plain Disaster Recovery (DR) – yes, the list is endless. What is Service Continuity Management? And why is it so important to an organization? Service Continuity Management provides a framework for developing infrastructure plan to protect your organization from a disaster. Service Continuity Management ensures that your organization have an alternative option ready to ensure business continuity in the event of a significant outage or disruption. Service Continuity Management frameworks vary by region because different areas have different risks. Hence plans to tackle these outages or minimize the impact have to be different. All these plans are highly customized to meet business continuity requirements.

To build a robust IT continuity plan the IT team needs to take into account multiple factors that could impact the business. These could relate to IT security, environmental hazards or even a volatile political situation.

It goes without saying that implementing an IT Continuity plan would have a cost involved. For example, for critical IT operations a skeletal staff may have to be maintenance at an alternate location. Also IT services need to be provided to that staff as well. Hence implementation of the IT Continuity plan needs to be well thought of. On the face of it, looks like a dead investment however this needs to be evaluated in comparison with the losses the business would suffer in case the alternative is not available. The process of having a good IT continuity plan is not simple. It begins with identifying critical processes and what is the level of risks these are exposed to. The next step is to have an acceptable level of risk and then implement controls / mitigation steps to be taken in case of disaster.

One more very critical yet neglected aspect of having a good business continuity plan is the training of the personnel. It is very important for each and every person associated with the continuity plan to be very clear of the role that he or she has to play. Periodic training needs to be conducted to all the people to ensure that they are clear about the action that needs to be taken when the disaster occurs. This would also include steps to be carried out (backups, evacuation etc), personnel to be informed etc. It is also a good practice to invoke and test the SR or business continuity plan at least once a year to ensure that it is up and running.

Manage IT’s Service Continuity Management covers all the processes required to make sure that IT services can recover and continue even after a serious incident occurs.


About Author:
Dimpy Thurakhia is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at dimpy.t@spluspl.com

Wednesday 20 November 2013

RFS Replacing RFP?

Looking for alteration in your outsourcing engagements? – You might want to dump the conventional, decades-old request-for-proposal (RFP) process which was used to go through bidding process.”RFPs by their very nature are prescriptive in their requirements and prescription is almost antithetical to innovation,” Tom Young, partner with outsourcing consultancy ISG says.

The long established RFP approach facilitates comparison of like offerings . This makes selection and review process easier at the same time it obstructs or restricts innovation by prescribing a solution. The more the buyer indulges in RFP, the lesser is the innovation or flexibility. The RFS, on the other hand, opens the field to a broader pool of players – and potentially to innovative solutions. In contrast to a detailed, buyer-led RFP, the RFS is an open-ended, collaborative process. A buyer knows that he wants his IT environment transformed, however he might not know what needs to be done even though a detailed RFP implies he does. An RFS can reveal options an outsourcing customer may not have thought of. The customer describes its IT environment, objectives, concerns, and risk tolerance and the potential suppliers come back with unique solutions that meet those general requirements.

To better explain the difference between RFP and RFS process, Young takes an example of vacation-planning. With traditional RFP approach, you’d ask a travel agent find the cheapest package for a family of four to fly from New York to a hotel room within five miles of Disneyworld for five days in June. Whereas using RFS approach, you’d say you want to take a family of four on a five night vacation and spend $4000 or less and then select from the variety of options the agent provides that meets those criteria—a cruise, a camping trip, a European tour, or Disney. (Source: ISG Information Services Group – The RFP will never be the same)

Many big players who have been working with the traditional RFP approach and are doing fine may never go for RFS approach as it requires significant alteration in their sales practices as well. However, RFS is attractive for tier-two providers who may not have required resources to pursue major deals through the traditional RFP process.

Though RFS has quite significant benefits, it need not necessarily be applicable in all circumstances. Since the RFS involves selection criteria that are more qualitative, soft benefits such as “cultural fit” can trump traditional quantitative measures. Generally, the approach is better suited to solutions requiring innovation and transformation, or to situations that raise questions that have more than one right answer.

When it comes to straightforward optimization – no transformation, innovation or it includes components such as market standards or implementation of process improvement or best practices, the better suited approach would be RFP.

The traditional RFP has been an effective tool in enabling competitive pricing and efficient oversight of service delivery. But as client organizations mature and their approaches to sourcing become increasingly sophisticated and ambitious, new models are needed to allow for innovation and creativity. The Request for Solution offers a promising approach to enable service providers to leverage their expertise and capabilities to address the business challenges of their clients.


About Author:
Nisha Tolani is consultant and part of Systems Plus Pvt. Ltd. She is a part of consulting team that delivers Sourcing and Vendor Management Office projects. She can be contacted at: nisha.t@spluspl.com

Monday 18 November 2013

SQL Server XQuery Methods

SQL Server provides XQuery methods to query xml file or xml data. Using these methods we can Insert, Update, Delete data in xml file or in XML Data Type variable. In SQL Server XQuery statements are case sensitive since xml is case sensitive. Hence while query to xml data remember this thing.


XQuery Methods

We have following xml data to implement all the XQuery methods given below.


DECLARE @xml XML
SET @xml='<EmployeeMaster>
DECLARE @xml XML
SET @xml='<EmployeeMaster>
<Employee EmpNo="1" Name="Anand">
    <EmpSub No="1" Name="Maths"></EmpSub>
    <EmpSub No="2" Name="English"></EmpSub>
    <EmpSub No="3" Name="Hindi"></EmpSub>
</Employee>
<Employee EmpNo="2" Name="Edalquvin">
    <EmpSub No="1" Name="Maths"></EmpSub>
</Employee>
<Employee EmpNo="1" Name="Anitha">
    <EmpSub No="1" Name="History"></EmpSub>
    <EmpSub No="2" Name="Tamil"></EmpSub>
    <EmpSub No="3" Name="English"></EmpSub>
</Employee>
</EmployeeMaster>';


1. xml.exist()

This method returns a boolean value depends upon the condition in this method like as


SELECT @xml.exist('/EmployeeMaster/Employee[@Name = "Anand"]') as Result1
SELECT @xml.exist('/EmployeeMaster/Employee[@Name = "Aand"]') as Result2

Output
















2. xml.query()

This method takes an XQuery statement and returns an instance of the XML data type like as

SELECT @xml.query('/EmployeeMaster/Employee') as Employee

Output













SELECT @xml.query('distinct-values( data(/EmployeeMaster/Employee/EmpSub/@Name))') as Subject

Output










3. xml.value()

This method takes an XQuery statement and returns a single value after type casting like as


SELECT @xml.value('/EmployeeMaster[1]/Employee[1]/@Name',   'VARCHAR(4)') as ResultName

SELECT @xml.value('/EmployeeMaster[1]/Employee[2]/@Name', 'VARCHAR(4)') as ResultName


Output















4. xml.nodes()

This method takes an XQuery statement and returns a single value after type casting like as


SELECT x.value('@EmpNo', 'int') AS UserNo, x.value('@Name','varchar(50)') AS Email
FROM @xml.nodes('/EmployeeMaster/Employee') TempXML (x)

SELECT x.value('../@EmpNo', 'int') AS UserNo, x.value('../@Name',       'varchar(50)') AS Email, x.value('@Name', 'varchar(50)') AS ItemName
FROM @xml.nodes('/EmployeeMaster/Employee/EmpSub') TempXML (x)

Output





















5. xml.nodes()

This method takes an XQuery statement and modify the xml data like as


DECLARE @EmpNo int
Set @EmpNo=12
SET @xml.modify ('replace value of                   (/EmployeeMaster/Employee/@EmpNo)[1]      with sql:variable("@EmpNo")')
SELECT @xml;

Output















DECLARE @EmpNo int
Set @EmpNo=1
SET @xml.modify(' delete            EmployeeMaster/Employee/EmpSub[@No=sql:variable("@EmpNo")]')
SELECT @xml;

Output













About Author:
Anand Sahayaraj is technology lover and is important part of Systems Plus technology Think Tank. He works in Systems Plus Pvt. Ltd. and actively contributes to technology. He can be contacted at: anand.s@spluspl.com