Showing posts with label SDLC. Show all posts
Showing posts with label SDLC. Show all posts

Thursday, May 27, 2010

CSS3 and html5

tools & resources for web professionals

the best site for understanding and creating online code of css3.

http://westciv.com/tools/gradients/

http://westciv.com/

what you can do by using cc3. http://www.everydayworks.com/css_typography/HTMLCSSrotation.html

i like it. alot. :D

http://creatingsexystylesheets.com/

Tuesday, April 22, 2008

Association Matrix Checklist




































































CHECKLIST FOR AN ASSOCIATION MATRIX


Project Name: Project Code:
Document Name: Document Number:
Reviewed By: Reviewed Date:

Checklist Items



Yes



No



Comments


There are no missing rows or columns (the matrix is complete).
The rows and columns are sorted for best presentation.
All rows have an association with at least one column.
All columns have an association with at least one row.
For CRUD matrices, all entities that are being managed by the application have a "create".
For CRUD matrices, all entities that are managed by other applications (i.e., interfaces) show as "read" only.





i have to face problems, and solve them.

Saturday, April 19, 2008

Using CRUD Diagrams to Group Processes into Systems

Using CRUD Diagrams to Group Processes into Systems

Grouping or clustering processes allows the analyst to identify what business processes fit naturally together. The groupings help determine what functions a specific system should perform and what data it requires.



The objective is for groups to have a high degree of independence from one another.



Converting to Association Matrix may Simplify Grouping



Grouping processes does not distinguish between create, read, update, or delete. Therefore, it may be simpler to convert the CRUD Diagram to an Association Matrix by changing each intersection with a C, R, U, and/or D into a common symbol such as a check mark or an asterisk.



Example: CRUD Diagram Converted to Association Matrix









































































































Entity

Process
Customer Customer Order Customer Account Customer Invoice Vendor Invoice Product
Receive Customer Order

*



*



*


Process Customer Order

*



*



*


Fill Customer Order

*



*



*


Maintain Customer Account

*



*



*


Terminate Customer Account

*



*



*


Pay Vendor Invoices

*


Validate Vendor Invoices

*


Pay Vendor Invoices

*


Invoice Customer

*



*



*


Maintain Inventory

*





Initial Grouping


Begin by identifying the first two processes that use the same data entities. Rearrange the rows to position these two processes at the top of the matrix.



Identify other processes that use the same data entities and, if any, move them into the next rows in the matrix.



Example: Initial Grouping of Processes


















































































































Entity

Process

Customer



Customer Order



Customer Account



Customer Invoice



Vendor Invoice



Product


Maintain Customer Account

*



*


Terminate Customer Account

*



*


Receive Customer Order

*



*



*


Process Customer Order

*



*



*


Fill Customer Order

*



*



*


Ship Customer Order

*



*


Validate Vendor Invoices

*


Pay Vendor Invoices

*


Invoice Customer

*



*



*


Maintain Inventory

*





Continue Grouping Process


Continue to identify other sets of processes that share the same data entities and move them into the next rows.



Example: Next Grouping of Processes




































































































































Entity

Process

Customer



Customer Order



Customer Account



Customer Invoice



Vendor Invoice



Product


Maintain Customer Account

*



*


Terminate Customer Account

*



*


Process Customer Order

*



*



*


Fill Customer Order

*



*



*


Validate Vendor Invoices

*


Pay Vendor Invoices

*


Receive Customer Order

*



*



*


Ship Customer Order

*



*


Invoice Customer

*



*



*


Maintain Inventory

*





Manual Grouping


Once all processes that use the same entities have been identified, begin to analyze remaining entities to determine their best fit. This analysis is subjective. In the example you may decide that Receive Customer Order and Invoice Customer should be grouped with Process Customer Order and Fill Customer Order because they are all involved in processing the customer's order.



Example: Manual Grouping of Processes




































































































































Entity

Process
Customer

Customer Order



Customer Account



Customer Invoice



Vendor Invoice



Product


Maintain Customer Account

*



*


Terminate Customer Account

*



*


Receive Customer Order

*



*



*


Process Customer Order

*



*



*


Fill Customer Order

*



*



*


Invoice Customer

*



*



*


Ship Customer Order

*



*


Validate Vendor Invoices

*


Pay Vendor Invoices

*


Maintain Inventory

*





Consider Using Subject Databases


Entities may be grouped into subject databases using a method such as Affinity Analysis. The subject databases are then used on the matrix instead of data entities. Grouping processes will be easier when there are fewer objects to analyze. For example, Customer, Customer Order, and Customer Account may be grouped as Customer while Customer Invoice and Vendor Invoice may be grouped as Invoicing.



Example: Grouping Processes using Subject Databases

























































































Subject

Process
CustomerInvoicingProduct
Maintain Customer Account

*


Terminate Customer Account

*


Receive Customer Order

*


Process Customer Order

*



*


Fill Customer Order

*



*


Invoice Customer

*



*


Ship Customer Order

*



*


Validate Vendor Invoices

*


Pay Vendor Invoices

*


Maintain Inventory

*





Craig Borysowich (Chief Technology Tactician)

Do I Even Need a Prototype??? & Prototyping Overview

Prototypes can add unnecessary overhead if they are not needed or are not workable for a particular project situation. Analyze the circumstances of the project to determine if a prototype will add value. When making the decision, consider the benefits of prototyping.



THE BENEFITS OF PROTOTYPING



Types of Benefits



Prototyping primarily assists with communication between the end-user and the development staff. The enhanced communication results in greater accuracy and fewer errors in later parts of the project, when they become more expensive to fix. The early involvement also empowers the end-user and facilitates system acceptance and understanding.



Communicate Requirements to Customer



Prototyping is an effective means of communicating the analyst's understanding of system requirements to the customer. The customer achieves a better understanding of the proposed system than could be obtained from written documentation alone. Therefore, problems that may have gone undetected until a later stage are identified earlier.



Prototyping should be used for all interactive systems. Consider that a serious review by end-users will almost always result in a change.



Communicate Requirements to Programmer



Prototyping is an effective means of communicating the system requirements and design to programmers. It is easier for the programmers to build a system from a working model than from a design document.



Customers See the Design at an Earlier Stage



Some design activities, such as Human Interface Design, occur at an earlier stage in the life cycle when a prototype is developed. Customers are able to try out the design and provide their input before much time and money are expended.



If Horizontal Prototyping is used during analysis, a first cut of the system externals is defined at that time. If a Vertical Prototype is developed, a first cut of the database must be designed during analysis.



Prototyping can greatly reduce the scope and size of design activities. Design activities still occur but they are moved to other stages of the system life cycle. Depending on the extent of the prototype, design efforts can be reduced to include only such tasks as test plan preparation, user aids design, conversion design, and database optimization.



Greater Customer Involvement



Customers become more involved in the system development process when a prototype is used. This helps ensure that customer requirements are met.



Reduce Written Documentation



Prototyping makes a system more intuitive and reduces the amount of written documentation required.




Situation Where Prototypes are Most Valuable



Some situations where prototyping is particularly valuable include:



· scope of the project permits customer involvement to improve the system,



· customers are unsure of their exact requirements or are having difficulty expressing requirements,



· the new system is altering a basic business operation,



· customers are not fully aware of all the impacts of the new system,



· the advantages and disadvantages of alternative solutions need to be explored.



Situations For Limited Prototyping



In general, prototyping is more valuable for on-line systems than for batch processing. However, most batch systems produce reports which can be prototyped using a report generator. Prototyping is of limited value in some systems that are logic intensive. In these cases, horizontal prototypes can still be used to evaluate the human interface.




Craig Borysowich (Chief Technology Tactician)






-------------------------------------------------------------------------------------



Use Prototyping to:



· develop a working model of key functional components of a system, which may or may not be developed into the final system,



· enhance communication of requirements between the analyst, customer, and development team members,



· demonstrate features of the proposed system to such a level that the customer can relate it to his or her requirements,



· allow customers and analysts to explore alternative architectures and specific customer task scenarios,



· uncover design flaws early in the project life cycle,



· train customers who will eventually use the system,



· validate customer requirements (are we building the right product?),



· verify customer requirements (are we building the product right?).



Method



To build a prototype, complete the following steps:



Evaluate the Need for Prototyping



Define the Type of Prototype



Develop the Prototype



Refine the Prototype



Tips and Hints



Fourth Generation tools make it possible to quickly and easily prototype a model of system externals. However, if the prototype cannot be built and changed easily, many of the advantages of prototyping are lost. Some tools require considerable effort to set up the database or make database changes, particularly in the hands of inexperienced programmers.



See Also



Interviewing (for defining requirements related to the external design of a system)



Participant Observation (for defining requirements related to the external design of a system)


Timeboxing








Craig Borysowich (Chief Technology Tactician)