|
Hi,
The system is already designed and almost going to be finish... from our experience with many clients when we set with the HR team and take all thier requirements. Yes, it is a standard procedures.
Job Seeker Register -> update his profile (his personal details, contacts and address) --> build his cv (using cv builder) or upload a document (CV).
when he attempt to apply he either apply with his current CV or upload new one.
this standard functionality is already taken into the account of the system. What i wanted is just to collect thouhgts and feedback. But i raise just one point which is:
when a job seeker update his CV using CV builder tool. Technically, he his editing the current record not keeping it as an old version CV and building a New CV from scratch (Adding new Record.). And whenever he want to apply with different cv he can do:
1. upload new cv when he attempt to apply for job (this is the easy way)
2. using cv builder to build a new cv (this will overwrite the existing one) then apply with his curent updated cv.
that was my point
bcz some of our client asked for copying the entire CV records againest the job and keep the orginal one unchanged. We are trying to come up with a general job application that fits most requirements.
the point i mentioned. i felt it is not right.
Hussain Mohammed Saleh Attiya
ISP Technical Manager
Atyaf Telcom - Bahrain
|
|
|
|
|
I have been reading "The Art of Agile Development" and it says that design of software should be minimal but not entirely suitable for change.
That instead, classes and such should be built for what the requirements currently do and not to make them for future changes unless required!
It does mention that some people may find that idea "unprofessional" such as my self but it does have a point that "In the end your architecture will reflect change suitable for the requirements you need not what you *could* need"....
Whats your ideas on this?
Thanks 
|
|
|
|
|
venomation wrote: It does mention that some people may find that idea "unprofessional"
The professional thing is to deliver what has been agreed upon with the customer. I'm not going to provide a plug-in architecture for something like a ping-command, nce it wouldn't add much value, merely luggage.
Imagine the ping-command popping up each day when you start Windows, claiming that there are new updates to be installed 
I are Troll 
|
|
|
|
|
Eddy Vluggen wrote: I'm not going to provide a plug-in architecture for something like a ping-command
While I tend to agree HERE, if as a developer/architect, you see an opportunity to design for expansion then why not do it?
When you consider it really, even PING follows a basic 'command line' pattern:
1) Allows the user to select a command
2) Allows the user to provide basic command line args
3) Allows the user to get help explaining the user of the command
4) Allows the use of various command line options
5) ...
so in a way, PING IS using a design pattern.
|
|
|
|
|
Ray Cassick wrote: if as a developer/architect, you see an opportunity to design for expansion then why not do it?
I can see lots of opportunities to design for expansion, but my time is rather limited. If I can choose between building functionality that "might" be used "one day", and something that's needed now - I'll go for what's need now.
Ray Cassick wrote: 1) Allows the user to select a command
2) Allows the user to provide basic command line args
3) Allows the user to get help explaining the user of the command
4) Allows the use of various command line options
5) ...
It's the command line environment that provides that functionality. It's strictly text, and as such, the ping-command does not offer any extensions for a visual plugin to configure it.
venomation wrote: should be built for what the requirements currently do and not to make them for future changes unless required!
That's the current UI, and the ping-command does indeed provide switches. It does not provide it's own scripting-language, it's not prepared to output HTML, it does merely what it's intended for, in the environment it was designed for.
You don't always take extensibility in account, just like we don't always take globalization in account.
I are Troll
|
|
|
|
|
Then perhaps we have a different definition of 'extensibility' and a different vision of how the process 'should' work vs. how it 'does' work.
Eddy Vluggen wrote: It's the command line environment that provides that functionality. It's strictly text, and as such, the ping-command does not offer any extensions for a visual plug-in to configure it.
Actually, given the way PING (as well as just about every other command line driven tool on windows) was written, you CAN wrap a visual component around it if you wanted to now. It is even fairly easy to use the /? options (provided that the original developer stuck to the standard) and have your GUI adapt to 'newer' versions of what it is driving with little work.
I am not trying to say you are wrong here, and I know that we have all fallen into the 'just get it done trap' before, and I am sure at some point been bitten by it also.
Now, globalization is a different story  That's freakin' hard
|
|
|
|
|
Ray Cassick wrote: Then perhaps we have a different definition of 'extensibility'
Guess so, and I started with a bad example on top of that. I take the parameters to a console application as part of the UI, just as a button on a form. To quote the topicstarter;
it says that design of software should be minimal but not entirely suitable for change.
Yes, a parameter might be required, but you're not going to prepare additional interfaces based on the idea that you "might" need them. One day. Somewhere.
Ray Cassick wrote: Actually, given the way PING (as well as just about every other command line driven tool on windows) was written, you CAN wrap a visual component around it if you wanted to now.
Has been done a thousand times at least, since the invention of VB4. How often did you download or use such a visual ping? Does it add value? Or does it merely eat your time?
Ray Cassick wrote: I am not trying to say you are wrong here, and I know that we have all fallen into the 'just get it done trap' before, and I am sure at some point been bitten by it also.
Yes, and thanks for the reminder. You're right; it shouldn't be used as an argument to get the product out the door.
"Add a column there, we'll add the other three in the next version."
I are Troll
|
|
|
|
|
I wonder if this is something like designing a system and have it based on 1 currency, you know there are multiple currencies out there, you know that retro fitting for multi currency is going to be a PITA, you know that it is relatively simple to add in the support for multi currency from the start of the design. And yet you do not add the 3 fields needed to support multi currency.
Now that I call "unprofessional" and yep I've seen it done more than once.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
This is quite a good example. The key thing is to know when to allow for future requirements, and when to concentrate on building what you need now. That's a judgement call that you learn through experience. Not every system needs to be multi-currency, but some do, so you need to make a decision about the system you are building.
Many people quote the agile mantra "you ain't gonna need it" when in fact it's just a cover for "I can't be bothered". Other people get caught up in the "what if..." game and end up building enormously complicated frameworks to cover every possible imaginable requirement that any hypothetical future user might possibly want.
|
|
|
|
|
David Skelly wrote: what if
One of my BAs is a classic one of these, I caught her the other day what iffing we got some type of data and asked her if there was any indication that such a thing could happen. Then spat the dummy when she said not that she could see but it might happen.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks for the comments !
I have decided to just use my "intuition" and try not to over design !
|
|
|
|
|
venomation wrote: says that design of software should be minimal but not entirely suitable for change.
Well...the project should be ready for some change. So this is confusing.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
My understanding of the YAGNI principle of Agile (You Ain't Gonna Need It), is that, as another post pointed out, what's needed now is much more valuable than what could be needed in the future.
Forgive me, I can't remember who I'm paraphrasing here, but the best practical description of how to implement this I've heard is:
Given your knowledge of the system, predict one or two things that are the most likely to change - while completing the actual requirements protect yourself from these changes through abstraction. When a requirement change happens (and, as we all know, it almost certainly will) protect yourself from that kind of change ever happening again in the future.
A contrived example would be a web application where all your colours are hard-coded. Suddenly The-Guy-In-The-Office-Who-Thinks-He's-An-Artist comes up and asks you to change the blue component of the background by 1. Of course, that just throws out the harmony and balance of the design, and suddenly a whole new colour scheme is on your desk. This is when you build a system to allow colour schemes to come from a config file (also known as CSS).
Do you see where I'm going? Wherever I read this advice, it was written a whole lot eloquently than I've just put it
|
|
|
|
|
Architecture should be extensible, code should be minimal. Having worked in senior development environments for many years, if a line of code is written, I assume it is for a reason. To spent time determining that the statement was not a requirement is expensive.
|
|
|
|
|
I would say that the book is correct on the assumption that the requirements analysis is of a suitably high standard to correctly ascertain 'future-proofing' requirements.
By that, i mean:
If you have spent enough effort in requirement analysis to be confident of where change is and is not a risk and to what degree change may occur and have subsequently included specific requirements for change 'suitability' then by all means code to these requirements alone.
If, however, you have vague and ambiguous requirements that are unlikely to have considered future requirement changes, i would recommend erring on the side of caution and spending a bit of extra effort to make the design as flexible as possible
But as someone else has pointed out, you deliver what you are contracted to deliver. As developers we have an obligation to advise on the best course of action when setting out requirements and, if we feel there is need to facilitate future changes, this should be pointed out tot he client. If the client can be persuaded then, effectively, the requirements have been updated and you are still following the book. If the client declines, well you did your best but its their (now informed) choice.
That said, unless the client has stuck their oar in as to how the technical design should be, there is nothing to stop you 'choosing' to implement a somewhat 'future-proof' solution (in terms of code layout, don't go slapping in superfluous functionality) if it does not impact your budget/time constraints. In most cases designing code that facilitates change is synonymous with designing code that facilitates maintenance and is, therefore, good practice regardless of your change-supporting requirements
|
|
|
|
|
I am planning to develop medium size library project for personal purpose. After documented the requirements, I designed an entity diagram. Now I am planning to define all classes, structs, enums and function body before coding the logic. As per my vision this method will help me to identify problems at the beginning, so that I can save the time to rewrite the logic. Is this a standard methodology? Is there any pre-defined method to do this?
Thanks and regards,
Thomas
|
|
|
|
|
Well, it's an interesting approach and an admirable one. Unfortunately, practical experience shows that the reality will fall short because requirements change as most projects and a rigid approach means that it is harder to adapt to these changes.
I prefer, now, a more fluid approach such as TDD coupled with SOLID architecture, which makes it easier to work with isolated simple to use classes.
|
|
|
|
|
But this is for my personal use. I am the coder and client So I am well aware of requirements. So are despite these problems, are you suggesting me to follow this mythology? Can you please suggest me any good read about this?
|
|
|
|
|
popchecker wrote: So I am well aware of requirements.
Are you - you're a much better person than me then ? Even on personal projects, I've ended up changing requirements as things have evolved.
There are plenty of articles here on Code Project and the web about TDD, I'd start off with general purpose articles if I were you.
|
|
|
|
|
I salute your discipline, I have yet to create a design specification before the project is at least 80% done. A personal project tends to start as a data structure and flows naturally from there. If I screw up the structure I just fix redesign and move on.
I use my personal development projects as learning experiences, usually built in a new tech/language so doing a bunch of design stuff before building it just seems silly. Data structures are pretty standard across all platforms but the internals of the app tend to be quite fluid.
I am lucky in that even at work I can just build the solution and then create the doco after the fact (or not if I'm really lucky) after all my work projects are ALL POCs
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
This is about the same for me.
For personal projects I tend to change design even more often as there is no one else involved I first have to consult with.
So, while coding I end up noticing a different approach might be better after all, etc. and change the structure.
When I learned programming they certainly did hammer into my brain that it's imperative to create detailed design sheets beforehand, but from my experience you should never go too much into detail unless required client side as it makes you far to inflexible.
And once you started changing designs, you should wait to change the documentation until the project is done or otherwise you end up wasting time to redo the documentation every time you change something.
I think it's best to design a concept and basic classes/methods beforehand and then fill in the rest when you really have coded it to not end up documentation a program that never came to be.
|
|
|
|
|
lol 80% done. I only laugh because personal or professional, that's probably the honest truth.
Architecture is extensible, code is minimal.
|
|
|
|
|
If you are doing this for learning purposes, then I would say this is not a bad idea. For someone who is learning OO programming, I think it can be useful to sit down and draw out the class structure first because it helps them learn to think in terms of objects and how they interact. Experienced programmers can get away without doing this because they have the experience to know what the rough structure of the classes should be, and they can evolve that as they go. Newbies don't have that depth of knowledge to draw on so they can easily end up with a huge ball of mud that sort of works but isn't maintainable.
I don't think you need to go right down to the level of detailing the function bodies and so on, but sketching out a class diagram will help to get things clear in your mind before you start and make sure that you can see the wood for the trees when you find yourself buried in the coding phase. But don't be afraid to deviate from it when you are coding if you find a better way to do things once you get started. It's a guide to help clarify your thinking, not a rigid plan to be mindlessly obeyed.
It depends on how experienced you are at designing and building this sort of application.
|
|
|
|
|
Hello,
I am having little design problem: I have one factory which will create object of with one type or another type. But my client requirement is to give(feed) the data(via setter methods) from outside world to the concrete class of type-1 not for type-2.
If I place these setter methods in interface, those need to be implemented forcefully both of concrete classes. This is NOT my requirement. I want to feed 1 kind of data for 1st type(some setters) and want to give another kind of data for other type(probably different setters other than which's contained by previous type.)
e.g
class ISubjectExecutor
{
public:
virtual void ISUBJECTEXECUTOR_EXPORTS_API Execute()=0;
};
class COMExecutor: public ISubjectExecutor
{
public:
virtual void Execute()=0;
void setCLSID();
void setGuids();
};
class Win32Executor : public IWin32Executor
{
public:
virtual void Execute();
void setFilePath();
};
Now here I can't use pointer of ISubjectExecutor (*pSubjectExecutor) to call setter methods of Win32Executor or COMExecutor on my choice at any time after reciving pointer(ISubjectExecutor) from factory. Because those all setters never exist inside ISubjectExecutor interface, and you can't access any method which's never contained inside interface and exist in concrete implementation.
How to tackle this design problem to solve.?
Regards
Usman
|
|
|
|
|
struct IParameter
{
int m_ID;
virtual ~IParameter(){}
};
class IParameterSetter
{
public:
virtual ~IParameterSetter(){}
virtual int SetParameter(IParameter *pParam) = 0;
};
class IFactorySpecific
{
public:
virtual void Execute()=0;
};
class ISubjectExecutor : public IFactorySpecific, public IParameterSetter
{
public:
enum PARAMETERID
{
ID_CLSID,
ID_Guids
};
struct CLSID : public IParameter
{
CLSID(){m_ID = ISubjectExecutor::PARAMETERID::ID_CLSID;}
int a;
.....
};
struct Guids : public IParameter
{
Guids(){m_ID = ISubjectExecutor::PARAMETERID::ID_Guids;}
int x;
......
};
};
class IWin32Executor: public IFactorySpecific, public IParameterSetter
{
public:
enum PARAMETERID
{
ID_FilePath,
};
struct FilePath : public IParameter
{
FilePath(){m_ID = IWin32Executor::PARAMETERID::ID_FilePath;}
char cszFilePath[260];
.....
};
};
class COMExecutor: public ISubjectExecutor
{
public:
int SetParameter(IParameter *pParam)
{
switch(pParam->m_ID)
{
case ISubjectExecutor::PARAMETERID::ID_CLSID :
ISubjectExecutor::CLSID *pData = (ISubjectExecutor::CLSID *)pParam;
return ...;
break;
case ISubjectExecutor::PARAMETERID::ID_Guids :
ISubjectExecutor::Guids *pData = (ISubjectExecutor::Guids *)pParam;
return ...;
break;
}
}
virtual void Execute(){.........}
};
class Win32Executor : public IWin32Executor
{
public:
int SetParameter(IParameter *pParam)
{
......
......
}
virtual void Execute(){.........}
};
IFactorySpecific *pExecutor = Factory::GetExecutor("COMExecutor");
ISubjectExecutor::CLSID stParam;
stParam.a = 10;
pExecutor->SetParameter(&stParam);
IFactorySpecific *pExecutor = Factory::GetExecutor("Win32Executor ");
IWin32Executor::FilePath stParam;
strcpy(stParam.cszFilePath, "c:\\abc\\xyz.exe");
pExecutor->SetParameter(&stParam);
Sameer();
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
