|
But that is our job ... take "functional requirements" and translate them into a workable solution; which could be a combination of manual and automated procedure.
There will always be new requirements; you simply assign them a priority and catalog them while working on the core requirements. If the original analysis was performed correctly, you will have a core functionality around which you build. If a "new" requirement comes along that causes you to rethink your "core", then the original analysis / design missed its mark.
I find that when I truly understand the user's requirements and write the software in such a way that "I" would be pleased to use it, the user's response to the product has always been positive. One still needs to go back to the user at regular intervals to demo the product and get feedback. And if you cannot demo something new at least once a week, then the problem has not been partitioned properly.
|
|
|
|
|
While providing an architectural solution proposal, what do I need to include under section - "Dimensioning & Configuration"? Specific example for ASP.NET + SQLServer scenario would be helpful. Thanks in advance!
|
|
|
|
|
Its framework development for automation test system from initial phase(vb .net and oops). so that below layers can communicate with each other but in some protected way.. and can be handled
seperately without affecting others functionality.
1. ApplicationUI
2. TestScripts
3. class libraries(few functions is accessible from testscripts, and few from other libraries and then remaining critical functions(e.g truning OFF the hardware) are inaccesible ).
4. reporting.
furthermore
below is the control flow.
User--->Application(StartTest and generateReport)-->TestScripts(for 200 testcasess)->Libraries which includes Testscripts functions+Interface libraries(Measuring instruments & Device under test ).
i am looking for
1. How to share data across layers in restrictive way...
2. what are the oops concepts(this perspective as well) that can help.
I cannot go with the certain design patterns(MVC,factory pattern..etc) also,since defining the framework data is happening parallel.
kindly help.
|
|
|
|
|
Hello, everybody!
I`ve been interested in architecture and design for about 10 years and read a lot of blogs and literature on the subject. Could you give me some titles of books about it? May be I haven`t read it yet and want to learn about something new which is worth attention!
Thank you!
|
|
|
|
|
You could try searching Google, your local library, bookshops ...
|
|
|
|
|
What architecture?
You start off with a 3-tier system, select a DBMS (relational or whatever) for the back end, choose HTML or any such crap for the front-end and there is your architecture.
Is there anything else?
Welcome to the world of suburban tract-home of computer architecture!
|
|
|
|
|
You should definitely read this Patterns of Enterprise Application Architecture[^]
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
My aim of finally year to do big and nice project that can work in on web and desktop.
In desktop when no connection application can work without any problem and when connection come just it update the action performed.
So I Think it possible but i no title for that project "Please help me for give title"
|
|
|
|
|
You first need to decide what actions, inputs and outputs the application will contain. The title is trivial, you could even name it after your cat.
|
|
|
|
|
My project i want to help my country (government) and record the information on government
|
|
|
|
|
|
You could go totally off the wall and call it "Doofus and the chocolate fireguard".
Starting with a title is a terrible idea - you need to work out what you want your application to do first, and then work out what it's called.
|
|
|
|
|
You can give more information about title
|
|
|
|
|
"My recipes".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
You explained what the app does technically, which sounds like a generic data-application. Based on your first post, you want to edit/share data - like cooking-recipies. I'd recommend a name that gives a hint as to which problem it solves for the user.
When in doubt, call it "Henk" and rename it later 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Well, that depends on what kind of person you are, and the personality of your teacher/professor.
In your situation I would name it something like:
- Yet To Be Named
- Function over Form
- The Unnamed Application
- [Insert name here]
or
- MyTIB (acronym) = My Teacher Is the Best
The best way to name something is either using an acronym:
- YP3 or YPPP = Your Personal Podcast Player
- FREE = Financial Records Enterprise Edition
- STEEL = Software To Extract and Evaluate Lists
- WINDS = Windows and Internet Networked Development Software
or just describe your software:
- Free Website Creator
- Your Budget Personal Edition
- Personal Notes and Reminders
- Your Personal PodCast Player
There are also tons of name generators out the on the web, and you could also look up in a dictionary and find a word like "Avalanche", that is just a word and does nothing except identifying your application
Good luck!
|
|
|
|
|
I had this question earlier on what would I consider as a complex architecture and just responded with a blank stare as I was confounded.
On my own opinion, I would like to think that architectures need to be complex, or rather even if it is "complex", if it was designed properly, it should still be straightforward and easily understandable.
I do have my doubts, so please be gentle with the pitchforks.
What do you guys think?
|
|
|
|
|
Member 4411225 wrote: What do you guys think?
About what?
|
|
|
|
|
You can not learn a design pattern simply by running into one that you never seen. Same goes doubly so for architecture. You will not learn CSLA.NET simply by looking at it and going "Yes, I see now".
We aim to keep things as simple as possible, as having things simple makes stuff easier to maintain. But no, you do not recognize a "good" architecture simply by it being straightforward or easily understandable; source-code is not an instruction manual, does not show the bare bones and comes with a lot of noisy details not related to the architecture but to the problems that the application solved for its domain.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
NickPace wrote: IMHO anything that does not follow the SOLID principles is probably overly
complex
Hence, "most of the code in existence today".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Hence, "most of the code in existence today".
I would say that within the bounds of error and statistical variation that "most" is actually "all" in any meaningful sense of the word.
|
|
|
|
|
Member 4411225 wrote: I would like to think that architectures need to be complex, or rather even if it is "complex", if it was designed properly, it should still be straightforward and easily understandable.
I would like to think that unicorns were real but reality keeps getting the way.
Humans are limited. Humans are fallible, even the ones that are really good.
Complex systems and some point do not become amenable to being easily broken down.
And finally of course businesses are not willing to wait much less spend infinite sums of money waiting for perfect solutions. Even presuming they knew what the wanted in the first place.
Consequently systems are messes. And more complexity means more mess.
The only goal can be to insure that is not any more messy than it needs to be. Within limits.
|
|
|
|
|
Architecture is similar to design but at a larger scale. And like design, is about managing the complexity of a software system (or multiple software systems that are interacting with one another).
There isn't anything inherently complex about architecture, except that few people have practical experience of it. Designing and architecting large enterprise applications requires a deep understanding of architecture patterns. For this I would recommend Martin Fowler's book on Architecture Patterns.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
