The Importance of proper Analysis and Design - Page 2
Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

Thread: The Importance of proper Analysis and Design

  1. #11
    AntiOnline n00b
    Join Date
    Feb 2004
    Posts
    665
    hi

    Now I have a question. What is the Waterfall?
    It's a Classical Life Cycle of a Program.....Often called the Classical Life Cycle Or Linear Sequential Model......Bacasically these are steps or guidelines to be followed from the very Begning of Proposeing a new system and following it until it remains in use.........This is called a Waterfall because like Waterfall the Steps are one way down you start at the top and go down the ladder without coming back ( well theoricatically...but in real you have to come back )

    Steps are
    • Analysis -- What factor ...Establishing What is the Problem(Until you have properly Identified the Problem you cannot find a solution)....Why we need to this
    • Design -- Logical Design ... The How factor .....mostly done on paper..how are we going to Correct the problem
    • Coding -- implementing What we have done in the above two phases
    • testing -- Preparing various test Case Plans ....and putting the moduses and the product as a whole through it
    • implementation/Mantainance --Preparing Implementating Plan ..deployig it at the site and mantaining the product till it is in service


    You start from the First Process that is Analysis and when you complete Analysis you go down to the next process that is design.......theroacially it sounds very good ...Complete one process and go down but most of the time dosen't work......new things creep up , requirements change.......market changes or just because the USer was shy was not pass what actually he wants in the system ........ you have to accomodate changes that why Irtrative Process models are more fesible these days as compared to Classical Life Cycle or Waterfall Model Model .

    For Further explanation.....i would recommend you try giving Software Engineering A Practitioner's Approch By Roger S Pressman a Look ...

    --Good Luck--

  2. #12
    Super Moderator: GMT Zone nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,190
    To follow up on SwordFish's comments:

    There is a sort of parallel "waterfall model" in IT career development. You see the classical:

    1. Systems Operator
    2. Programmer
    3. Analyst/Programmer
    4. Analyst/Designer
    5. Project Leader
    6. Project Manager
    7. Consultant/Architect
    8. Vice President/Account Director/IT Director

    OK the titles vary, but that is roughly the progression.

    My point is that the project management skills need to be introduced much earlier. This is particularly important in the software house and consultancy environments where you are on fixed price or time and materials.

    I have personally seen a $700,000 project where we had incurred $32,000 in pre-project analysis and proposals. The project had "stalled" and it was thrown at me I "cheated" and did it myself for $16,000 but billed the client for $48,000; which they happily paid

    The "spare" time I billed to another project I was working on. We got $48,000 for $48,000 worth of work, and my time was fully accounted for. Not "nice" I agree, but this was the same client who asked us to put time for an unauthorised project onto one that I was managing and was well within budget

    You have heard of "reality TV".............I guess that I am preaching a bit of "reality IT"

    This takes me back to the essential requirement to have a "contract" with the user UP FRONT. Then if they change the rules, we change the timescales, resources and costings.

    There is a "Change Management" process for projects, as well as for software. I tend to call the software one "version control", and manage the project side with "variation orders" (I stole that concept from civil engineering/construction)

    just a few thoughts
    If you cannot do someone any good: don't do them any harm....
    As long as you did this to one of these, the least of my little ones............you did it unto Me.
    What profiteth a man if he gains the entire World at the expense of his immortal soul?

  3. #13
    AntiOnline n00b
    Join Date
    Feb 2004
    Posts
    665
    Hi

    Very Often In Small and Medioum sized organisations .........Coders are given the extra burdon of doing the analysis too..........Which is is indeed a spelised feild in itself..........people want you to get over it as soon as possible because it costs bucks too ..and stsrt with the actual thingy called Coding.....a patch work analysis is worse than doing no analysis at all. and taling from a personal experience coders like to code not running after peole asking questions and preparing Questioneers .

    - During analysis and design, requirements change
    - During development, requirements change
    - Requirements change all the time
    - Mistakes are made during analysis and subsequently design, quite serious ones, which are subsequently overlooked until someone actually tries to use the first prototype
    - Design and analysis takes time away from other tasks, as a result the business becomes less efficient beacuse the solution is delivered later
    - People with absolutely ****all skill, get moved to being systems analysists, because it's perceived as "easier" than programming, they make a balls-up of it, then throw their shoddy half-done inaccurate "solutions" at the developers
    IMHo change is a fact of life they will always change that should put a extra emphasys on the importance of Analysys and Design.............to estimate the level of change that can occur and choose appropriate Process model............You choose an worng model and it would make you like as hell later.

    Changes can occour at any stage Analysis .......Design......Coding or later. If it occurs at the First two stages then it is easy to accumudate.........Resaon behind these changes can be many and implemenation of changes depends on what kind or level that the software require changed..

    --User Requirements changed........most of the users are not that techinacally blesses as coders or analyst to putting their thought to words it not a easy task for them.........requires a efficent Analyst to get ot out of them.

    --Extrnal Factors such techonology changed(hardware , OS)........Level of Competation changed changed...and many other.....these are much harder to predict and implement a plan for them in advance.

    That shouldn't discourage people from putting money in the Analysis phaze ( oo it's gonna change so lets build it then see what happens approch).........it should encourage people to put more effort to estamate the level of changes that might occur and prepare a proper Software Configuration Management Plan to accumuadate those changes at any level..

    Some people are quict to propose Prototyping at this point........Prototyping shouldn't be used as a magic stick for all the projects ...it's a waste of lot of money and effort in many cases.

    Choice of model is of atmost importance and it requirs a skilled Analyst to do that...because generally no Process model Fits your needs you have to sometimes mix modify a process model to fit your needs........like some people modify the Waterfall model to suit their needs .....Of course designations are changing we have got Analyst/Programmer and Analyst/Designer ..... i thing i too fall into that category . that makes your work easier as a programmer it you have doen the analysis yourself . I have always seen these two departments ( Analyst / Coders) at war with each other in my organisaton.


    acumodating changes after you are done with at leat a core product ......is not an easy job either and there are appropriate process models to accomodate them ....Brodly knows Softare Configuration Management......Establishing the basline and then following other methods that Nihil pointed out ...... Verson Control , Change Control , etc etc...and i belive thats a different feild all together different for the Software Process models.....and should be run parallel to the process model choosen earlier

    There is a "Change Management" process for projects, as well as for software. I tend to call the software one "version control", and manage the project side with "variation orders" (I stole that concept from civil engineering/construction)
    Why do you have to steal it when we have something called the Software Configuration Management...which accumodates all these

    Just my thoughts on the matter

    --Good Luck--

  4. #14
    Super Moderator: GMT Zone nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,190
    Hi SwordFish,

    Why do you have to steal it when we have something called the Software Configuration Management...which accumodates all these
    I am probably 30 years older than you

    Because of the low margins and considerable risks involved, there was a time when construction project management was about 20 years ahead of IT. We have only caught up in relatively recent times.

    And, Software Configuration Management does not completely cover what I call "contract management".............that is the billable/accountable side of things. Basically we have to "balance the books" and give the "bang per buck" whether we are an internal or an external resource.

    My view is that you have to look at the "big picture" unless (possibly?) you are buried in the guts of some off-the-shelf software company.

    I fully appreciate the angst of the programmer who has to do the analysis as well

    You get the "Oh and can you just do........." That is what causes a lot of project overruns!

    What you need is someone on the team with Business Analysis skills, or send your programmers on an appropriate course?

    just my thoughts
    If you cannot do someone any good: don't do them any harm....
    As long as you did this to one of these, the least of my little ones............you did it unto Me.
    What profiteth a man if he gains the entire World at the expense of his immortal soul?

  5. #15
    AntiOnline n00b
    Join Date
    Feb 2004
    Posts
    665
    Hi

    And, Software Configuration Management does not completely cover what I call "contract management".............that is the billable/accountable side of things. Basically we have to "balance the books" and give the "bang per buck" whether we are an internal or an external resource.
    Very True You knock at the doors of the Accounts Department and try to make them understand the importance of putting money on the Analysis and stuff and they give you that evil Grin ........There should be a Get money from Account Department Process Model.

    Everything said and done at the end of the day it's the Bucks that matters...and there is considrable void about that in Software Engneering.........By that i mean balancing the Money....there are few Cost Estimation Models ..........but alas nothig considerable .

    Yes my Compnay works on similar Projects Hotel related.....So most Projects are the same........even though some projects maybe more suited to some differnt Project model but because people of the organisating are more well versed with one model and team structures are well defined.........thats why it is given prefference....now who will take the headace of rearranging the teams (CC /CD/DD).......one more example how Software Engeneering is ignored.

    Software Engineering is still to get the status of a full fledged Engeenireng Dicipline....it's way far behind as yet thougt a considebral improvement has been done....it's still evolving.......people still have the impression that it's the programmer's job to do it.. Which IMHO is wrong

    Getting back to the Topic "The Importance of proper Analysis and Design" ................Yes it is utmost Important........and yes it is Ignored the only reason i see is money .............And about changes..........there are Many Process Models to accomodate the ever growing stream of changes ...........and Change Control is a different and vast process in itself..........and has to be implemented in parallel to the Process Model......Software Process Models In itself will not be able to fully accomodate changes.

    I am probably 30 years older than you
    emmmmm ..........

    or send your programmers on an appropriate course?
    Nooooooo After that they will start using programmers as Analysists and sales Persons then........they will suck the last Drop outta you ......o and can you recommend doubling my salary then too.......I am a programmer and likes to code nothing else.


    And Sorry about my Spelling And Grammer My English Sucks ^_^

    --Good Luck--

  6. #16
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    Originally posted here by nihil
    My point is that the project management skills need to be introduced much earlier. This is particularly important in the software house and consultancy environments where you are on fixed price or time and materials.
    I agree completely. I've watched people who were supposedly experienced developers get given a project and fail to manage their time, resources, and others' time very well, to the point where the project was taken away from them and given to me (rather an insult given my lack of formal education). Not that I relished being put in that situation at all, but it was interesting to see how people manage a project even on a small scale of like 2-3 developers.

    This takes me back to the essential requirement to have a "contract" with the user UP FRONT. Then if they change the rules, we change the timescales, resources and costings.
    Unfortunately not everyone has such a luxury, a lot of developers are not on a contract basis. In my case, I was working full time for the employer in question, and my approach was rather than get frustrated and yell about all the changes they wanted, I would consider how much time it would need, and come back to management with an estimate. There were times where my answer was simply "this cannot be implemented in the timeframe you requested". I think many people worry about saying no to their boss, but I look at it this way. I'd rather be a realist than fired when the project misses the deadline.
    Additionally, if changes were too widesweeping, I would put it to management that they had a choice: I could make the changes necessary with a revised and significantly lengthened deadline, or if the changes are not so critical, I could keep them on file for the next revision, and get the software out on the current deadline. Most of the time management opted for the "get the software out, add functionality later" approach, though not always. Either way it is good to get these decisions in writing so that you can keep it on file in case people above your boss don't agree with his or her decision -- CYA, ALWAYS.

    I posted this thread because I wanted to illustrate to the up and coming developers what doing proper analysis and design can offer in the simplest measurable form, and all everyone is talking about is the immeasurable stuff. 9600% speed increase is tangible, and when you show an example like that to management and non-technical staff, they begin to see why spending a few weeks or more analyzing the needs of the project and desigining the software meticulously and properly can yield some decent results.
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  7. #17
    I just wanted to mention that this is a great thread, and that all of a sudden the past few days, regardless of the complaining that has been going on, AO's content has been getting better.

  8. #18
    Super Moderator: GMT Zone nihil's Avatar
    Join Date
    Jul 2003
    Location
    United Kingdom: Bridlington
    Posts
    17,190
    Chris,

    Please do not misunderstand me, as I have worked for single employers, consultancies and on my own.

    I mean that you need an agreement with whoever you are doing the work for..........internal, external or whatever.

    I was once taught the buzz phrase "MCMR...........my customer, my responsibility"...........well that is IT, because we are a service function. On the other hand, the users have to realise that just because IT is an internal function it does not mean that it is "free".

    That is my biggest argument against outsourcing. As soon as they have to sign off the bills (a direct cost rather than an indirect/overhead one) they get very shy, so they don't ask for what the business needs...............they all sit there waiting for someone else to ask..............

    Then the outsourcer gets bored and lays off staff........HR are very happy, the wage bill is way down.....then a project comes up......but they have no staff, neither does the marvellous outsourcer because they fired them all............so then I step in at $1575 per day (minimum 3 months contract) and they have really "saved" money

    My advice is, if you hold stock in a company that is about to outsource IT, or is even considering it...........dump that stock fast

    I have actually been in the position of leaving a company on a friday, and re-starting with them on monday...........they outsourced IT, and I came back as a "senior software engineer"..........I was not one of the weapons of mass destruction types (the corporate business), I only supported them AGAINST ( and I do mean that) my former colleagues.

    Just my experience
    If you cannot do someone any good: don't do them any harm....
    As long as you did this to one of these, the least of my little ones............you did it unto Me.
    What profiteth a man if he gains the entire World at the expense of his immortal soul?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •