Conclusion of drafting Solution&Design document
-
During the period of developing new changes request for our application, some of significant experience and mistakes are found which is necessary to make a conclusion in order to enhance team’s work in future. 1.Granularity of items in Solution &Design document.All detail changes in business, logic, UI and DB changes should be described in this document. We are supposed to make any developer get all details from this document. 2.Before talking about CR and drafting this document, it is very important to go through the related exist code of application, which will help to clear the relationship among the business objects and confirm CRs’ feasibility. When we made an investigation for the relationship between business log and Machine and made a mistake that one log contains multi Machines. Actually only one Machine in this log. So when we are coding, we found this problem and then we have to update our Solution &Design document again. Certainly it’s disappointing. 3.As to any one item, its corresponding priority (market/user level) and access permission should be taken into consideration as well. welcome your input for this.
-
During the period of developing new changes request for our application, some of significant experience and mistakes are found which is necessary to make a conclusion in order to enhance team’s work in future. 1.Granularity of items in Solution &Design document.All detail changes in business, logic, UI and DB changes should be described in this document. We are supposed to make any developer get all details from this document. 2.Before talking about CR and drafting this document, it is very important to go through the related exist code of application, which will help to clear the relationship among the business objects and confirm CRs’ feasibility. When we made an investigation for the relationship between business log and Machine and made a mistake that one log contains multi Machines. Actually only one Machine in this log. So when we are coding, we found this problem and then we have to update our Solution &Design document again. Certainly it’s disappointing. 3.As to any one item, its corresponding priority (market/user level) and access permission should be taken into consideration as well. welcome your input for this.
When customers / sales people / product managers etc. request a change, they are not at all interested in code. They look at the functionality only. Such requirements often start with a headline only, it is then the duty of requirements engineering / product management to precisely describe the requested functionality, possibly with user stories. When appropriate, the description will show the differences to the present situation. Now you have a functional specification. Next, development has to scrutinize the requested change, and see how the application has to be designed: which interfaces, classes are needed, how they are distributed between server and client, etc. They have to look at the present code and its re-usability. Now you have a technical specification, and you can estimate the efforts for development. Of course, the "functional" guys may talk with the "technical" guys when they create their functional specification. When you eventually develop the functionality, you'll document differences from the original plan. With "big" projects, you'll start with the main functionality, and while the customers can already use that core functionality, more details will be added as outlined in the steps above.
-
During the period of developing new changes request for our application, some of significant experience and mistakes are found which is necessary to make a conclusion in order to enhance team’s work in future. 1.Granularity of items in Solution &Design document.All detail changes in business, logic, UI and DB changes should be described in this document. We are supposed to make any developer get all details from this document. 2.Before talking about CR and drafting this document, it is very important to go through the related exist code of application, which will help to clear the relationship among the business objects and confirm CRs’ feasibility. When we made an investigation for the relationship between business log and Machine and made a mistake that one log contains multi Machines. Actually only one Machine in this log. So when we are coding, we found this problem and then we have to update our Solution &Design document again. Certainly it’s disappointing. 3.As to any one item, its corresponding priority (market/user level) and access permission should be taken into consideration as well. welcome your input for this.
aoe.Dylan wrote:
Certainly it’s disappointing.
Not sure what the question is. But I believe you are suggesting that you had a Change Request (CR) and that while analyzing/implementing this you found a bug. The bug, which significant, had nothing to do with the CR. As such it is nothing more than another CR despite originating from a different CR. You might choose to bundle multiple CRs into a release or not. That decision is based on an independent evaluation of each CR.
-
aoe.Dylan wrote:
Certainly it’s disappointing.
Not sure what the question is. But I believe you are suggesting that you had a Change Request (CR) and that while analyzing/implementing this you found a bug. The bug, which significant, had nothing to do with the CR. As such it is nothing more than another CR despite originating from a different CR. You might choose to bundle multiple CRs into a release or not. That decision is based on an independent evaluation of each CR.
We anylasize the relationship of certain two object and thought it is one-to-many through business logic. We wrote these into our solusion &design document and were waiting for approval from archetect/DBA ext. However these related logic had exist in our application, its implementation logic is according to one-to-one.This kind of implementation can satisfy old logic. So when we develops, we should follow old one-to-one logic. We have to change design in document, but nobody is willing to review and apporve it again(disappointing). Therefore my conclusion is the reason of this mistake is "we didnt go through old code!". Hope you can see my point.
-
We anylasize the relationship of certain two object and thought it is one-to-many through business logic. We wrote these into our solusion &design document and were waiting for approval from archetect/DBA ext. However these related logic had exist in our application, its implementation logic is according to one-to-one.This kind of implementation can satisfy old logic. So when we develops, we should follow old one-to-one logic. We have to change design in document, but nobody is willing to review and apporve it again(disappointing). Therefore my conclusion is the reason of this mistake is "we didnt go through old code!". Hope you can see my point.
If I understand that correctly then the incorrect implementation of the design means that you are not going to be able to implement the new Change Request (CR.) Normally you must build that correction in to the estimate for the CR. It is up to who ever pays if they want the main feature or not. However your company might have a mitigation policy however that allows another CR to be put into place via some 'good service' policy (whether an explicit or implicit policy.) If that exists then you must put that CR into place and expedite it so it doesn't impact the other CR. Even if the primary CR is not accepted the correction can proceed since it impacts the expected functionality, even if not the actual functionality.