Software Construction Methods

yeah now lets get back to business and talk stuff related to job and BA's rather then discussing things a BA should know or shouldnt.. i am sure anything mentioned here wont harm a BA. I know that even if a BA doesn's even know all these stuff he can survive.. yeah he can survive in IT industry alright/... but well never mind.. lets talk about software construction methods :

To mention a Few related to and important for BA's :

• Waterfall Method
• Rational Unified Process (RUP)
• RAD methodology
• Synchronize & Stabilize Methodology
• Prototype Model

Waterfall Method :
Here development is seen as flowing steadily downwards (like a waterfall) through the various phases of (SDLC) requirements analysis, design, implementation, testing (validation), integration, and maintenance. The term was introduced in 1970 by W. W. Royce; ironically, Royce himself advocated an iterative approach to software development. Royce originally proposed what is now known as the waterfall model as an example of a system that he argued "is risky and invites failure"

The following phases are followed PERFECTLY in order in waterfall method:

1. Requirements specification

2. Design

3. Construction (aka: implementation or coding)

4. Integration

5. Testing and debugging (aka: verification)

6. Installation

7. Maintenance

Anyhow this method has recieved severe crticism, just follow a couple of links to know how much people love (?) Waterfall... (seems this waterfall has made a lot of people wet ;-) )

http://jeffsutherland.com/scrum/2004/10/waterfall-method-colossal-blunder.html
http://tarmo.fi/blog/2005/09/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

Do read them.. even if one loves it or hates it.. one should surely know what are the aspects that could be be crticised or appreciated... what say..

enough blogging for the day.. or night? yeah pretty late.. lets call it a night

Its NOT just about COMMUNICATION

welll software construction methods, Development, analysis & design, testing.. and why the heck is a BA supposed to know all that..

so for all those who wonder a BA has to be a non technical person here comes the eye opener, a BA has to know all about the Software construction, development, design, testing.. ie all stages of the SDLC.. so its not just about the communication and requirement gathering.. i have found many people think that a guy with excelent communication skills can handle the BA job with perfection but the point is not that, good communication skills are important for sure but deep knowldege about the SDLC, about development team & their capabilities (shortcomings too) software construction methods and all other aspects of client needs..

so i concur that Communication is a very important part but having a hold over othe stuff mentioned is also very important as it would only help a BA through out the project...

P.S: ANYWAYS I HAVE NEVER MET OR SEEN A BA WITH POOR COMMUNICATION SKILSS, SO IF YOU ARE NOT CONFIDENT ENOUGH ABOUT YOUR COMMUNICATION SKILSS................... BETTER TRY ANOTHER JOB :-(

JAD Session

So another important aspect of a BA's life is JAD session.. though it is pretty important i have to say its not really some thing a BA has to deal with every day.. probably coz its an exhaustive exercise and people have to fly over from all over the country.. so it does become expensive an proposition..

So wondering what the heck am i talking about... ok lets begin with some general explainations about JAD, to begin with a rather funny one i found on Expert knowldegeBase

JAD stands for Joint Application Development. It's one of those software engineering techniques that some folks with lots of time on their hands sat around and dreamed up. All the design methodologies like this are complicated replacements for a huge dollop of common sense. Sit down with the client and design a paper UI that they can see what the application will look like and behave like. Give the user a chance to work through common scenarios and see if the application will work for them. Keep refining until the user feels the application is doing what they want it to do. As you get functionality implemented, bring the user in and have them work through those scenarios and see if it still works.

On a more serious note, According to Wiki "JAD is a popular Fact-finding technique that brings users into the development process as active participants"

A Typical JAD session agenda:

Project leader: 1) Introduce all JAD team members 2) Discuss ground rules, goals, and objectives for the JAD sessions 3) Explain methods of documentation and use of CASE tools, if any

Top management : Explain the reason for the project and express top management authorization and support.

Project Leader: 1) Provide overview of the current system and proposed project scope and constraints 2) Present outline of specific topics and issues to be investigated.

Open discussion session, moderated by project leader: 1) Review the main business processes, tasks, user roles, input, and output 2) Identify specific areas of agreement or disagreement 3) Break team into smaller groups to study specific issues and assign group leaders.

JAD team members working in smaller group sessions, supported by IT staff: 1) Discuss and document all system requirements 2) Develop models and prototypes.

Group leaders: 1) Report on results and assigned tasks and topics 2) Present issues that should be addressed by the overall JAD team

Open discussion session, moderated project leader: 1) Review reports from small group sessions 2) Reach consensus on main issues 3) Document all topics

Project leader: 1) Present overall recap of JAD session 2) Prepare report that will be sent to JAD team members

Typical JAD's :

• Business Process Modeling JAD
• Business Rules Definition JAD
• Business Data Modeling JAD
• Requirements Gathering JAD
• Quick Fix Design JAD
• Test Planning JAD

To sum it up :

Joint Application Development (JAD) enables a group of people to grasp complex issues quickly and make informed decisions.

The core component of JAD is a structured, facilitated workshop that focuses on creating specified deliverables based on the group's input.

It is an effective tool for planning a project, designing a solution, defining requirements, or any other process that requires consensus-based decision making across functional areas.

Source / Credits :Wiki, Requirementsolution.com, expertanswercenter.com, Brainstorming-that too alone ;-)