Software Development methodologies refer to frameworks used to control the process of developing software applications. There are a wide variety of frameworks available, each with its own strengths and weaknesses. Some methodologies are more suitable for certain types of projects while other methodologies are suitable for other project types, based on technical, organizational and project/team considerations.

Each sofware development methodologey has its own approach to software development. There is a set of more general appraoches, which were developed into several specific methodologies. These approaches are:

• Waterfall: linear frameowrk type
• Prototyping: interative framework type
• Incremental: combination of linear and iterative framework types
• Spiral: combination of linear and iterative framework types
• Rapid Application Development (RAD): iterative framework type
• Extreme Programming

Brite Global uses 3 different types of methodologies for its different projects:

• Sure Step Methodology for Microsoft Dynamics CRM Implementations
• Microsoft Solutions Framework for Agile Software Development Projects
• Scrum Framework for Software Development Projects

The Microsoft Dynamics Sure Step Methodology is designed to enable consulting firms to better serve their customers by helping reduce their Microsoft Dynamics total cost of ownership. This Methodology can be used for projects encompassing large, medium, and small end-to-end engagements.
The methodology provides different project types to suit the implementation engagement, as well as optional offerings to assist during Diagnostic and Optimization. Flowchart diagrams within the Sure Step Methodology point you to tools and templates that can be used at different phases, while the content provides detailed guidance on roles required to perform activities and proven best practices.
The content tools, templates and best practices of the methodology can help increase the consistency, timeframes, quality and success of the implementations.

The Sure Step Methodology has six phases: Diagnostic, Analysis, Design, Development, Deployment and Operation.
Diagnostic is a pre-implementation phase that helps the customer with their due-diligence process for the selection of the right solution to meet their needs.
The Analysis, Design, Development, Deployment and Operation phases represent the five phases of an implementation project, with the Operation phase also encompassing post-implementation activities, in that it extends the project lifecycle beyond the implementation and into the Support stage.

The Sure Step Methodology offers the following project types:

• The Standard project type is a lean approach for implementing Microsoft Dynamics solutions at a single site.
• The Rapid project type depicts an accelerated approach for implementing Microsoft Dynamics solutions with minimal or no customizations
• The Enterprise project type represents a standarized approach for implementing Microsoft Dynamics solutions in complex single-site deployments or in a global/multi-site organization wherein country/site specific unique business needs have to be factored on top of a core solution
• The Agile project type represents a flexible and collaborative approach to implementing Microsoft Dynamics Solutions at a single site requiring specific features and moderate-to-complex customizations. While the Standard, Rapid, Enterprise and Upgrade project types are waterfall-based, the Agile project type uses the Sprint cycle approach to solution deployment
• The Upgrade project type describes the approach for bringing an existing Microsoft Dynamics solution to a subsequent release of that solution. This approach starts with a Technical Upgrade to address moving existing functionality to the subsequent release. Any new functionality desired is then deployed using the above project types, Rapid, Standard, Agile or Enterprise

The Microsoft Solutions Framework is a set of principles, models, disciplines, concepts, guidelines and practices for delivering software solutions from Microsoft. MSF is not only limited to software solutions, but is also applicable to other IT projects like deployment, networking or infrastructure projects. MSF does not force the developer to use a specific methodology (such as Waterfall or Agile) but lets the developers decide what methodology to use.

MSF Consisits of two models, the Team Model and Governance Model.
The team model describes the role of various team members in a software development project. The members of the team would be: Product Management, Program Management, Architecture, Development, Test, Release/Operations and User Experience. Depending on the size and requirements of the project, one person can be assigned to perform multiple roles, but some roles should not be combined.

The Governance model describes the different stages in processing a project.
The stages of the governance model include: Envision, Plan, Build, Stabilize and Deploy.

The MSF for Agile Software Development is intended to be a light weight, iterative and adaptable process.
It uses the principles of the agile development approach formulated by the Agile Alliance. The MSF for Agile Software Development provides a process guidance which focuses on people and changes. It includes learning opportunities by using iterations and evaluations in each iteration.
The high level ideas the build of the MSF for Afile Software Development include:

• Principles
• Mindsets
• Workstreams
• Activities by Workstream
• Artifacts (Work Products)
• Disciplines
• Team Model, Roles, Priciples and Responsibilities
• Cycles and Iterations

Scrum is a lightweight management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Over the last couple of years in particular, Scrum has garnered increasing popularity in the software community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

The following three pillars uphold every implementation:

• Transparency: Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but also what is being seen must be known.
• Inspection: The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection.
• Adaptation: If the inspector determines from the inspection that one or more aspects of the process are outside acceptable limits, and that the resulting product will be unacceptable, the inspector must adjust the process or the material being processed. The adjustment must be made as quickly as possible to minimize further deviation.

The Scrum framework consists of a set of Scrum Teams and their associated roles; Time-Boxes, Artifacts, and Rules.
Scrum Teams are designed to optimize flexibility and productivity; to this end, they are self-organizing, they are cross-functional, and they work in iterations. Each Scrum Team has three roles: 1) the ScrumMaster, who is responsible for ensuring the process is understood and followed; 2) the Product Owner, who is responsible for maximizing the value of the work that the Scrum Team does; and 3) the Team, which does the work. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.

Scrum employs time boxes to create regularity. Elements of Scrum that are time-boxed include the Release Planning Meeting, the Sprint Planning Meeting, the Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective. The heart of Scrum is a Sprint, which is an iteration of one month or less that is of consistent length throughout a development effort. All Sprints use the same Scrum framework, and all Sprints deliver an increment of the final product that is potentially releasable. One Sprint starts immediately after the other.

Scrum employs four principal artifacts. The Product Backlog is a prioritized list of everything that might be needed in the product. The Sprint Backlog is a list of tasks to turn the Product Backlog for one Sprint into an increment of potentially shippable product. A burndown is a measure of remaining backlog over time. A Release Burndown measures remaining Product Backlog across the time of a release plan. A Sprint Burndown measures remaining Sprint Backlog items across the time of a Sprint. Rules bind together Scrum’s time-boxes, roles, and artifacts. Its rules are described throughout the body of this document. For example, it is a Scrum rule that only Team members - the people committed to turning the Product Backlog into an increment – can talk during a Daily Scrum.