howto design a software ?

[Alvin chew]

hi, good day for everyone here ! i have basic coding skill but i'm not good in design , can some expert here please guide me how to design a software , i would rather appreciated someone can point out step by step , thank you very much !

take an example for development steps for web application development ?

i figure out as below, please do correct my idea

step0: gather requirement
step1: design html forms based on requirement
step2: design database based on forms
step3: select framework like struts
step4: coding
step5: apply design pattern for coding

is it the right way to develop web application ? i have limited experience on web application development, please help me !

[Tom Hill]

Any software goes through a development life cycle (loads of options out there). The basic linear one (waterfall model) will go something like this:

Specification: Definition of the task.
Feasibility Study: Is the task you have to do possible?
Analysis: This looks at existing systems and types of solution avaliable
Design: Now you are actually choosing what and how the function does it.
Programming & Testing: Doing all the nasty coding!
Implementation: Getting all the code in the write place so that everything works.
Maintainance: What to do if the system stops working, why , how to fix etc. This also including documentation on how to use the system.

This is just a simple model, of a life cycle. Each of these sections ca be further subdivided into specific areas eg (web development). It sounds like you have a basic idea of what should happen though. It is always good to keep these areas in mind so that you know how to build the system up - jumping straight into design can be bad, because you might ahve missed something that your analysis section would have helped you solve. You get the general idea!

Hope that helps

Tom
[ July 27, 2004: Message edited by: Tom Hill ]

[Dirk Schreckmann]

Moving this to the OO, Patterns, UML and Refactoring forum, where they love to discuss such issues...

[Lasse Koskela]

Web application development projects can benefit from the same design techniques and process models as any other kind of software using an object-oriented language. Thus, I would highly recommend reading books like Domain Driven Design by Eric Evans, Agile Software Development by Robert Martin, Applying UML and Patterns by Craig Larman, and Agile and Iterative Development by Craig Larman.
[ July 27, 2004: Message edited by: Lasse Koskela ]

[Junilu Lacar]

You can also get a free copy of "Java Testing and Design" from The Server Side

[Alvin chew]

thank you very reply , really appreciated your valuable comments !!

can somebody share the experience on real life software development that how a developer build a software from scratch ..eg: step 1: design html form, step2: design database based on html form....and so on,

in short , i need more specific details on every single step in software life cycle eg: design - should we design class first or database first, should be code basic required function first or interface should come out first before code ...

thank you !

[Stan James]

I have to weigh in with another vote for Martin's Agile Software Development. There are a couple case studies that take complex requirements to code. It's great to watch an expert use iterative design along with test-first coding and rafactoring.

[sever oon]

Having been a software consultant for a number of years (development), I can say that I've never seen a company grab a development process from any one source and use it. Companies typically structure the development process according to a number of factors, including the team, the project needs, the management structure, etc. Development processed do a lot more than develop software, they make the software extensible and flexible to meet future demand, provide for quality assurance, and most important to managers, provide visibility into the project (for managers, in terms of reports, and for developers, in terms of code reviews/documentation/etc).

The best approach I can think of, when it comes to learning about development processes, is to not limit yourself to one particular approach. Study waterfall processes even though you're not likely to use them, it's useful to be able to recognize the traits of a waterfall process when you encounter it. Most processes are iterative nowadays, and you'll want to spend time looking at the phases and ordering of the phases that they enumerate.

Take a look at eXtreme Programming, the Rational Unified Process, Six Sigma (this is more a quality process that can be applied to manufacturing as well as software, but it contains several key ideas that I've always found useful), the Agile techniques, and any other you happen to run across. Don't get hung up on knowing any one of them too much in detail (though you'll likely have to devote some time to both RUP and Six Sigma in order to get a decent high-level view of them), the point is that you'll be able to recognize which processes any particular company has pulled from to form its own dev process.

Beyond that, you can learn a lot about the architecture and design phases that is present in every software dev process just by studying OO design. Good guys to look to are Robert Martin and Martin Fowler. They've written a number of articles on OO design over at Object Mentor, just click on the resources/Published Articles link and browse through them.

sev

[Lasse Koskela]

Originally posted by sever oon:
Six Sigma (this is more a quality process that can be applied to manufacturing as well as software, but it contains several key ideas that I've always found useful)

May I ask which key ideas you're referring to?

[sever oon]

Sure!

First, Six Sigma primarily focuses on the QA phase of the development cycle (when it's applied to software, that is), but what's interesting about it is that it exerts a force in every other phase as well to support this purpose. When Six Sigma is used, the entire development process can be seen as existing for the purpose of supporting the quality phase. The real advance in Six Sigma is in getting people to think about quality, and what is meant by quality.

Most of the time, quality in software simply is reduced to mean bug count. Six Sigma requires one to take a more holistic view of quality in general. From a Six Sigma standpoint, if the application that results from the dev process doesn't support a particular important requirement, even though no bug results, it's lower "quality". (Read Zen and the Art of Motorcycle Maintenance to understand the context in which Six Sigma uses the term "quality".)

Besides that, there are many, many other ideas in Six Sigma that can be applied to software. Six Sigma splits into two main approaches to all projects: DMAIC and DMADV. It's been about 4 years since I intensively studied it, so I still remember all the big ideas but I've forgotten some of the acronyms...they're something like design?-measure-analyze-implement?-control and design-measure-analyze-???-verify. The first is used to improve existing products (as in supporting legacy software) and the second is used to create new ones (as in new development). One of the major tenets of Six Sigma that these two approaches support is measure-a-bility. In Six Sigma, if something can't be measured, it doesn't exist for the purposes of improving quality. That's not to say it doesn't exist at all, only it asserts that you must be comfortable with releasing all control over any aspect of a project that cannot be unambiguously characterized with a number.

A lot of people feel this is Six Sigma's downfall. A lot of people feel that things like flexibility and extensibility can't be assigned a number. Well, they might be right, but there's no doubt that even the most abstract concept has aspects that are measurable, and Six Sigma can be applied to control those things. Also, the focus on measurements, statistical analysis, and DoE (Design of Experiment) gives developers and software project managers a set of new ways of looking at software, a new way of thinking about things like performance, and most importantly, a new way of documenting and communicating about the important aspects of the project.

Like any process, it can be overdone. Six Sigma is a fairly heavyweight process so it's even more exposed to this kind of misuse. But one aspect of Six Sigma that I liked is that it requires nearly everyone on a project to formulate and drive dozens or hundreds of little experiments that constantly flex the product in a thousand different tiny ways. Making these kinds of forays into complex projects can provide previously undiscovered information about the software that was just unknown--even if it doesn't, it breeds a certain familiarity among the developers and managers that they wouldn't otherwise have. Certain discussions fall by the wayside because when there is a best way to do something, it very often is apparent to everyone involved without having to talk about it.

Anyway, one other advantage of Six Sigma is it grounds all discussion in the culture of measurement that it perpetuates. In other words, if you don't have some kind of validated experiment that shows some kind of empirical evidence to support what you're saying, no one's going to listen to you. On the other hand, regardless of who you are, if you have evidence that supports your point, your voice is heard clearly. Everyone on the project is capable of adding force to their viewpoints without fear of politics getting in the way.

This is all an idealization, but I've seen a couple of close approximations of this ideal at companies I've worked for, so it's not all smoke and mirrors.

sev

[Lasse Koskela]

Hmm. Sounds like you're talking about the same points I've manage to extract (based on purely superficial reading on Six Sigma), that is, focus on what the customer wants. Does that sound about right?

Originally posted by sever oon:
DMAIC and DMADV. It's been about 4 years since I intensively studied it, so I still remember all the big ideas but I've forgotten some of the acronyms...they're something like design?-measure-analyze-implement?-control and design-measure-analyze-???-verify.

DMAIC = Define-Measure-Analyze-Implement-Control
DMADV = Define-Measure-Analyze-Design-Verify

[sever oon]

Well, I think every process is ultimately about focusing on what the customer wants. That's just one of those management platitudes.

Truly, the benefit of Six Sigma is in the details. When I first heard about it when I worked for GE I did the once-over and thought, oh no, this is a super-heavyweight process. My attitude changed when I saw that it was able to be applied to things like extensibility, when I was able to run up DoE's in Minitab, and when generate formulas that show the scalability of subsystem and predict its failure points. It also really helps to sell management on your ideas when you have a process that puts an actual dollar value on your proposed contributions.

Good stuff...but it takes more than a passing familiarity I think to see the real value.

sev

[Lasse Koskela]

Originally posted by sever oon:
Well, I think every process is ultimately about focusing on what the customer wants.

In what reality you live in?

Seriously, while every process framework may promise to help deliver what the customer wants, few process instances are delivering on that promise. In my opinion, the problem is that people establish too many compliance-oriented processes to prevent certain negative things from happening while they should be establishing processes that enable certain positive things to happen.

[Tulsi Rai]

Hi All,
I am not sure if this is the right place to aks this question but since we are talking about a development process, i am gonna ask this question here. and the question is that how would you estimate a completion time for a given task by a boss? If a boss or manager assigns you a particular task or a module and asks you for a rough completion time for that particular task. what is the real world way to give him/her the estimate? are there any formula or some approaches?
thanks.

[Junilu Lacar]

Originally posted by Lasse Koskela:
In my opinion, the problem is that people establish too many compliance-oriented processes to prevent certain negative things from happening while they should be establishing processes that enable certain positive things to happen.

Alistair Cockburn cites a good example of this "playing to not lose rather than playing to win" strategy in one of his books.

[Lasse Koskela]

Originally posted by t ray:
Hi All,
I am not sure if this is the right place to aks this question but since we are talking about a development process, i am gonna ask this question here. and the question is that how would you estimate a completion time for a given task by a boss? If a boss or manager assigns you a particular task or a module and asks you for a rough completion time for that particular task. what is the real world way to give him/her the estimate? are there any formula or some approaches?
thanks.

Our Process forum would be the right place to ask about estimation so I took the liberty of starting a new thread over there.