Thursday, 19 December 2013

Choosing Between ASP.NET Web Forms and ASP.NET MVC?

Introduction

ASP.NET MVC is not a new architecture pattern but the debate still goes on in development circles as to which is better
.So, I just want to try to clear that differences and right usage of patterns. Let we go 10-15 years back and see how web has changed..

History of the web

We've seen a number of changes in web development over the years, not always for the better:
  • Common Gateway Interface (CGI) - Scripting language running outside the web server. Time and resource intensive
  • Microsoft Internet Database Connector (IDC) - Simple wrapper for SQL queries, with templates to format the results
  • Active Server Pages (ASP) - Big step forward but mixture of HTML and code became cumbersome and confusing. Known as "spaghetti code"
  • ASP.NET Web Forms - Compiled web "applications" which hides the "statelessness" of HTTP. Allowed Windows developers to more easily transfer to web developers. Heavy on bandwidth. Untestable.
  • ASP.NET MVC - Reworking of Xerox Smalltalk paradigm from the 1970's. Works WITH statelessness nature of HTTP rather than hiding it. Removes ViewState

Looking Back

We've seen a number of changes in web development over the years, like: Common Gateway Interface (CGI) - Scripting language running outside the web server. Time and resource intensive Microsoft Internet Database Connector (IDC) - Simple wrapper for SQL queries, with templates to format the results Scripting Active Server Pages (ASP) - Big step forward but mixture of HTML and code became bit confusing. Known as ASP.NET Web Forms - Compiled web "applications". It seems to take this bit confusion away We are thinking MVC :)

Choosing Between ASP.NET Web Forms and  ASP.NET MVC?

Fact is that both are just ASP.NET server side technologies known as Active Server Pages .Now where we split them or where is difference ? Actually these are architectural patterns or the way we develop .net web based applications.Both can be the “best choice” for a specific solution depending  application development requirements  . When facing a decision to choose between ASP.NET Web Forms or ASP.NET MVC it is important to know that neither technology is meant to replace the other. Both are running parallely and are used as per project requirement.Now, gap between two is getting filled as Microsoft is parellely including best features of MVC into ASP.NET Webform pattern also.
Some important factors we should consider while making the choice is
  1. If we really need to develop application rapidly, i believe ASP.NET Web Forms pattern is only and best choice
  2. Unit Testing - If  TDD test driven development is not important, ASP.NET web form is best choice.
  3. If Application really doesn't bother about UI scalability(UI for multiple devices) . ASP.NET is again best choice
Apart, there are lots of questions we need to consider before choosing architectural pattern like

  1. Do we have resources with good experience with Web Forms or MVC?
    Because learning MVC is not simple . It has its own learning curve and needs good time to learn.
  2. Be sure that we have people with JavaScript / JQuery based languages because MVC needs to do much with these languages 
  3. Looking for good performance without any postback? MVC is the choice but I know it point to be debated because ASP.NET has option of AJAX

Conclusion

Truth is that choosing  MVC pattern as architectural pattern need to be justified with strong reason otherwise it can never ever end or can lead to project failure because you don't have mature knowledge base yet compared to ASP.NET web-forms.I think you should be equipped with huge experience & information to make a decision what is best for your project. The complete decision depends on your team and project requirement.

Friday, 29 November 2013

Software Development Project Explained from Start to End

Introduction

If you think or dream of designing/developing software project, why you will think that project is always big .We can start project of minimal functionality rather than undertaking or thinking of a large project. You start with a small project, and should never expect it to get large. If you do, you will just over design and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the absolute size of the work you imagine. So start small, and think about the details. Don’t think about some big picture and great design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to fly in and help you. That’s not how these things work. You need to get something half-way useful first, and then others will feel confident on you and say, that “this almost works for me”, and they will get involved in the project automatically. Actually don’t try to be overconfident to finish application in one go. I still remember my academics when we were assigned with some programs of addition, subtraction.. Then gradually, we modified those small programs and made it functional as calculator program. I mean implement just one feature, and complete that. Then start another feature, and so forth. Otherwise, you will never get there. Apart, keep it clean, if at any stage your code gets a little disordered, refactor it before adding any more features. If you try and guess how you should try and modify the system for all future requirements, you're going to get everything wrong. Either you'll end up rewriting the code you never used, or you'll be stuck with code that sort-of does what you actually want it to do Apart, Copying and pasting text looks code in documentation part. I believe If you ever find yourself copy-and-pasting code, then that's a hint that you should pull out the common functionality of the code.
This Series of articles is written in almost 60 hours including sample project development carried out as a part of the using .NET Technology stack. Complete project can be downloaded from Click Here to download entire solution The project is not supervised or monitored by anyone except getting some vital feedback and clarification from some MVP’s , whom I thank for taking time to provide me a valuable comments and feedback in the process of designing and developing this application

Assumptions

  • You have worked with Microsoft visual studio any version.
  • You are very familiar with classes.
  • You have used .net framework classes.
  • You can create a form in Microsoft® Visual Studio® .NET.
  • You are familiar with relational databases and Microsoft ADO.NET.
  • You have created a simple service in Microsoft® .NET. 

Motivation


My motivation for writing this series of articles and doing this project follows the main goal of making a developers especially who want to grow as technical architects, Projects leaders ,Mentors or Technical independent Consultants aware and guide them in understanding End to End project implementation which includes:-
  1. Software development cycle SDLC
  2. Application architecture
  3. Solution structuring in Visual Studio
  4. Application Packaging
  5. Application Deployment

Regarding which they are always wondering and shy away from taking project initiative and trust me I have seen huge number of articles written by people without understanding the value of the layered or tiered approach to architecture. I know people love search engines because these search engines discover huge number of content which they are looking for but does anyone think whether the content is authentic? I am sure no one has time to think about it because they are looking for something which they get.
Apart, I Just want to make a programmer/developer comfortable to work practically on .NET projects stick on to proper software quality processes. I believe my words can just guide you but only your own effort of implementing my exercise or series of articles practically can make you expert and confident to some extent. But there is one more important thing that is Software quality process, which makes your development visibility clean
I aim to be more hard core developer and definitely over think about how to design or write better code? You can take the simplest problem and ask an endless list of questions like:
  1. What proper design pattern can I use here?
  2. What is the best way to structure my class hierarchy?
  3. What is the best way to reduce lines of code?
  4. If I have created separate layers, have I knotted them too much?
  5. Do I have a clean separation of code, like do I have a data access, business, Service & a UI layer?

After you’ve defined the problem, have some draft of the UI, understand the business rules, have a basic idea of how the code is going to look, you may find yourself where I do need to ask the above questions. I am sure that you are thinking about how to address above questions to get your code done?
Simply fallow below steps:-
  1. Ask your seniors and get positive as well as negative feedback from him/her
  2. Open .Net Framework or any free frameworks in Reflector and try to analyze how code has been written
  3. MSDN is the biggest knowledge ocean which can guide you a lot. I love the way it has been organized
  4. Ask MVP’S for help who run their own blogs and Forums
The whole idea of cleaning up your code, using patterns is an art. Nobody is an expert at anything on their first attempt, their second attempt, etc.Simple more you study and practice and learn the better you will reach on level where you will feel comfortable with designing great applications.

How This Article series is organized in Depth?

Software Development Life Cycle SDLC : -

IST Part will deal with Software life cycle which will include:-
  • Requirement Stage
  • Design Stage
  • Build Stage
  • Test Stage
  • Delivery Stage

Application architecture: -

Second part deals with architecturing application as per requirement. Which wilI include:-
  • Determine the Application Type
  • Determine the Appropriate Technologies
  • Determine the Deployment Strategy
  • Determine the Quality Attributes
  • Determine the Crosscutting Concerns

Solution Structuring in Visual Studio: -

Third part deals with Solution structuring. Which will include:-
  • Creating Solution
  • Adding Project Libraries to it
  • Determine the Crosscutting Concerns

Application implementation in Visual Studio

Fourth part deals with writing source code. Which will include:-
  • Creating Classes
  • Writing Source Code

Application Packaging

Final part deals with packaging of application which will include:-
  • Creating Solution
  • Adding Project Libraries to it
  • Determine the Crosscutting Concerns

Application Deployment

Final part deals with deployment of application which will include :-

  • Creating Solution
  • Adding Project Libraries to it
  • Determine the Crosscutting Concerns

Source Code of Entire Application

Finally your source code is here http://www.skypedrive.com:- As mentioned that first part of this series will deal with SDLC .I know this is theoretical so obviously boring too for coders

Software Development Cycle:-

Planning

Planning is an objective of each and every activity, where we want to discover things that belong to the project. An important task in creating a software program is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but do not know what software should do. Skilled and experienced software engineers recognize incomplete, ambiguous, or even contradictory requirements at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document.Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Implementation

is the part of the process where software engineers actually program the code for the project.

Software testing

is an integral and important phase of the software development process. This part of the process ensures that defects are recognized as soon as possible.

Documenting

the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the writing of an API, be it external or internal. The software engineering process chosen by the developing team will determine how much internal documentation (if any) is necessary. Plan-driven models (e.g., Waterfall) generally produce more documentation than Agile models.

Deployment

starts directly after the code is appropriately tested, approved for release, and sold or otherwise distributed into a production environment. This may involve installation, customization (such as by setting parameters to the customer's values), testing, and possibly an extended period of evaluation

Software training

and support is important, as software is only effective if it is used correctly

Maintaining

and enhancing software to cope with newly discovered faults or requirements can take substantial time and effort, as missed requirements may force redesign of the software
Software development process , also known as a software development life-cycle (SDLC), is a structure imposed on the development of a software product. Similar terms include software life cycle and software process. It is often considered a subset of systems development life cycle. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a life-cycle model a more general term and a software development process a more specific term. For example, there are many specific software development processes that 'fit' the spiral life-cycle model. ISO/IEC 12207 is an international standard for software life-cycle processes. It aims to be the standard that defines all the tasks required for developing and maintaining software.
Several models exist to streamline the development process. Each one has its pros and cons, and it is up to the development team to adopt the most appropriate one for the project. Sometimes a combination of the models may be more suitable

The figure shows waterfall BigBang model which has several stages and are described as below:-

Requirement stage: - This stage takes basic business needs required for the project which is from a user perspective so this stage produces typical word documents with simple points or may be in a form of complicated use case documents. In this book we will be using use case documents to describe this stage.

Design stage: - Use case document / requirement document is the input for this stage. Here we decide how to design the project technically and produce technical document which has Class diagram, pseudo code etc.

Build stage:-This stage follows the technical documents as an input so code can be generated as an output by this stage. This is where the actual execution of the project takes place.

Test stage:-Here testing is done on the source code produced by the build stage and final software is given a green flag. In this book we will have a test plan documents for this stage.
Deliver stage: - After succeeding in Test stage the final Article /project is finally installed at client end for actual Articleion. This stage is start for the maintenance stage.
Every activity has a life cycle and software development process too is an activity. Even if you are not aware of SDLC you still must be following it unknowingly. But if a software professional is aware about SDLC he can execute the project in a much controlled fashion. The greatest benefits of this awareness is that developers especially new developers will not start directly coding which can really lead to project running in an uncontrolled fashion. Second it helps customer and software professional to avoid confusion by anticipating the problems and issues before hand. In short SDLC defines the various stages in a software life cycle. But before we try to understand what SDLC is all about. We need to get a broader view of the start and end of SDLC. Any project started if it does not have a start and end then its already in trouble. It’s like if you go out for a drive you should know where to start and where to end or else you are moving around endlessly.

Above is a more global view of the how the start and end of SDLC. Any project should have entry criteria and exit criteria. For instance a proper estimation document & requirement document can be an entry criteria condition. That means if you do not have a proper estimation document in place the project will not start. It can be more practical, if half payment is not received the project will not start. So there can be list of points which needs to be completed before a project starts. Finally there should be end of the project also which defines saying that this is when the project will end or sign off . For instance if all the test scenarios given by the end customer is completed that means the project is completed. In the above figure we have the entry criteria as an estimation document and exit criteria as a signed document by the end client saying the software is delivered.

Below is the figure that shows typical flow in SDLC which has five main models .As per use developers can select model for their project.

Water fall

  1. Big Bang model
  2. Phased model.

Iterative

  1. Spiral model
  2. Incremental model.

Water fall


Let’s have a look on Water fall model which is basically divided into two subtypes:-

Big Bang Waterfall model

The figure shows waterfall BigBang model which has several stages and are described as below:-

Requirement stage: -

This stage takes basic business needs required for the project which is from a user perspective so this stage produces typical word documents with simple points or may be in a form of complicated use case documents. In this book we will be using use case documents to describe this stage.

Design stage: -

Use case document / requirement document is the input for this stage. Here we decide how to design the project technically and produce technical document which has Class diagram, pseudo code etc.

Build stage:-

This stage follows the technical documents as an input so code can be generated as an output by this stage. This is where the actual execution of the project takes place.

Test stage:-

Here testing is done on the source code produced by the build stage and final software is given a green flag. In this book we will have a test plan documents for this stage.

Deliver stage: -

After succeeding in Test stage the final Article /project is finally installed at client end for actual Articleion. This stage is start for the maintenance stage.


 

In this model, it is assumed that all stages are freezed that means it’s a perfect world. But in actual projects such processes are impractical.

Phased Waterfall model


In this model the project is divided into small chunks and delivered at intervals by different teams. In short, chunks are developed in parallel by different teams and get integrated in the final project. But the disadvantage of this model is there is improper planning may lead to fall of the project during integration or any mismatch of coordination between the team may cause huge failure.

Iterative model

Iterative model was introduced because of problems faced in Waterfall model. Now let’s try to have a look on Iterative model which also has two basic subtypes as follows:-
Incremental model
In this model work is break into parts like Waterfall model but the difference is that in Incremental model one team can work on one or many chunks which is contrasting from Waterfall model.
Spiral model
This model uses series of prototype which refine on understanding of what we are actually going to deliver. Plans are changed if required as per refining of the prototype. So every time in this model refining of prototype is done and again the whole process cycle is repeated.

Evolutionary model


In Incremental and Spiral model the main problem is for any changes in between SDLC cycle we need to iterate through the whole new cycle. For instance, During the final(Deliver)stage client demands for change we retreat the whole cycle again that means we need to update all the previous (Requirement, Technical document s, Source code & Test plan) stages. In Evolutionary model, we divide software into small units which can be earlier delivered to the customer’s end which means we try to full fill the clients needs. In the later stages we evolve the software with new customers needs.
Process improvement models
Capability Maturity Model Integration
The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.

ISO 9000
ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards have been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.

ISO/IEC 15504
ISO/IEC 15504 Information technology — Process assessment also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

Agile development

Agile software development is based on fundamental changes to what we considered essential to software development ten years ago.
The most important thing to know about agile methods or processes is that there is no such thing. There are only agile teams. The processes we describe as Agile are environments for a team to learn how to be Agile.
We realize the way a team works together is far more important than any process. While a new process can easily improve team productivity by a fraction, enabling your team to work effectively as a cohesive unit can improve productivity by several times. Of course to be eligible for such a big improvement you must be working at a fraction of your potential now. Unfortunately, it isn't that uncommon.
The most brilliant programmer’s alive working competitively in an ego-rich environment can’t get as much done as ordinary programmers working cooperatively as a self disciplined and self-organizing team. You need a process where team empowerment and collaboration thrive to reach your full potential.
The second change is making the customer, the one who funds the software development, a valuable and essential team member. When the dead line gets close a traditional approach to reducing scope is to let the developers decide what will work properly and what won't. Instead let the customer make scope decisions a little at a time throughout the project.
When your customer or domain expert works directly with the development team everyone learns something new about the problem. True domain expertise and experience is essential to finding a simple, elegant, correct solution. A document can have plenty of information, but real knowledge is hard to put on paper. Left alone programmers must assume they know everything they need. When asking questions is difficult or slow the knowledge gap grows. The system will get built, but it won't solve the problem like one guided by an expert on a daily basis.
Perhaps the biggest problem with software development is changing requirements. Agile processes accept the reality of change versus the hunt for complete, rigid specifications. There are domains where requirements can't change, but most projects have changing requirements. For most projects readily accepting changes can actually cost less than ensuring requirements will never change.
We can produce working software starting with the first week of development so why not show it to the customer? We can learn so much more about the project requirements in the context of a working system. The changes we get this way are usually the most important to implement


Agile also means a fundamental change in how we manage our projects. If working software is what you will deliver then measure your progress by how much you have right now. We will change our management style to be based on getting working software done a little at a time. The documents we used to create as project milestones may still be useful, just not as a measure of progress.
Instead of managing our activities and waiting till the project ends for software, we will manage our requirements and demonstrate each new version to the customer. It is a hard change to make but it opens up new ways to develop software.
Take a guided tour of Agile Development by following the buttons starting here. Or continue your guided tour of Extreme Programming by following the buttons. Let's look at how we manage by features next.

Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile processes fundamentally incorporate iteration and the continuous feedback that it provides to successively refine and deliver a software system.
There are many variations of agile processes:
Extreme Programming (XP) , the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. The same people who do the coding do design. (Only the last feature — merging design and code — is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.
Scrum is the most commonly used agile process. The results from the 7th Annual State of Agile Development Survey showed that 72% of respondents were practicing scrum or a variation in 2012.

Rapid Application Development (RAD) Model


Rapid application development R.A.D is a software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.RAD involves methods like iterative development and software prototyping According to Whitten (2004), it is a merger of various structured techniques, especially data-driven Information Engineering, with prototyping techniques to accelerate software systems development
In rapid application development, structured techniques and prototyping are especially used to define users' requirements and to design the final system. The development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively; further development results in "a combined business requirements and technical design statement to be used for constructing new systems”


Code and fix

"Code and fix" development is not so much a deliberate strategy as an artifact of naïveté and schedule pressure on software developers. Without much of a design in the way, programmers immediately begin producing code. At some point, testing begins (often late in the development cycle), and the unavoidable bugs must then be fixed before the product can be shipped.

V-model

This type of model was developed by testers to emphasis the importance of early testing. In this model testers are involved from requirement stage itself. So below is the diagram which shows how for every stage some testing activity is done to ensure that the project is moving as planned. For instance, In requirement stage we have acceptance test documents created by the testers. Acceptance test document outlines that if these test pass then customer will accept the software. In specification stage testers create the system test document. In the coming section system testing is explained in more elaborate fashion. In design stage we have integration documents created by the testers. Integration test documents define testing steps of how the components should work when integrated. For instance you develop a customer class and Article class. You have tested the customer class and the Article class individually. But in practical scenario the customer class will interact with the Article class. So you also need to test is the customer class interacting with Article class properly. In implement stage we have unit documents created by the programmers or testers.



Let’s try to understand every testing phase in more detail.
Unit Testing: Starting from the bottom the first test level is "Unit Testing". It involves checking that each feature specified in the "Component Design" has been implemented in the component. In theory an independent tester should do this, but in practice the developer usually does it, as they are the only people who understand how a component works. The problem with a component is that it performs only a small part of the functionality of a system, and it relies on co-operating with other parts of the system, which may not have been built yet. To overcome this, the developer either builds, or uses special software to trick the component into believe it is working in a fully functional system.
Integration Testing: As the components are constructed and tested they are then linked together to check if they work with each other. It is a fact that two components that have passed all their tests, when connected to each other produce one new component full of faults. These tests can be done by specialists, or by the developers. Integration Testing is not focused on what the components are doing but on how they communicate with each other, as specified in the "System Design". The "System Design" defines relationships between components. The tests are organized to check all the interfaces, until all the components have been built and interfaced to each other producing the whole system.
System Testing: Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In fact it is one giant component.



System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. In addition to functional requirements these may include the following types of testing for the non-functional requirements:

  • Performance - Are the performance criteria met?
  • Volume - Can large volumes of information be handled?
  • Stress - Can peak volumes of information be handled?
  • Documentation - Is the documentation usable for the system?
  • Robustness - Does the system remain stable under adverse circumstances?
There are many others, the need for which is dictated by how the system is supposed to perform.

Acceptance Testing: Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus:
Systems testing checks that the system that was specified has been delivered. Acceptance Testing checks that the system will deliver what was requested. The customer should always do acceptance testing and not the developer. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. This testing is more of getting the answer for whether is the software delivered as defined by the customer. It’s like getting a green flag from the customer that the software is up to the expectation and ready to be used.



Which is the best model?


In the previous section we looked through all the models. But in real projects, hardly one complete model can full fill the entire project requirement. In real projects, tailor model are proven to be the best because they share features from all models such as Waterfall, Iterative, Evolutionary models etc and can fit in to real life time projects. Tailor model are most Articleive and benefited for many organization. I am going to rely on Big Bang Waterfall model. In waterfall project output of every stage will be freezed as explained earlier no changes will be accepted once the requirement document is freezed.
What ever model you fallow, they are almost same in terms of phases you work with .Truth is that Choosing model is demand from client or sometimes taste.

Essential documentation in projects


In the previous section we discussed the various SDLC lifecycle models. For every stage in the model we have documents created according to phases such as:-


  • Requirement stage we have the Use case document
  • Design stage we have the Technical Design document
  • Build stage we have the source code
  • Test stage we have the Test result document
  • Deliver stage we have the sign off document
There is different documentation for every project and these documents change from organization to organization and obviously project to project.For instance, some organization will have 3 documents and some will have 12 documents in a project depending upon project manager or the policy of the organization to execute a project.
Let’s try to see what each document is about:-

Requirement document:- requirement document can be a single English document, probably a recorded audio or video conversation or can be a complicated use case. In short it’s something raw which comes from the end client.
Estimation document: - After getting requirement from the user we can judge cost for the project. In this book we will be using the function point estimation model. There is a complete chapter which is dedicated to function point in this book.
Use case document:- document which serves as an input to the Design stage
Technical document:- This document contains detail of how the project being executed such as pseudo code, class diagram, objects diagram, etc.
Test result document: - This document is written by the testers which describe the test plan which needs to be executed and thus giving project a green flag to Articleion.
Source code: - This is not basically a document but one of the important deliverable which maps to the execution phase of SDLC cycle.

Unified Modeling Language UML

The main object of UML is to make the project understanding more clear. It is a global computer industry modeling language to communicate between software professional in a project. UML helps us to create documents, artifacts & also give visualization so that we can understand the complex software engineering process of a project. There are 12 diagrams in UML but only three views of the project from UML perspective they are as below:-


  • Structure diagram
  • Behavior diagram
  • Model management diagram

Structure diagram

They are used to show static structure of an application. Let’s try to understand what word static means here. For example a civil Engg makes a model of a building. The outer structure of the building will remain same but inner part of the building for instance the structure of rooms and passages (one room, two rooms etc) can vary. Same holds true when we talk about software industry there are static part and dynamic part of project. For example classes in project will rarely change. Yes the attributes and methods in the class will change as user adds new functionalities. For instance in the below figure you can see the Invoice header will have multiple invoice details. The structure and relation between Invoice header and Invoice detail will never change. But yes the invoice can pass through multiple stages like open invoice, closed invoice or pending invoice which is dynamic.
Figure 1.5: - Project static nature UML has four types of structure diagram:-
  • Class diagrams
  • Object diagrams
  • Component diagrams
  • Deployment diagrams

Behavior diagram

UML gives us five Behavior diagram. They are used to show dynamic structure of an application. Let’s try to understand what does a dynamic structure of a project means. In a typical software project we can have business validations. Business validations of a project are of very dynamic nature. For instance an invoice can have lot of states for instance open invoice, closed invoice and paid invoice. And your software will change the invoice object from one state to other state. This is a dynamic nature of the project.
Figure 1.6: - Project behavior in action
The above figure shows how the invoice section moves dynamically by making transition from one state to other state. In UML to represent this kind of dynamic nature there are five diagrams.
  • Use Case diagrams
  • Sequence diagrams
  • Activity diagrams
  • Collaboration diagrams
  • State chart diagrams

Model management diagram

Model management diagram gives a view how different application modules are managed, grouped and classified. For instance the below figure shows how Accounting, Payment and common routines are grouped and organized.
Figure 1.7: - Model Management diagram in action
UML provides three diagrams by which we can get the Model Management view. Below are the three diagrams:-
  • Packages
  • Subsystems
  • Models

Overall Explanation of the UML diagrams

These are available libraries/Diagrams in almost all the known tools like
  • UML
  • Enterprise Architect
  • Visio
  • Edraw
Class diagram Use to show real-world entities, elements of analysis and design, or implementation classes and their relationships

Object diagram used to indicate the conditions for an event, such as a test or an operation call

Composite structure diagram Use to show the how something is made. Especially useful in complex structures-of structures or component-based design

Deployment diagram Use to show the run-time architecture of the system, the hardware platforms, software artifacts (deliverable or running software items), and software environments (like operating systems and virtual machines).

Component diagram Use to show organization and relationships among the system deliverables

Package diagram Use to organize model elements and show dependencies among them

Activity diagram Use to the show data flow and/ or the control flow of a behavior Captures workflow among cooperating objects

Use case diagram Use to show the services that actors can request from a system in actor and role form

State /protocol state machine diagram Use to show the life cycle of a particular object, or the sequences an object goes through or that an interface must support

Overview diagram Use to show many different inter- action scenarios (sequences of behavior) for the same collaboration (a set of elements working together to accomplish a goal)

Sequence diagram Use to focus on message exchange between a group of objects and the order of the messages

Communication diagram Use to focus on the messages between a group of objects and the underlying relationship of the objects

Timing diagram Use to show changes and their relationship to clock times in real-time or embedded Systems work

Which diagram is important?


In above table we have seen the basic use of all the UML diagrams. But in real projects we do not draw all the diagrams instead we look towards the complexity of the project or necessity of the project and accordingly we decide the diagrams and then diagrams are added to the technical document or the requirement document. So in this series of article we will use only required diagrams extensively:-
  1. Use case diagrams
  2. Class diagrams
  3. Component diagram
  4. Sequence Diagram
Let’s try to understand them one by one:-

Use case diagram overview

It’s a user functionality which the user wants to be completed by the system. For example Common scenario is that user wants to login in system. So basically it defines the actions of the user in the system. It basically defines actions of the system. The best way to identify a use case is by extracting verbs of the requirement document given by the end customer/Client, which you can name as user stories in Agile World
Actors and Goals Every use case will have the below two components actors and goals. Actors are stake holders of the system. Stake holders provide requirement to your project and oppose in case of any issues. Normally software users are the actors. For instance in an accounting application accountant forms as an actor and for the same accounting application we have cashier and charted accountant as another form of actors for the system. Every actor has goal to perform when using the system. There are two types of actors:-

Primary Actor:-This actor actually initiates the use case on the system.

Secondary Actor:-While Secondary Actor contacts other actors or use cases to meet the Primary Actor’s goal.
[Picture stolen from MSDN]
The examples used in this topic relate to a Web site on which customers can order meals from local restaurants.
  • An actor (1) is a class of person, organization, device, or external software component that interacts with your system. Example actors are Customer , Restaurant , Temperature Sensor , Credit Card Authorizer.
  • A use case (2) represents the actions that are performed by one or more actors in the pursuit of a particular goal. Example use cases are Order Meal , Update Menu , Process Payment . On a use case diagram, use cases are associated (3) with the actors that perform them.
  • Your system (4) is whatever you are developing. It might be a small software component, whose actors are just other software components; or it might be a complete application; or it might be a large distributed suite of applications deployed over many computers and devices. Example subsystems are Meal Ordering Website , Meal Delivery Business , Website Version 2 .A use case diagram can show which use cases are supported by your system or its subsystems
In every project we have use case documents as a part of requirement gathering. So once you go through those use case you will have good understanding of the same.


Sequence Diagram:
Sequence Diagrams are interaction diagrams that detail how operations are carried out Interaction diagrams model important runtime interactions between the parts that make up the system

  • Interactions Diagrams
  • Sequence diagrams
  • Interaction overview diagrams
  • Timing diagrams
  • Communication diagrams
When to Use Sequence Diagrams

  1. You should use sequence diagrams when you want to look at the behavior of several objects within a single use case.
  2. Sequence diagrams are good at showing collaborations among the objects.
  3. They are not so good at precise dentition of behaviour.
Here is the flow of events used for the typical creating new account use case. The Open a New Account page uses the following ASP.NET file and C# code behind files:
  • NewAccount.aspx
  • NewAccount.aspx.cs
Sequence Diagram

 
Process Overview The Open a New Account process is initiated in the User Services Layer (USL). A user inputs his or her first name, last name, password, and e-mail address. After the USL validates the information through validator controls, it passes the information to the Business Logic Layer (BLL) via the FMStocks7.BLL.Account.Add method of the Account object. The BLL then passes the information to the Data Access Layer's (DAL) AccountAdd object. The DAL then calls the Account_Add stored procedure (SPROC) in the SQL Server database. If the SPROC is successful, it adds the information to the accounts table. Otherwise, it returns to the Open a New Account page and the process is repeated. Upon successfully adding a new record to the accounts database, the Generic Accounting Module (GAM) object additionally creates an account with a cash balance of US$10,000.00; this is all done in a distributed transaction. The user is then redirected to the login page and the E-Mail field is filled in.

 that we would use a second flow of events for the case where the user is not authenticated.
So for the same we need to document it using use case documents which is explained in the coming section. In the next section we will go through a use case template which we will use in most of the project. Use case templates can be used to expand on the above diagram in more detailed way.

Detail Explanation of the Use Case template

Below is the use case template which we will be using in most of our project. So let’s understand every section of the template.

How do Interaction Diagrams help?

  1. Check use cases
  2. Check class can provide an operation { showing how a class realizes some operation by interacting with other objects
  3. Describe design pattern {parameterising by class provides a scheme for a generic interaction (part of Software Architecture)
  4. Describe how to use a component {capturing how components can interact
A web-based system is an example of a 3-tier client-server web architecture with a presentation layer, a business logic layer, and a database layer.

  • The presentation layer is the client browser with HTML and JavaScript (for interactively and data validation).

  • The business logic layer is the IIS web server with server-side processing using ASP (VBScript) and the database server supporting T-SQL.

  • The data layer is a SQL database that is on the database server
In a simple web-based system such as this, the system for the login problem could represent a combination of

  • a web browser with HTML (Hypertext Markup Language) using client-side JavaScript processing,
  • connected via HTTP (hypertext transfer protocol) to a web server running server-side ASP (Active Server Pages),
  • and connected via ADO (ActiveX Data Objects)
  • a database server supporting SQL (Structured Query Language).
We can now improve our sequence diagram to the following using a UML sequence diagram. The steps are summarized here as the following flow of events.

  1. The user/Actor clicks on a link to go to the login page or simply browses through browser using url like www.articlegallary.com
  2. The web browser requests the login page from the web server.
  3. The web server sends the login page to the web browser
  4. The web browser displays the login page to the user.
  5. The user inputs the login form.
  6. The user clicks on the login button.
  7. The web browser validates the information supplied by the user.
  8. The web browser submits the login form to the web server.
  9. The web server sends the authentication request to the database server/Active Directory
  10. The database server requests the relevant data from the database.
  11. The relevant data is returned from the database.
  12. The database server/windows Active directory uses this data to authenticate the user and send the result to the web server.
  13. The web server sends the page to the web browser.
  14. The web browser displays the landing page to the user.

Class diagram

Class is basically prototype /Template which helps us create objects. Class defines the static structure of the project. In the below figure you can see how the class diagram looks. Basically there are three important sections which are numbered as shown in the below. Let’s try to understand according to the numbering:-
Class name:- This is the first section or top most section of the Class which represents the name of the Class (Article).
Attributes:- This is the second section or the middle section of the class which represents the properties of the system.
Methods: - This section carries operation or method to act on the attributes.

Figure 1.12: - Three sections of the Article class
Now we will have a look on Association relationship between these classes

Associations in Class diagrams

A single Class cannot represent the whole module in a project so we need one or more classes to represent a module. For instance, a module named ‘Article details’ cannot be completed by Article class in order to complete the whole module we need Article class, ArticleCategory class, .. in short there is relationship between the classes. So by grouping and relating between the classes we create module and these are termed as Association. In order to associate them we need to draw the arrowed lines between the classes as shown in the below figure. In this figure, we can see Article class and the Comment class and arrowed line showing
relationship that comment class is shown using article class in other words order class is
going to be used by Article class to show Article with comments. The left to right marked arrow basically shows the flow that comment class uses the Article class.

Figure 1.13:- comment is shown by Article class
There are four signs showing the flow:-
Figure 1.14:- Direction signs in UML
In this Association there are two types mainly Aggregation Association and Composition Association.
Aggregation Association
Aggregation Association signifies that the whole object can exist without the Aggregated Object. For example in the below figure we have three classes university class, department class and the Professor Class. The university cannot exist without department which means that university will be closed as the department is closed. In other words lifetime of the university depend on the lifetime of department.
Composition Association
In the same figure we have defined second Association between the department and the Professor. In this case, if the professor leaves the department still the department continues in other words department is not dependent on the professor this is called as Composition Association.

The filled diamond represents the aggregation and the empty diamond represents the composition. You can see the figure below for more details.

Multiplicity

Multiplicity can be termed as classes having multiple associations or one class can be linked to instances of many other classes
Composite structure diagram
When we try to show Aggregation and Composition discusses above in a complete project the diagram becomes very problematical and very complex so in order to keep it simple and visible we can use Composite structure diagram.
Reflexive associations
In many scenarios you need to show that two instances of the same class are associated with each other and this scenario is termed as Reflexive Association.
Figure 1.18: - Reflexive association
Generalization and specialization
In Generalization and Specialization we define the parent-child relationship between the classes. In many instance you will see some of the classes have same properties and operation these classes are called super class and later you can inherit from super class and make sub classes which have their own custom properties. In the below figure there are three classes to show Generalization and Specialization relationship. All phone types have phone number as a generalized property but depending upon landline or mobile you can have wired or simcard connectivity as specialized property. In this diagram the clsphone represent Generalization whereas clslandline and clsmobile represents specialization.
Figure 1.19:- Generalization and Specialization
Note: - I

Estimation


Sometime I believe that it is hard for one to estimate unless and until you do a fine grained analysis of the system. It's one thing to estimate effort as opposed to time. Effort calculations can be more transitive across teams as they estimate things on basis of components, function points, lines of code, modules, screens, etc. For me I believe unless you're keeping a record of time spent on previous projects, how can you expect to estimate future ones? I personally recommend just decide on an effort metric and you continue to track your time spent developing solutions next to it.

I believe without any historical data or previous experience you can’t provide a promising estimation. If you don't have a SharePoint developer resource to review your estimations (and point out architectural choices and high risk issues), you can only rely on a scale of magnitude of accuracy. I guess an technical resource should be part of every estimation

Testing Document

The success of every project is keep testing….. the current project which I am doing along with this series have simple test plan. Below is the simple paste of a sample. This is basically an Article gallery application. The below action is when user updates the Article details. So basically we define steps with pass and failed conditions.
Update Article
Steps for the test:
  • Start the Article gallery application
  • Select one of the article from the article data grid. Article details will be displayed on the textboxes.
  • Modify some information in all the three fields.
  • Press Modify button Passed condition
  • System should save the changed information and display the newly entered data in the grid.
  • Failed condition: The system is not able to update the address data.

Application architecture: -  Coming Next........

Shabir Hakim

Wednesday, 20 November 2013

DECIDE WHAT TYPE OF CONTENT PAGES TO USE WHILE MAKING YOUR INTRANET?

Components of SharePoint Platform

The SharePoint product comprises many different components . Every component is described below with respective tasks they perform
  • SharePoint Foundation: SharePoint Foundation is a foundational program that enables communication, collaboration, and content management; it comes free with the Windows Server operating system.
  • SharePoint Server: SharePoint Server is a full-featured software product that provides industrial-grade communication, collaboration, and content management. It’s like SharePoint Foundation on steroids. SharePoint Server comes in an Enterprise and Standard edition for both Internet sites and Intranet sites.
  • InfoPath Form Services: This feature of SharePoint Server allows InfoPath forms to be embedded in SharePoint Web sites.
  • Excel Services: This feature of SharePoint Server embeds Excel documents in a SharePoint Web site where they can be viewed (which helps with version control).
  • SQL Server Reporting Services (SSRS) Integration: This feature installs an SSRS server in such a way that it works closely with the SharePoint environment. In an integrated installation, SSRS reports are contained and managed in SharePoint instead of in a standalone program (Report Manager).
  • Key Performance Indicator (KPI): A feature of SharePoint (and of SSAS) that provides a quick visualization of business information that the organization considers indicative of how well it’s doing. KPI data is contained in a KPI list that can be embedded in SharePoint Web sites.
  • Business Connectivity Services (BCS): BCS is a feature of SharePoint that connects to Line of Business (LOB) systems and displays the data that they contain in the SharePoint environment. The data can then be manipulated (read and write) directly from SharePoint with users having to know, or care, where the data lives behind the scenes.
  • Sites: A SharePoint site is a Web site that SharePoint manages in ways that are compatible with its content-management features. SharePoint sites can contain many user facing SharePoint features such as Document Libraries, Lists, Wikis, Blogs, and Discussion Boards.
  • Document Libraries: A mechanism for storing content within SharePoint. A Document Library provides content management (which includes document check-in and check-out, versioning, security, and workflow).
  • Lists: Lists of data, made available on a SharePoint site, that store data in columns and rows. Almost all of the user facing SharePoint features stem from Lists. For example, a Calendar is actually a specialized List under the covers.
  • Wikis: Specialized Web sites that allow community members to update content on the fly. SharePoint provides wiki functionality as a feature.
  • Blogs: A Web log or online journal. A blog provides a forum for people to write communications that can be viewed across the entire organization. Once a blog entry is posted, the content can attract comments and discussions on the entry page. Blogs came to prominence as personal online journals; SharePoint provides tools for getting business blogs up and running in a manner of minutes.
  • Discussion Boards: A designated intranet location for online discussion, accessible throughout the organization. A discussion board provides a forum for people to post questions and replies that can be viewed throughout the organization.
  • Performance Point: A feature of SharePoint that is designed to build advanced scorecards, dashboards, and reports.
  • Dashboard Designer: An end user tool that can be launched from SharePoint and is designed to build Performance Point content.
  • Report Builder: An end user tool that can be launched from SharePoint and is designed to build SQL Server Reporting Services (SSRS) reports.
  • Scorecard: A collection of data that includes graphs, charts, numbers, and other visualizations of information that is designed to show progress towards a stated goal. For example, you might have a Scorecard that shows sales per quarter per sales person and how well that sales person is performing against a target goal.
  • Dashboard: A Dashboard is much like a Scorecard with the difference being that a Dashboard shows the status of key information but is not necessarily in relation to an overall goal. For example, you might have a dashboard showing current production on a day, week, month, and year to date scale without having a specific target production output you are trying to reach.
INTRODUCTION
I am sure that all types are required and while designing corporate intranet we will end up with using all the three.I still feel like there are differences which are worth discussing because while implementation we should use these pages very cautiously and on right place.
Here are three types of pages available

Type 1: Publishing Page
Default Location: Pages library
Typical Usage Scenario: Complete control over look and feel; more granular content management.
Type 2: Web Part Page
Default Location: None; can reside in any library or folder
Typical Usage Scenario: To display Web Parts; no content management requirement.
Type 3: Wiki Page
Default Location: Site Pages
Typical Usage Scenario: Pages that look and function like the home page.
Let me explore bit and show you which page to use where?

Here you see option in SharePoint where we create pages for our SharePoint portal..


WIKI PAGES

If you are sure that content presentation and standardization of layouts is less important then choose Wiki because of it’s WYSIWYG in-page editing capabilities, this is unique and great choice for end-users to create and manage contents on their team sites in more easy and flexible way.This page type is available in 2010 onwards.Apart,Wiki pages can be version ed  and display history of changes and are stored in Page Library which is really easy for accessibility and to update


WEB PART PAGES
 In This type of page content on a web part page is displayed using web parts. Web Part pages are structured web part content including lists, libraries, and other collaborative content including rich media, other web pages, search results, and an aggregation of information. You can’t add text or image easily on web part pages – it requires web parts like content editor or image web parts. This is one of the major disadvantages of web part pages over wiki pages

PUBLISHING PAGE

Publishing pages are designed for creating content pages in more controlled manner with consistent look & feel. These pages are based on page layouts and content types. Publishing pages content can be version-ed and display history of changes. Publishing pages optionally allows passing articles through proper page approval and page scheduling life cycle.Publishing pages are stored in Pages library. This library is available when publishing infrastructure is enabled on the site. You can't have more than one pages library per site.This page type is available since 2007 version


CONCLUSION:

Talents differ but everything is well and wisely put. All three pages are required while designing your intranet like If you have to design most structured content with fixed page layout just use publishing pages
If you want to standardize the look & feel and layout of home pages across intranet for multiple departments. Web part pages is good choice for us to allow department content owners to add content in more controlled manner.Finally if you don't bother about content presentation and standardization of layouts just choose Wiki because of it’s WYSIWYG in-page editing capabilities.





Tuesday, 19 November 2013

MY SUZUKI FIERO 2001 MODEL HAS CROSSED 291000 KMS and Still RUNNING..

WHO WILL FORGET LOVABLE SUZUKI FIERO

Suzuki Fiero was the first 150cc 4-Stroke bike launched in India. The Bike was the best 150c bikes of that time. Even when the CBZ powered with an 156cc, it can produce an output power of only 12.8bhp.

TVS after breaking with suzuki has tried lot to use name of fiero but said to say that they couldn't.
Now a days people talk about APACHE , They don't know Apache engine is just fiero engine modification which belongs to suzuki. :)

Even today it stands as a classic bike in the hearts of Indians.

Specifications:

  1. Engine Displacement: 147.5cc
  2. Engine type: 4 Stroke, SOHC
  3. Output power: 12Bhp@7500rpm
  4. Engine torque: 10.5nm@6500rpm
  5. Fuel Capacity: 13Ltrs
  6. Weight: 115Kgs(dry)/127Kgs(wet)
  7. Transmission: 5 Speed
  8. Top Speed: 110Kmph
My SUZUKI FIERO 2001 MODEL BIKE WAS ABOUT TO CROSS 3 LAC KMS IN SPAN OF 14 YEARS GOT  BORED  LAST WEEK. I really have experienced a great ride from suzuki fiero bike.
Thank you very much to suzuki who has provided such a great model and now i am moving to GIXXER which i believe will give me same taste.




 

 

Suzuki Bikes in India

Suzuki has 12 Bikes models available in India. The available models are Suzuki,Suzuki Gixxer,Suzuki Inazuma, Suzuki Access, Suzuki Bandit, Suzuki GS, Suzuki Hayabusa, Suzuki Intruder M1800R, Suzuki Slingshot, Suzuki GSXR, Suzuki Intruder, Suzuki Swish, Suzuki Hayate, . The minimum priced model of Suzuki is Suzuki Inazuma priced at Rs 150000 and the maximum priced model of Suzuki is Suzuki Inazuma priced at Rs 150000. Click Here to find all Dealers in India Suzuki Dealers in India
Suzuki Motorcycle India Private Limited is the Indian arm of the Japanese multinational corporation, Suzuki Motor Corporation that is headquartered in Minami-ku, Hamamatsu, Japan. Besides rolling out batches of scintillating bikes and amazing automobiles, this Japanese company is also involved in the production of outboard marine engines, wheelchairs, all-terrain vehicles (ATVs) and small internal combustion engines. Today standing at the 9th position in the line-up of the largest automobile manufacturers of the world, Suzuki began its journey as something completely different - Suzuki Looms Work. Started by Mr Michio Suzuki in 1909, this company manufactured weaving looms for the better part of the time till 1951, indulging in the production of prototype cars for about a couple of years before the World War II broke out. But, after the cotton market crashed in 1951, Suzuki abandoned its looms and went back to the motor vehicles coming up with the first known form of a Suzuki motorcycle – a motorized bicycle by the name of 'Power Free' in 1952. After building two-stroke engines for more than two decades, Suzuki moved on to manufacture four-stroke bike engines in 1976, the first ones being GS400 and GS750. Today, Suzuki bikes have established their footprints in every part of the globe, and India is no exception. The Indian markets, these days, are glittering with the dazzling fleet of new Suzuki bikes that includes the likes of Hayabusa, GSX, GSX-R1000, GS150R, Intruder, Bandit, Slingshot and Hayate. Besides these, there is a whole lot of shining new Suzuki bikes that are waiting for their launch in India which includes Suzuki B-king, Gladius, GW250, Inazuma 250, Skydrive and V-Strom. Apart from bikes, Suzuki India also has a couple of scooters in its portfolio that are quite popular amongst the Indian crowds – Access and Swish. Suzuki bikes in India have always been revered for their stunning looks, futuristic style, unbeatable technology, extraordinary performance, easy handling and immense reliability. That's the reason why Suzuki bikes have won so many awards over the past few years like the Motorcycle of the Year Award 2010 for Suzuki GS150R and Most Awarded Bike of the Year Award 2011 for Suzuki Slingshot.

Sunday, 17 November 2013

Best Practices for Developing SharePoint Custom Web Parts

Overview of Custom Web Part:

A Web Part, also called a Web Widget, is an ASP.NET server control which is added to a Web Part Zone on Web Part Pages by users at run time. The controls enable end users to modify the content, appearance, and behavior of Web pages directly from a browser. It can be put into certain places in a web page by end users, after development by a programmer.Web Parts can be used as an add-on ASP.NET technology to Windows SharePoint Services.Web Parts are equivalent to Portlets, but don't necessarily require a web portal such as SharePoint to host them.

Web Parts are reusable components that display content on web pages in SharePoint 2013. Web Parts are a fundamental component in building SharePoint pages. A number of Web Parts ship right out of the box with the different editions of SharePoint, and you can also purchase third-party Web Parts.
Note: The Web Parts that you have available depend on which SharePoint 2013 edition you use as well as which features are activated. For example, the PerformancePoint Web Parts are available only with the Enterprise license and only when the PerformancePoint Services feature is activated.
Below Fig show Categories of webparts available in sharepoint 2013. You can add your own categories.


The following is a list of the common Web Part categories:
  • Apps: Each app instance you have added to your site has an associated Web Part. The app Web Parts enable you to add a view into the data in your app to your web pages.
  • Blog: Provides Web Parts for a blog site.
  • Business Data: A group of Web Parts that display business information, such as status, indicators, and other business data. This group also includes Web Parts for embedding Excel and Visio documents and displaying data from Business Connectivity Services (BCS; a component of SharePoint that allows you to connect to data stored outside SharePoint).
  • Community: A group of Web Parts for the community features of SharePoint, such as membership, joining a community, and information about the community. In addition, there are tools for community administrators.
  • Content Rollup: Contains Web Parts that are used to roll up (aggregate) content, such as rolling up search results, providing project summaries, displaying timelines, and showing relevant documents from throughout the site.
  • Document Sets: Web Parts specifically designed for working with sets of documents.
  • Filters: Web Parts that can be used to filter information. These Web Parts are designed to be connected with other Web Parts in order to provide a useful filtering mechanism. For example, you might have a list of content and want users to be able to filter based on certain criteria. You could use these Web Parts to provide the filter mechanism.
  • Forms: Web Parts that allow you to embed HTML or InfoPath forms in a page.
  • Media and Content: Web Parts that display media, such as images, videos, and pages. In addition, there is also a Web Part for displaying Silverlight applications.
  • PerformancePoint: Web Parts specifically designed for PerformancePoint services.
  • Project Web App: Web Parts specifically designed for Project Server. These Web Parts include functionality for displaying information about a project, such as issues, tasks, timesheets, and status.
  • Search: Provides Web Parts for search functionality, such as the search box for entering a query, search results, and refinement of results.
  • Search-Driven Content: Provides Web Parts that display content based on search. For example, Web Parts that show items matching a certain tag, pages based on a search query, and recently changed items.
  • Social Collaboration: Web Parts designed for the social components of SharePoint, such as user contact details, shared note board, tag clouds, and user tasks.
INFO :Web Part behaves like control which runs or works only when hosted on webpage
In SharePoint, web parts usually coexist with other web parts on a web part page. So,It's developers responsibility to ensure that you design your web part so that it will:
  • Provide an intuitive user interface even when failing
  • Work with other web parts running in the same environment
  • Be upgradable
  • Be safe and secure
  • Provide optimal performance

Best Practices for Developing SharePoint Custom Web Parts 

It should go without saying that you should not stop implementing normal programming practices when programming web parts either using c# or vb.net. To this end you should still…
Handle All Exceptions.
It is quite likely that any exception generated by your web part will cause the entire web part page to stop responding and display your error. You should avoid such problems at all costs by wrapping all code likely to generate an exception in a Try/Catch/Finally block
SharePoint will direct any unhandled exceptions to a generic error page and render a message. To control the error message displayed, you need to implement the WebPartPageUserException class.
Validate All User Input.
Any information submitted via a web application is subject to both accidental misuse and deliberate attack. Therefore, you must validate all information submitted by the user, making sure it's in an appropriate form and contains acceptable values.
HTML- Encode All User Input
To help prevent a malicious user from attacking your application using cross-site scripting or other script-based attacks you should always encode input to safe HTML. This changes all extended and special characters into escape characters. To do this in SharePoint, use the SPEncode class's HTMLEncode method (you will need to import the Microsoft.SharePoint.Utilities namespace to use this class).
Linked Resources
In addition, if your web parts use external resources such as images, CSS files, or scripts, you will need to reference these from within your code. If you want to maintain the upgradability of your web part, use linked resources to ensure that the external files are not bound to your assembly. This will also help with performance if you share these scripts with multiple web parts, because they will be cached at browser level.
User Interface
If your web part performs actions within the SharePoint framework that require permissions, then you should check these permissions before rendering your interface. Although there's no real security hazard here—WSS 3.0 will not allow a user to perform an action unless they have appropriate permissions—by checking permissions before rendering, you can improve the look and feel of your web part by hiding or graying out options that are unavailable when a user does not have sufficient permissions.
Exported Web Parts
An instance of your web part on a page could potentially be exported by a user into a .dwp file. By default, this file will contain all the properties set on the web part. That's a security hazard, because if your web part contains properties that are sensitive or confidential in nature, you may not want those to be exported by a user. Examples might include personal information such as telephone numbers, postal codes, dates of birth, etc. To prevent a web part from exporting sensitive information, you need to perform two actions:
Set a WebPartStorage attribute on the property within your web part, and set ControlledExport to true:
// C#
[WebPartStorage (Storage.Personal, ControlledExport=true)]
‘VB.NET
<WebPartStorage(Storage.Personal, ControlledExport:=true)>
The WebPart class has a property called ExportControlledProperties, which is set to false by default. However, a user can set this to true to override the ControlledExport value set above. Therefore, you must ensure that users with appropriate access to alter web part properties are also those users with authority to see this controlled data.
Web Part Zone Properties
Each web part zone on a given page has AllowPersonalization and AllowCustomization properties that control whether a user should be allowed to save changes to any web parts in that zone. The properties dictate whether a user can save changes in shared view or personal view, respectively.
Another property, named LockLayout, controls whether users can save changes to the following web part properties:
AllowRemove
AllowZoneChange
Height
IsIncluded
IsVisible
PartOrder
Width
ZoneID
If your web part allows users to change any of these base class properties, you should always check the parent web part zone for theLockLayout property before saving the changes.
You can access the parent WebPartZone using the following code:
// C#
WebPartZone myZone = (this.Page.FindControl (this.ZoneID));
' VB.NET
Dim myZone as WebPartZone = Me.Page.FindControl (Me.Zone-id)

Final and Very Important Points
Although they don't fall neatly into a category, there are a couple of other topics that you should keep in mind when developing web parts.
Make Properties User Friendly
Your web part users will typically modify properties exposed by your web part from the tool pane. Therefore, you should set the following attributes on your properties when appropriate, so that they have friendly values when rendered in the tool pane.
WebDisplayName: The name for this property as shown in the tool pane.
WebDescription: The tooltip to display when the user hovers the mouse over this property in the tool pane.
Category: A category in which to display this particular property. If you don't specify a category, the tool pane displays it in the default "Miscellaneous" category.

Don’t

1. Use Inline Styles

Inline styles are styles applied directly to HTML content and look like the example below:

<div style="width:100px;color:green"></div>
Inline styles are the most specific and the highest priority of all other styles so it’s tempting to use them instead of fighting with the cascading style sheets of SharePoint. You don’t want to manage styling this way because inline styling mixes content and presentation (look and feel) together. This is a bad practice because styles aren’t managed in a central place, pages can become inconsistent and they are pesky little buggers to find and correct.
2. Apply a Fixed Width to a Collaboration Site
A fixed width layout has a set width around the main content area and doesn’t expand to fill the browser window. When you fix the width of a site meant for collaboration and document management, you have to potential of eliminating extra space for users to add content and collaborate.If you must fix the width on a collaboration site, fix the width of the content area using a percentage rather than a set pixel value. This ensures the maximum amount of space and focuses on function rather than form.
3. Use Too Many Master Pages
Multiple master page design for every design variation even if it something small such as a different logo or a background color. Over the course of a year, the differences between the master pages became significant. Consolidating these master pages was part of the upgrade path and it cost the client a fortune. Be wary as those master page numbers start climbing.

If you are using over four master pages to manage branding for any given site or site collection, you are probably doing it wrong. If you forced me at gunpoint to come up with an ideal number of master pages, I would say 1 master page per parent design and then I would probably wet my pants (because I’m at gunpoint).

If you are using multiple master pages that share the same parent design, try to consolidate them. First define how they are different. Determine if those variations can be managed using page layouts, custom controls, alternate CSS, or scripts. You can generally manage styling differences in a design such as colors, logos, and icons using CSS and page layouts. Variations in master content such as header and footer links can be managed with SharePoint lists and custom web parts or controls.

Conclusion: As you know that web part needs host so be careful while writing your own web-parts because they can ruin entire page functionality.So, better fallows best practices or checklist recommended by Microsoft