Feasibility Study/Envisioning Phase

       This is the first phase of Software Development Life Cycle of the project. As per my experience, this phase bring in a lot of curiosity in the mind of project team and stakeholders. Like what technology would be best suitable for this project? How long will it take to complete this project successfully. How many resources required for accomplish this project. This phase can also be describe as broad description of the goals and constraints of the project. Each phase in the SDLC have interim and major deliverables. Major deliverables in this phase are Creation of project team and project structure, Vision/Scope statement and identification and mitigation of Risks associated with the project.  In this phase, Program management identify the Project team to accomplish goal and objectives of the project.  This is the initial phase of the project, team consist of only key team members who performs several tasks to kick off the project. This phase culminate in the Project vision/scope milestone. Vision/Scope milestone indicate that Project team and stakeholder agree on the goals and future direction of the project.

List of the tasks performed by the team are as follows:

Setting up the Project team:

SDLC consists of many activities and tasks. You need resources to accomplish those tasks. Each resource in project team assigned a role required to accomplish tasks for the project. Creation of project team which represents all the roles required for the successful completion of the project.

Creation of Administrative Structure

All the standards and process project team needs to follows identified and impart to the team. Administrative structure of the project also identified.

For example: Team decide on coding standard, Quality control, communication etc

Assessing the current situation and defining the business goal:

Analysis of the business problem and opportunities.

Analyzing and assessing the difference between current and expected situation. It helps us to find the problem statement and identify the direction and objecttive

of the project.

Creating a vision statement and defining the scope of the project:

Creation of a vision statement that communicates the long term direction for guiding the team towards its business goals. Identification of the scope of the project defines what will and will not be included in the solution.

Developing a solution concept:
 
Creation of a baseline solution concept, that is , the outlining of the approach that the team will take to create the solution. This concept is created by using the requirements that have been identified.

Identifying and Assessing risk:
 
Identification and assessment of the risks to the project, creation of a risk mitigation plan. This is an iterative step that is conducted during all stages of the product life cycle.
 
Closing the envisioning phase:
 
End of the envisioning phase. Accomplished when the vision scope document is formally approved by all stakeholders and the project team

Deliverables of the envisioning phase:
 
The team create deliverables for each task in the envisioning phase. Together, these deliverables provide context and direction for the team for the remainder of the project., and communicate the project vision and scope to the customer. Customer review the deliverables and approve it. Customer involvement in this phase is always greatest.

Also, since it is initial phase, so  this is right phase to impress the customer which is must for successful completion of the project.

If customer approve it, the project team then can go ahead with the next phase of SDLC i.e planning.
 
The deliverables that the team creates during the envisioning phase includes:
 
Vision/Scope
 
Problem statements and business objective
A review of the existing processes
A broad definition of user requirements
User Profiles identifying who will benefit from the solution.
A vision statement and scope definition.
The solution concept outlining the approach the team will take to plan the project.
Solution design strategies
 
Project Structure:
A description of all project team roles and a list of corresponding team members
A Project structure and process standards for the team to follow
 
Risk Assessment

A preliminary risk assessment
A list of the primary identified risks
Plan for mitigating or eliminating the identified risks

C# Sharp Coding Standard and usage Guideline

The Importances of Standards: 

 Coding is easy but writing an effecient code is hard. It is common practice that developer ignore the importance of the coding standards and guidelines due to project pressure and hectic deadlines. But they pay penalty for not using the coding standards in form of lot of rework when their program become ready for QA testing.

We can avoid a lot of hassle and hardship by following coding standards and guideline. For example, suppose you write a program without giving a variable a meaningful name and your program consists of many routines which are too big to understand. Your logic is very messy. Can you believe it how long will it take to debug the code. You maytake a lot of time even for fixing simple error.

The standards are importants because they allow group of people to commmunicate for the same perspective.

When it comes to any Software language coding standards, we can save a lot of time and rework by following coding standard for that particular language.

Code Documentation

Even with naming convention is in place, coding standard is very important. Depending on the objects being documented, it can tells us when it was created, and by whom.

Commenting Code

Comments are the most obvious form of code documentation. Use the appropriate comment style to  comment your code. Comment headers provide an overview of various

sections of your code.

Writing Clean Code

Clean code means that the code that can easily be read by other programmers.  The logic flow will be easy to follow, the object names will be self-descriptive and comments will be liberally sprinkled throughout. 

The Sixty-Second Rule 

A routine should be understandable within 60 seconds by a skilled developer.  If it cannot, this is usually indicative of a problem with the routine (too long, not commented, convoluted).  Be sure that your routines provide clarity in objective and operation by keeping them small, focused and well documented.

Single-Entry, Single-Exit

There is only one way to enter a method, and there should be only one way to exit a method.  Instead of having several return statements in a routine, save results in a single variable, scoped at the method level, and use a single return when processing is complete

Correct Way

public string OverUnder (int a_iNumber)

{

  // Code commenting template would go here…

 

  string sReturnValue = “”;

  if (a_iNumber < 5)

    sReturnValue = “Under”;

  else

    sReturnValue = “Over”;

  return sReturnValue;

}

Incorrect Way

public string OverUnder (int a_iNumber)

{

    if (a_iNumber < 5)

        return “Under”;

    else

        return “Over”;

}

Naming Convention

Name of the Variables and objects should be self descriptiive. It should help reader to understand the purpose of the objects or variable quickly and properly.

Notation Styles

Use the following three conventions for notating identifiers.

 

Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example:

Color BackColor;

 Uppercase

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example:

System.IO   

System.Web.UI

  Hungarian

Hungarian notation is a set of conventions for naming variables in which a programmer adds a meaningful prefix of one or several characters to the object’s name to identify what type of object it is. For example:

String sUserName;

 

Naming Variables Guidelines:

 Hungarian notation is a set of conventions for naming variables in which a programmer adds a meaningful prefix of one or several characters to the object’s name to identify what type of object it is.

Consistancy in naming convention is very important.

 Example:

 DataType                   Name

 Bool                           bIsValid

Integer                        iCounter

Char                          cStatus

.Net Controls

 Button                        BtnAdd

ComboBox                 cboStates

Database Objects

Connection                   connMaster

Dataset                         dsEmp 

Scope Modifiers

The following table depicts the various scope modifier prefixes to that will be used for all variables, parameters, and member functions contained within a class.

Examples:

Private:/Protected

         Variable                 :   _ :    _UserName

        Methods/Function:    _GetUserName()

        Property                     :  _MyProperty

Public:

        Variable                 :   _ :    UserName

        Methods/Function:    GetUserName()

        Property                     :  MyProperty

  General:

General
Parameters	a_	a_bCalcInProgress
Local variables	{none}	iCounter

 

Namespace Naming Guidelines:All namespaces are to be determined in an orderly fashion. A new namespace selection must be ran by the Program Management group first for approval.

The general rule for naming namespaces is to use the company name followed by the technology name and optionally the feature and design as follows.

CompanyName.TechnologyName[.Feature][.Design]

For example:

XXX.Media

XXX.Media.Design

Prefixing namespace names with a company name or other well-established brand avoids the possibility of two published namespaces having the same name. For example, XXX.EMS is an appropriate prefix for the Email Management System.

Use a stable, recognized technology name at the second level of a hierarchical name. Use organizational hierarchies as the basis for namespace hierarchies. Name a namespace that contains types that provide design-time functionality for a base namespace with the .Design suffix. For example, the System.Windows.Forms.Design Namespace contains designers and related classes used to design System.Windows.Forms based applications.

A nested namespace should have a dependency on types in the containing namespace. For example, the classes in the System.Web.UI.Design depend on the classes in System.Web.UI. However, the classes in System.Web.UI do not depend on the classes in System.Web.UI.Design.

You should use Pascal case for namespaces, and separate logical components with periods, as in XXX.EMS.Exceptions. In the case where branding employs nontraditional casing, follow the casing defined by your brand, even if it deviates from the prescribed Pascal case. For example, the namespace XXX.eDelivery illustrate appropriate deviations from the Pascal case rule.

Use plural namespace names if it is semantically appropriate. For example, use System.Collections rather than System.Collection. Exceptions to this rule are brand names and abbreviations. For example, use System.IO rather than System.IOs.

Do not use the same name for a namespace and a class. For example, do not provide both a Debug namespace and a Debug class.

Finally, note that a namespace should parallel an assembly name. For example, if you name an assembly XXX.EMS.dll, it should to contain a XXX.EMS namespace.

Class Naming Guidelines

The following rules outline the guidelines for naming classes:

·         Use a noun or noun phrase to name a class.

·         Use Pascal case.

·         Use abbreviations sparingly.

·         Do not use a type prefix, such as C for class, on a class name. For example, use the class name FileStream rather than CFileStream.

·         Do not use the underscore character (_).

·         Occasionally, it is necessary to provide a class name that begins with the letter I, even though the class is not an interface. This is appropriate as long as I is the first letter of an entire word that is a part of the class name. For example, the class name IdentityStore is appropriate.

·         Where appropriate, use a compound word to name a derived class. The second part of the derived class’s name should be the name of the base class. For example, ApplicationException is an appropriate name for a class derived from a class named Exception, because ApplicationException is a kind of Exception. Use reasonable judgment in applying this rule. For example, Button is an appropriate name for a class derived from Control. Although a button is a kind of control, making Control a part of the class name would lengthen the name unnecessarily.

The following are examples of correctly named classes.

public class FileStream

public class Button

public class String