Tuesday, August 28, 2007

MSDN Library - HTML and CSS Reference

URL: http://msdn2.microsoft.com/en-us/library/aa155093.aspx

Here you can find the tutorials & reference for the web development HTML and CSS section.

* HTML and DHTML Overviews and Tutorial

* HTML and DHTML Reference [I guess I'll visit this site more often, here is where I found what javascript methods to use.]

* Cascading Style Sheets (CSS)

* DHTML Behaviors

* DHTML Data Binding

* Scriptable Editing

* Web Multimedia

* HTML Applications (HTA)

* Accessibility

* Technical Articles and Columns

Tuesday, August 21, 2007

Filter Access Records

I just found out this filter option in Access database recently, it helped me a lot in doing my work, especially when I want to select a range of records.

This is my table records:

To filter the records, go to Records menu --> Filter --> Filter By Form.

Then key in what you want to search for, or select from the dropdownlist for the particular column(s), then right-click on the column header and select 'Apply Filter/Sort'.

The records will be shown:

If you want to perform advanced filter function, you may click on Records menu --> Filter --> Advanced Filter/Sort. The Filter window below will appear. Just define the filter criteria as below, and apply the filter/sort.

The records will be filtered:

This is a simple but useful feature in Microsoft Access. ^_^

Thursday, August 2, 2007

Requirements Gathering Techniques

Interviews

Cons: Predisposition, experience, understanding and bias of the person being interviewed influence the information obtained.

Solution: Use context-free questions to avoid prejudicing the response.

Note: Context-free question is question that does not suggest a particular response.

e.g. Who is the client for this system? What is the real reason for wanting to solve this problem? what environment is this product likely to encounter? What kind of product precision is required?

Document Analysis

All effective requirements elicitation involves some level of document analysis, such as business plans, market studies, contracts, requests for proposals, statements of work, existing guidelines, analyses of existing system, and procedures.

Improved requirements coverage results from identifying and consulting all likely sources of requirements.

Brainstorming

Brainstorming involves both idea generation and idea reduction.

Idea Generation: identify as many ideas as possible.

Idea Reduction: ranks the ideas into those considered most useful by the group.

Pros: it may come out the most creative or effective by combining seemingly unrelated ideas, it encourages original thinking and unusual ideas.

Requirements Workshops

Requirements Workshops are best facilitated by an outside expert and are typically short.

Benefits:

- workshop costs are often lower than are those for multiple interviews.

- they help to give structure to the requirements capture and analysis process.

- they are dynamic, interactive, and cooperative.

- they involve users and cut across organizational boundaries.

- they help to identify and prioritize needs and resolve contentious issues.

- when properly run, they help to manage user's expectations and attitude toward change.

A special category of requirements workshop: Joint Application Development (JAD) workshop.

JAD:

- a method for developing requirements through which customers, user representatives, and developers work together with a facilitator to produce a requirements specification that both sides support.

- an effective way to define user needs early.

Prototyping

- a technique for building a quick and rough version of a desired system or parts of that system.

- illustrates the capabilities of the system to users and designers.

- serves as a communications mechanism to allow reviewers to understand interactions with the system.

 Use Cases

- A use case is a picture of actions a system performs, depicting the actors.

- It should be accompanied by a textual description and not be used in isolation of other requirements gathering techniques.

- Use cases and scenarios (descriptions of sequences of events) facilitate team communication. They provide a context for the requirements by expressing sequences of events and a common language for end users and the technical team.

Storyboards

- a storyboard is a set of drawings depicting a set of user activities that occur in an existing or envisioned system or capability.

- storyboards are a kind of paper prototyping.

- Customers, users or developers start by drawing pictures of the screens, dialogs, toolbars, and other elements they believe the software should provide.

- The group continues to evolve these until real requirements and details are worked out and agreed upon.

- Related technique: storytelling - the writing of vignettes to envision new products and services based on perceived user needs and the possibilities offered by emerging technologies.

 

There are some other techniques which I didn't take note here,such as Interfaces Analysis, Modeling, Performance and Capacity Analysis.

Common Requirements Errors

I'm currently working out some templates to be used in our software development process, and I read this interesting study:

The common types of requirements errors:

49%  -- incorrect assumptions

29%  -- omitted requirements

13%  -- inconsistent requirements

 5%   -- ambiguities

 

There are so many errors occurred just because of the incorrect assumptions!! It shows that we really shouldn't make assumptions. Whenever we are going to gather or analyze requirements, I guess it's good for us to remember these points. ^_^ 

Recommended Requirements Gathering Practices

Extracted from: STSC (Software Technology Support Center) CrossTalk

1. Write and iterate a project vision and scope document.

2. Initiate a project glossary that provides definitions of words that are acceptable to and used by customers/users and the developers, and a list of acronyms to facilitate effective communication.

3. Evolve the real requirements via a "joint" customer/user and developer effort. Focus on product benefits (necessary requirements), not features. Address the minimum and highest priority requirements needed to meet real customer and user needs.

4. Document the rationale for each requirement (why it is needed).

5. Provide training for requirements analysts and selected customer/user representatives that explains the following:

- The role of the requirements analyst.

e.g. to evolve real requirements working with customers & users, not to invent requirements independently or to "gold plate".

- How to write good requirements.

- The types of requirements errors and how these can be reduced.

- The value of investing more in the requirements process.

- The project and/or organization's requirements process.

- Overview of the methods and techniques that will be used.

- How to use the project's automated requirements tool.

- The role of validation and verification during requirements definition.

6. Establish a mechanism to control changes to requirements and new requirements.

7. Prioritize the real requirements to determine those that should be met in the first release or product and those that can be addressed subsequently.

8. When the requirements are volatile (and perhaps even when they are not), consider an incremental development approach. This acknowledges that some of the requirements are "unknowable" until customers and users start using system.

9. Use peer reviews and inspections of all requirements work products.

10. Use an industry-strength automated requirements tool.

- Assign attributes to each requirement.

- Provide traceability.

- Maintain the history of each requirement.

11. Use requirements gathering techniques that are known, familiar, and proven in the organization such as requirements workshops, prototyping, and storyboards.

12. Provide members of the project team (including requirements analysts) who are domain/subject matter experts.

13. Evolve a project and organizational approach based on successful use of policy, process, methods, techniques and tools. Provide a mechanism such as working groups to share information and "best practices" among projects.

14. Establish a continuous improvement ethic, teamwork approach, and a quality culture.

15. Involve customers and users throughout the development effort.

16. Perform requirements validation and verification activities in the requirements gathering process to ensure that each requirement is testable.

Create Table using stored procedure

My sis was asking me how to create a table using stored procedure, well, I think it's better just jot down some notes here, for my future reference too.

 

Here is an example:

CREATE PROCEDURE CreateTestTable
AS
    
CREATE TABLE [TestTable]
(
    [Id] int NOT NULL Primary key identity(1,1),
    [Description] varchar(7000),
    [TestDate] datetime, 
    [Cost] money,
    [TestRole] char(4),
    [IsAdmin] bit
)
 
RETURN

* using brackets [] to embrace the table name or field name so that even reserved words have been used, the names are still allowed.


* the field name [Id] has been defined to be primary key and it's auto increment by 1, start from 1. (Null is not allowed for this column)


* the data type for boolean is "bit" here.


* the difference between using "char" & "varchar" is that, when you define the size for char, no matter how many characters have been stored, it'll use up all the space defined. But for "varchar", it'll allocate just the size enough to store the variables. For variable string, it's good to use "varchar" as the data type.


* The maximum size for varchar is 8000 characters.


* For Chinese characters, it's good to use "nvarchar" as the data type.


 


Well, I didn't really do a proper study on the notes above, these are told by my friends or from my experience. Hope they are not wrong information. Tongue out

Wednesday, August 1, 2007

Create a Business Case

Extracted from allPM.com

 

Successful project management: -

- deliver projects on time, within budget & to specification.

- deliver the business benefits to the customer.

 

Purpose of creating a Business Case for each project:

- To ensure projects consistently deliver the stated business benefits to the customers.

- To justify the initiation of the project and to clearly specify upfront, the business benefits to be delivered.

 

Create Business Case in 4 steps:

1) Identify the Business Problem

2) Identify the Alternative Solutions

3) Recommend a Preferred Solution

4) Describe the Implementation Approach

 

 Step 1: Identify the Business Problem/Opportunity

* investigate that business problem before you attempt to find a solution to it.

1. Determine the root cause of the problem by analyzing the environment within it has arisen.

e.g. The root cause of a problem may be related to:

- changes to the business vision, strategy or objectives

- newly identified competing products or processes

- opportunities resulting from newly introduced technologies

- commercial trends that are driving business changes

- changes to legislative or other environmental factors

2. Once identified, describe the problem by

(a) listing the reasons why it has arisen,

(b) the impact it is having on the business and

(c) the timeframes within which it must be resolved.

 

Step 2: Identify the Alternative Solutions

* To ensure that you select the best solution available, complete the following steps:

(1) Identify the alternative solutions available

(2) Quantify the benefits of implementing each solution

(3) Forecast the costs of implementing each solution

(4) Assess the feasibility of implementing each solution

(5) Identify the risks and issues associated with each solution

 

Step 3: Recommend a Preferred Solution

(1) define a set of criteria upon which each solution will be assessed.

e.g. The criteria may be related to the solution; benefits, costs, feasibility and risk level.

(2) Identify a mechanism for scoring each alternative solution.

(3) Take each alternative solution and assign it a score based on its ability to meet the criteria set.

(4) Summarize the scores across all criteria, to identify the total score for each alternative solution.

The solution with the highest total score should become your preferred solution for implementation.

 

Step 4: Describe the Implementation Approach

* Convince the project sponsor that you have thought through the plan for implementation of that solution. -- describe in detail how the project will be initiated, planned, executed and closed effectively.

(1) Initiation: List the steps involved in initiating the project.

e.g. define Terms of Reference, recruit the team & establish a Project Office.

(2) Planning: Describe the steps you will take to plan the project in detail.

e.g. create a Project Plan, list the plans required to monitor and control project resources, finances, quality, risks, suppliers and communications.

(3) Execution: Outline the approach to be taken to build the physical project deliverables and gain the customer's acceptance for each deliverable produced.

(4) Closure: Identify the activities required to hand over the final solution to the customer, release staff, close the Project Office, and perform a Post Implementation Review of the project.