Iterative Design and Development

Iterative design and development is the idea that design should be done in repeated cycles where, in each cycle, the design is elaborated, refined, and tested, and the results of testing at each cycle feed into the design focus of the next cycle.  Business Intelligence projects tend to be done in short timeframes as the needs of business changes often.  It is best to carve up your larger project into smaller phases that each phase can be used to build upon to complete the total scope of the much larger project.  In doing this, will result in higher customer satisfaction, low risk and a much more dynamic business intelligence solution for you company.

Conceptual Design

The goal of the conceptual design section is to understand the business and user requirements. The design described in this section of the design specification is very high-level and does not include the technologies that are used to build the solution.  The process of conceptual design involves a set of steps for translating requirements into a user interface design. The process begins by getting at the core of an application–the central concept–and proceeds by organizing the functionality from the users’ point of view. Along the way, a deeper understanding of users and their requirements is developed. The result is an outline or model of the user interface that may be further developed during the detailed user interface design phase.

Logical Design

The logical design section takes input from the conceptual design and current technology infrastructure. Logical design organizes the details of the solution environment that your project team builds to fulfill business needs and user requirements. The architect on your team defines the structure of the solution and the communication paths among elements. For example, the architect takes the scenarios from the conceptual design and implements the scenarios using objects and services, user interface prototypes, and logical database design. An important objective in this phase is to define and document the link between the business requirements and the physical features that are included in the solution environment. Without this link, it will be impossible to implement feature trade-offs, if it becomes necessary.

Physical Design

Physical design defines the architecture at a greater level of detail. In this section, you define the hardware configurations and the software products involved in building the solution environment. The physical design takes also the high-level logical design down to specifics, outlining exact architecture configuration and placement for each instance and for each component. It is important to understand that the complete physical design will not be included in the design specification. Many portions of the physical design, such as detailed configuration documents and installation procedures, will be completed during the build phase of the project.

Business Scorecard Manager Training Kit

Introduction

Builder Fundamentals

Builder Advanced

Report Views

Scorecard Views

Deploying Scorecards to SharePoint SQL Reporting Services

Server & Security

Extensibility


 

Prototyping Scorecards

The scorecards views can actually be created even before all of the data issues and mappings have been determined as part of the project. When you create your KPI Actuals and Targets, you have an option of using a FIXED VALUE as your data source.  Using this, you will be able to enter your own values and easily prototype the scorecard views and validate that the scorecard look and roll up as you expect them to and refine the as needed.

See the following section “Scorecard Design and Interaction” for more specific information on layout and design of scorecards.

Test and Validate

Developing a good test plan is key to successful testing. In fact, it can help define the application. To create an effective test plan, you must first understand your customer’s strategic vision for the environment, and then define your test strategy accordingly.

A test plan includes the strategy and scheduling information for the entire project—everything except descriptions of the test cases. The test plan lists the features that need testing, the required resources, the risks you need to consider, and the testing schedule. The results of your test-planning process should be a stable specification, an accurate schedule, and a test plan containing an effective test strategy.

The test plan should reiterate the goals of the environment and divide the environment into testing areas. In addition, the plan should include inter-group procedure information, such as how bugs will be tracked and resolved, how test releases will be handled, how shared components will be tested, and criteria for determining whether a build is accepted or rejected for testing. Finally, the test plan must identify which testing tasks will be automated and which testing tasks will be done manually.   Test plans should describe in detail everything that the test team, the program management team, and the development team need to know about the testing to be done.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s