.net developer thoughts ...

The Magic of Traceability Matrix

joycsc — Wed, 28 Jun 2006 12:37:00 GMT

While working with outsourcing clients, a common problem appears, is the functional specification. Clients generally don't want to spend much time creating specs, try to write ASAP, which results an unfinished spec. While developing developers suffers a lot. First, it often gets confusing, the developer can't understand exactly what the spec is saying. Second, during the development (and also after seeing some demo), client discovers new features, which results much re-engineering on the code, as this is too late for adding new requirements. 'Traceability Matrix' might really a good solution in this case. What is 'Traceability Matrix'? In short, this is the simple list of features, something like the product feature list in the web sites (well off course TM has some more features). This is easy for clients as it requires less time for them to mention. Since clients are too busy to have time on spec, we can start work on specs, as we get the list of features. A smart system analyst can forward and elaborate the requirements in useful way using 'Traceability Matrix'. • This is the simplest requirement document. So keep it as simple as possible. • Include features in bullets, if necessary group the bullets, according to modular requirements. • Common Functions: Consider special terms, to specify commonly used requirements among several cases. For instance, such special term can be “CRUD”, which says Create, Read, Update and Delete operation in any entity. While writing requirement documents, you can use this commonly used features in multiple cases. Like: User CRUD, Product CRUD, Books CRUD etc. • Common Scenarios: You can also consider special terms for commonly used application scenario. For instance, a special term can be “Create Secured Record”, which tells, 1. Click “Add item” button, 2. The user will be redirected to “Add item” page, 3. User inserts data, 4. User submits data, 5. User provides “security text/code”. 6. User gets back to the caller page.

“Instance Saver” Custom Entity Model- Basic Architecture

joycsc — Wed, 28 Jun 2006 12:33:00 GMT

Business Entity: For each custom business entity, there is a collection class. However, if our tech platform is .net 2.0, we can use the generic list class for collections. Business Layer: 1. Contains a “Save” instance method in business layer for insert and update operations. 2. For delete and get operations, it uses static methods in the business layer. Data Access Layer: Data access layer contains all CRUD operations in one class.

Custom Entity – Many 2 Many Table Issue

joycsc — Wed, 28 Jun 2006 12:30:00 GMT

When we define a custom business entity as an architecture for a given project, one common issue arises that, how we will consider “Many to Many” relationships? As there is only one entity for each database table, “Many to Many” tables might not be a...(read more)

Custom Entity – Data Operation on Multiple Tables

joycsc — Wed, 28 Jun 2006 12:25:00 GMT

1. In a case, where we are considering m2m, and it’s required to add a new entity record in the m2m table, an obvious case comes, where we create and save the entity first and then we add that entity in the m2m table. For example, when we add a new book...(read more)