 |
|
|
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.
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
Not sure if this is the appropriate place to post but I found it odd that none of the top five online education companies offer content for smartphones. Desktop laptop and, of course... the iPad. Its not a form factor or capacity issue. Looking for a credible reason why this might be the case. Guidance sought
|
|
|
|
|
|
|
I think it's just because the explosion in popularity is still relatively new. So they're probably playing catchup just like a lot of us. There are plenty of online resources available though, just have to do a little research. The Android community is pretty active posting things in community forums (although the official Android website just points you to StackOverflow, but if you search online you'll find other forums).
Good luck! 
|
|
|
|
|
|
|
One can only guess of course but some possibilities...
Education normally moves a bit slower than the consumer market place. Not sure how this fits with iPad but maybe because little effort is required.
There can often be beauractric hurdles associated with education.
The market is driven by sales not technology. And for some reason either the companies don't see opportunity or they did investigate it and found it lacking. Perhaps based on per item revenue expectations.
There is a 'toy' perception of phones apps and those companies don't want their apps taken that way. And the first implementer might suffer until acceptance is gained so no one wants to take the plunge.
They are all actively working on it but they haven't released it yet.
|
|
|
|
|
|
|
I teach at TAFE is Australia. One of the reasons there is little iOS offerings is because up until recently, there was little demand so most labs are setup to run Microsoft/Linux. I'm sure this will change, we are already aware of the demand.
Also I question the value of online except for the purpose of getting the qualification. If its not the piece of paper you are after, there are plenty of free online resources.
Class room environments are best because teachers can normally tell who's comfortable and who's struggling immediately. Online teaching makes this a lot harder to identify. Also more experienced/talented students can be pushed harder and get a deeper understanding of the subject matter.
"You get that on the big jobs."
|
|
|
|
|
|
|
Message Automatically Removed
modified 30 Jan '12.
|
|
|
|
|
|
|
This message is spam. If you want to advertise here on Code Project, buy an advert.
|
|
|
|
|
|
|
This is not a question. Please don't advertise here.
|
|
|
|
|
|
|
Let me correct that one vote.
|
|
|
|
|
|
|
Pete O'Hanlon wrote: Let me correct that one vote.
Thank you.
|
|
|
|
|
|
|
As the members of CodeProject are not interested in this topic. It may please be deleted
|
|
|
|
|
|
|
Its not that we aren't interested in the topic but your message appears to be selling something. If we have this wrong then please create an article and many will read it
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|
|
|
|
Thank you.
We will submit the article.
|
|
|
|
|
|
|
We are creating a chat app for our office colleagues. Currently we are thinking of using web service for sending and receiving chat messages [calling function every 5 second]. Since this will be for smart phones [iOS, Win Mobile and Android] is this the best design or can this be improved or is there a better one.
|
|
|
|
|
|
|
I haven't done any push notification work but that maybe a better way to go.
"You get that on the big jobs."
|
|
|
|
|
|
|
Hi,
I'll make it short and clear (I hope).
We have two teams developping our product, the R&D and the 'Integrators'.
I'm not sure how the Integrators are called in english, maybe TPAM (Third Party Application Maintenance), anyway, let's say that Integrators = People working on the base product, adding or changing functionalities for a specific customer. And the R&D team beeing in charge of doing what's common to all of them (the customers).
The R&D team is in charge of developping functionalities available to all our customers, and the other team only does specific developments for specific customers.
The problem we're dealing with is that both teams may develop on the same web pages, controls, business logic etc. What happens is that our Release Manager deploys what the R&D team has been doing in some sort of common workspace, and he can't be aware of what's from one team or another, so a lot of times, the Integrators work is lost and our release manager spends hours finding the 'lost changesets' and re applying those modifications.
We're need to solve this problem and what we came with far now is to develop some sort of API exposing all the common asp.net events (page_init, load, render, etc.), we also should fire events when entering/exiting BL and DAL functions allowing the Integrators to develop 'manually', maybe injecting some asp.net code into the existing pages, also some code behind, javascript, etc. I'm not really sure if this is a reasonable idea or not, we've just been thinking for like 10 minutes and I wondered what did you recon in this kind of situations.
This is just an idea, because they may develop everywhere... Web, BL, DAL and Database (we have a project for that).
Just to be clear, we're developing a product, I'm not sure how it's technically called in English but our application will keep growing over time so we really need to do this right otherwise it will cost us a lot of time and money to correct that later when we'll have people using our 'API' (I'm calling this an API but I may be wrong about that)
Anyway, we're stuck here, I hope I was clear enough, if not tell me and I'll try again!
Thanks in advance
PD: I posted this in the ASP.NET and Design and Architecture forums, I apologize if this is not ok and you're free to delete one of them.
|
|
|
|
|
|
|
_Zorro_ wrote: The problem we're dealing with is that both teams may develop on the same web
pages, controls, business logic etc
First problem is right there.
Those components probably should not be treated the same in terms of Professional Services (PS) (customization for different clients.)
Commonly the business logic will have a standard API, which the PS can either add to or replace. Replacement is an option and one that should probably be avoided. A plug in architecture can enhance the above by assuming that functionality will be replaced while provide a default functionality ONLY if a replacement isn't found.
For the GUI it is often only a replacement, either complete or plugin (but I have almost no GUI experience so other options might exist.)
But regardless I think you need to have an explicit strategy for business objects and a different one for GUI even if it seems like they overlap.
All of that is a design/architecture problem only and not build/install.
For install/build ALWAYS uses the following idiom.
1. Lay down the base product.
2. Lay down the customer (PS) product on top.
|
|
|
|
|
|
|
Thank you jschell,
What you’re describing about the BL is more or less what we started.
We made a project where we allow other developers to override the implementation of our functions. If we find that/those DLLs then we use theirs otherwise we use ours.
It works great actually. But the main concern is the UI. We do not want to have to maintain a lot of duplicated (replaced) pages. What we were thinking was to expose some events and let them write their code dynamically. It would be interpreted at runtime.
What do you think about that solution? Do you see any inconvenient I may be not anticipating?
Thanks again.
|
|
|
|
|
|
|
_Zorro_ wrote: What do you think about that solution?
Absolute best way to generalize something is to start from existing examples.
Presumably you have such examples.
You can divide them into categories.
1. Those that are always changed (or almost always)
2. Those that are sometimes changed.
3. Those that seldom are.
The first case requires a relook in terms of architecture/design. It could be that the base functionality is just wrong, or that there are easily defined pluggable areas that would make it obvious.
The second case is harder in that it might require a more flexible look or it might just be leave it as it is.
The last case is easist, it must always be written fresh as an overlay.
|
|
|
|
|
|
|
Thank you for your answers
|
|
|
|
|
|
|
On my organization, we're doing the same thing as you do: Develop a product (core), and at the same time provide customization (integration).
First of all, we have several environments per each customer. Development, Test, and Production. Development environment is for developers, Test for testers and Production for customers. Easy enough!
Plus when we do a deployment in either Test or Prod, we first get the core, and then overlay the changes. And that overlay-ed source is installed in the environment. So the changes doesn't get lost.
We need the Test environment between Dev and Prod because Dev is frequently changing, and not stable enough for testing, and we can't do whatever-we-want in the Prod environment.
For our customization's (integration for you), we have a set of Dev/Test environments per customization project.
No matter how many APIs you develop, your problems will remain there until your two teams develop in the same environment.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin