Lately, there is a new technical term called Cloud computing. It means that the application is not dedicated only to one or more than one specific servers. Under this approach, it thinks everything is a resources. And from the application point of view, it based on what the user want to request what they need. To be more specific, we may not know how data store and where is the database, just known there is an interface connected with. We could retrieve the data through this interface. Therefore we could reduce the workload of each server and share the bandwidth since each request may cross different servers.
For the Google app engine, it uses the Cloud computing approach which allow small to medium size business to host their applications (include DB also!!) under Google. However, I just worry this may not work due to the following reasons :-
1. Security: May store sensitive data under service provider.
2. Data Mining issue: Since we may not own our DB, it may have difficult to do the data mining. Nowadays business intelligence are very powerful, however, it requests you have a real DB.
3. Connectivity : Will this framework has the sufficient functions to connect different local resources? The business application is not just only a web applications. It may interact with some files stored in some local resources (e.g. XML stored in a folder).
4. Maintenance and support: Backup maybe got headache now.
Due to these reasons, I don't think many commercial web applications will use Google app engine. Most likely, this is just a more powerful Web Hosting environment with better Ajax support and required fewer bandwidth application for Web 1.0 to Web 2.0 applications but not real business applications (Web 3.0?).
Sunday, June 22, 2008
Tuesday, August 21, 2007
Requirement. Freeze. Don't move!!
I believe that many people understand that requirement should be freeze and don't be changed during implementation phrase. However, how many people willing do it or could follow this rule? I think it is a good open question.
As many books mentioned, we should not change the requirement during implementation phrase since the cost for changing will be much higher that change it under requirement capturing or analysis phrase.
For the big changes such as adding a new modules, I think many companies have the proper procedure to handle it. But for the minor changes, people will easily ignore the risk and accept the change. Actually, this is the hidden problem to make the system unstable.
Of course, to modify this minor change won't affect the system and it also could make the system better.. But what happen if we continue to do these minor changes under different times? Many people will continue to accept these changes but the fact is, 10 variances will create over 10 x 10 times variances and make the system difficult to maintain. People are easily skip to re-think these 10 variances at same time since it is not under the ANALYSIS phrase.
One of the key point for project management is to make sure everything are under control, if we create so many variances, how could we manage the project properly?
Therefore, please think carefully before accept the change. We need to improve the PM and system architecture and let them to decide even add a field or disable a button.
As I mentioned in this article, disable one button won't make much impact to the system but if we do many of these changes, the system will suffer finally.
As many books mentioned, we should not change the requirement during implementation phrase since the cost for changing will be much higher that change it under requirement capturing or analysis phrase.
For the big changes such as adding a new modules, I think many companies have the proper procedure to handle it. But for the minor changes, people will easily ignore the risk and accept the change. Actually, this is the hidden problem to make the system unstable.
Of course, to modify this minor change won't affect the system and it also could make the system better.. But what happen if we continue to do these minor changes under different times? Many people will continue to accept these changes but the fact is, 10 variances will create over 10 x 10 times variances and make the system difficult to maintain. People are easily skip to re-think these 10 variances at same time since it is not under the ANALYSIS phrase.
One of the key point for project management is to make sure everything are under control, if we create so many variances, how could we manage the project properly?
Therefore, please think carefully before accept the change. We need to improve the PM and system architecture and let them to decide even add a field or disable a button.
As I mentioned in this article, disable one button won't make much impact to the system but if we do many of these changes, the system will suffer finally.
Thursday, August 16, 2007
Early Binding !?
(Because of my poor English and this document is quite technical, you may have difficulty to fully understand it. If you really don't understand, please leave comment and I will try to explain in more detail)
Nowadays, many development tools (e.g. NET) always claims that they have many feasibility to provide the early binding. Actually, early binding could benefit the system that minimize problem occurred during the runtime since some typo problem (e.g. RecordSet("CustomerID") but typed RecordSet("CutomerIE")) could be captured during the development phase. That's why the trend of all development will try to switch to early binding approach. And that's why something called LINQ and Hibernate modules are built to direct link the DB and create the appropriate entity object with strong typed fields.
However, this approach is still not mature to handle the UI. If the outlook of the UI is dynamic and could be changed during the runtime, we couldn't located that control during the design phase. We only could build some mechanism to detect (e.g. Findcontrol function in .NET) the control. This may increase the risk of the system since we couldn't predict what happen in the runtime (e.g. What happen if the control is expected under that status but couldn't found). We may capture wrong control and doing wrong action during runtime.
Actually, I think this problem could be solved if the framework could help to identify all control's ID during design time, no matter it is visible or invisible during runtime, and store these information in the framework. Therefore, we could locate all the controls while in the development phase to help us to build a better solution.
"FindControl" is a powerful function to handle some tough UI logics. However, it is still better don't over use this function to minimize the risk. I still would suggest try to use some earlier binding solution if possible.
Nowadays, many development tools (e.g. NET) always claims that they have many feasibility to provide the early binding. Actually, early binding could benefit the system that minimize problem occurred during the runtime since some typo problem (e.g. RecordSet("CustomerID") but typed RecordSet("CutomerIE")) could be captured during the development phase. That's why the trend of all development will try to switch to early binding approach. And that's why something called LINQ and Hibernate modules are built to direct link the DB and create the appropriate entity object with strong typed fields.
However, this approach is still not mature to handle the UI. If the outlook of the UI is dynamic and could be changed during the runtime, we couldn't located that control during the design phase. We only could build some mechanism to detect (e.g. Findcontrol function in .NET) the control. This may increase the risk of the system since we couldn't predict what happen in the runtime (e.g. What happen if the control is expected under that status but couldn't found). We may capture wrong control and doing wrong action during runtime.
Actually, I think this problem could be solved if the framework could help to identify all control's ID during design time, no matter it is visible or invisible during runtime, and store these information in the framework. Therefore, we could locate all the controls while in the development phase to help us to build a better solution.
"FindControl" is a powerful function to handle some tough UI logics. However, it is still better don't over use this function to minimize the risk. I still would suggest try to use some earlier binding solution if possible.
Tuesday, August 14, 2007
No prototyping 2 !!!
Just got the feedback from Edward and I would like to clarify something about no prototyping. Actually, what I suggest is to use other tools (use case, data flow, etc..) to let the user to think in a deeper way to gather the better requirement. Prototyping is also a tools but I would suggest to gather the requirements from different aspect before using prototyping. However, this lead to the user need to take more responsibility and more effort during the design phase. But how to persuade the user to take more responsibility? This is related to the environmental factor and your company culture and it is another issues...
Sunday, August 12, 2007
No prototyping !!!
This is my first time to setup the blog and would like to share what my experience for software system development. My experience may not 100% follow the standards but it is just what I thought based on my experience.
Ok. let's start now..
Today, I would like to say about prototyping. From this topic, you may think that how could develop a system without prototyping. Yes, it is quite difficult without prototyping but what I said is try to minimize the dependency to rely on Prototyping. In terms of presentation, prototyping is easy to present the "real" system to user. However, it will limit the user's mindset because everything is setup. What they do is just follow the screen flow, the field shown in the screen. It may hidden some important function such as interaction with other modules, intergration...
When we discuss with user on the prototyping, user just focus on Screen, not real situation..
From my opinion, it is better to use the UML tools to build up the diagrams (such as use-case, sequential diagram..) and discuss with user but no prototyping at same time. Actually, it is a tough job for user to imagine the system without a "real thing" but it still better to convince them to follow it. It is because this is the only method to make the user think the system in the detail, not just based on the screen to determine what they need.
Honestly, this approach takes longer time during design phrase but minimize the risk under the implementation. As I mentioned earlier, this approach will let both developers and user understand what the system will done but not just a imagination. Prototyping makes things looks "real". However, it looks real only..
Ok. let's start now..
Today, I would like to say about prototyping. From this topic, you may think that how could develop a system without prototyping. Yes, it is quite difficult without prototyping but what I said is try to minimize the dependency to rely on Prototyping. In terms of presentation, prototyping is easy to present the "real" system to user. However, it will limit the user's mindset because everything is setup. What they do is just follow the screen flow, the field shown in the screen. It may hidden some important function such as interaction with other modules, intergration...
When we discuss with user on the prototyping, user just focus on Screen, not real situation..
From my opinion, it is better to use the UML tools to build up the diagrams (such as use-case, sequential diagram..) and discuss with user but no prototyping at same time. Actually, it is a tough job for user to imagine the system without a "real thing" but it still better to convince them to follow it. It is because this is the only method to make the user think the system in the detail, not just based on the screen to determine what they need.
Honestly, this approach takes longer time during design phrase but minimize the risk under the implementation. As I mentioned earlier, this approach will let both developers and user understand what the system will done but not just a imagination. Prototyping makes things looks "real". However, it looks real only..
Subscribe to:
Posts (Atom)
