business requirements

Aug 7 2009   10:00AM GMT

Ten Mantras for a software developer

Posted by: Jaideep
Software developer, software development, Application development, Software application, software testing, bug-free, Bug, software, application, bug identification, application building, code writing, application performance, business requirements, Business Rules, code validation, business process, process owner, end user, collaboration, tester, application functionality, software functionality, software performance, quality, customer experience, software build, bug fixing

Lot of efforts can be saved in terms of time and money if we reach to a stage of ‘first time right’ in application development. It has been proven largely that no good application can be built and released without extensive testing. Testing is not developers’ ball game – this is also a well proven fact. Reasons are many as far as it is concerned that why developers can’t build a bug-free application, or why can’t they test on their own. We are not going to discuss those reasons here. Focus here would be on what developers should keep in mind while building an application that it requires minimum efforts and time in all testing stages. As we all know the cost of bug fixing goes manifold, depending on how much distance (in terms of time and project stages) it has covered after development for bug identification. The bugs identified at a later stage, say during UAT cost more significantly as compared to the bug identified by the developer himself immediately after writing a code. Few qualities if a developer acquires and keeps in his mind while writing codes would not only benefit him but the organization he is working for and their customer also for whom the product is being built.

1. Commitment to application performance should be kept in mind while writing a code.
2. Clarity of business requirements and rules/ validations that are being translated into the application with real aptitude of business and not a developer. Don’t imagine and build. If there is some lack in clarity – discuss, record and build.
3. Treat yourself as the business process owner and end user – and build the application accordingly as if you have to use it. Don’t think yourself as a bartender, think as if you are preparing the drink for yourself.
4. Collaborate and build – rather than building in isolation- collaborate with other developers working on the application, the end user, and the testers.
5. Optimize your code – don’t just write it. There are n numbers of optimizers almost in all technologies. Use them and build a strong application in terms of functionality and performance. Be quality focused. Don’t do efforts that call for more efforts later.
6. Be focused. Don’t work on various applications development at the same time unless it is too mission critical.
7. Gain customer experience after launch of your application. It will certainly help you in your future builds. Build a customer satisfaction metrics.
8. Don’t take short cuts in fixing bugs – whatever stage they are identified. That way you will build more bugs while fixing identified bugs.
9. Work like a champion. There is a difference between playing a shot and playing an accurate shot.
10. Be loyal to yourself, your organization and your work.

May 11 2009   10:12AM GMT

Two aspects in Change Management in Software Project

Posted by: Jaideep
change management, Software Project, Project Management, project cycle, Project Development, software development, software implementation, project implementation, software requirements, business requirements, business study, project manager, Business Rules, customer management, customer requirements, project team, business critical change

Change management is a subset of project management. In any software project change is to be managed during the whole cycle of development and implementation. Requirements once specified by customer at the business requirements study phase does not mean that there will be no change in requirements later. Vendor who is not open to mange or cater to this change in requirements will not be able to deliver the product to customer upto his satisfaction. To mange these changes Change Management is essential and both have to play their respective roles in managing the project. Changes could be in terms of specifications, process being re-defined, or change in business rules. The two aspects for change management are – vendor and customer.

At Vendor level the Project Manager should accept changes only that are business critical and not cosmetic or wishful in nature. He should redefine the project/ development/ implementation plan in terms of time and revenues in consultation with his management taking customer management in confidence. He should incorporate changes only after getting it approved by customer top management.
The Project manager has all rights to challenge any change in requirements that is fanciful, not business critical and is impacting the software largely in terms of efforts and time.

At Customer level the Management and Project team have to understand the impact of any small change on the software thereby asking for a change only if it is a business critical change, analysing if the change can be avoided, and understanding the time and cost effect of the change.

Mar 4 2009   10:03AM GMT

10 top “Do this if you want blunders!” in Software Development and Software Testing

Posted by: Jaideep
software development, software testing, Project Management, Software Project, Quality Goals, software quality, SQA, SQC, product development, project documentation, organizational goals, time to test, development plan, Project Plan, Test Plan, test case, implementation plan, project close-out, top management requirements, requirements analysis, business requirements, change management, Risk Plan, Risk Management, Software Repository, Code library, Code repository, test case repository, project standards, project methodologies, software development standards, software development methodologies, test standards

1. Quality Goals are meant only for Quality Department: No department other than quality (project management, product development, documentation, general management etc.) has to read, understand and learn about the quality goals of the organization. It is only the responsibility of quality department and quality staff. So keep performing without ‘quality’ in it. After all the quality has to do its job.
2. Don’t define your quality goals: If quality goals have such a low value in the organization, don’t document it. Because even if it gets documented, it will be never read or adhered to. Why waste efforts and paper.
3. Give least time for testing: In your project development plan, keep least time between the release time and development finish time so that quality people get least time to test the product and thereby least burden to the production/development team.
4. Have a highly versatile and flexible project plan: Build a scope of huge flexibility and versatility in your project plan/ development plan/ testing plan/ implementation plan to make it a never ending project.
5. Don’t focus on customer top management requirements: Just focus on the user’s and department’s requirements while freezing customer requirements in requirements freezing stage. Discard top management in all briefings, findings and their requirements analysis at any stage. This may make you success in all stages except the final project close-off stage, which will never come in this scenario.
6. Adopt no methodology: Don’t try for any world class standards or methodologies in your project management even if you have any world class projects in hand. Be assured that both situations will go hand in hand for a long run. So no need to worry.
7. Learn the art of converting inadequate into adequate: Project in your review reports at all stages that situation is under control with an art of projecting inadequate efforts, planning etc as adequate.
8. Never change: Have a firm belief that priorities have no meaning. Keep working on your pace as per your desire. Don’t prioritize and re-prioritize anything, ever.
9. Risk: If your trust yourself, be firm that there is any risk to assess. There is no requirement of risk assessment and risk planning in your projects at any stage.
10. No Repository: Who says – there has to be a library of codes and test cases for instance? Why create a repository? You have enough time to work and re-work on anything.

Feb 27 2009   9:54AM GMT

Software Quality vs Project Quality

Posted by: Jaideep
software quality, project quality, quality standards, quality measures, quality metrics, software metrics, Project Management, Software Project, customer requirements, software product, software design, business requirements, functional requirements, software delivery, Project Delivery, project execution, project initiation, Project Development, project implementation, software strategy, test strategy, test case, Test Plan, test scenarios, test results, fixing of bugs, project close-out, post implementation phase of project

The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.

In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.

In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.

The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.

Jan 16 2009   10:12AM GMT

Understand customer requirements and make your customer understand

Posted by: Jaideep
CRD, Customer Requirements Document, business requirements, customer requirements, defect free software

You not only have to understand the customer but sometimes you have to make customer understand what exactly he requires to enhance his business. Many a times, a customer is not able to chalk out clearly what business requirements he wants to get embedded in the software. He is not clear about what exactly he should get embedded in the software to get the optimum out of the software and business mix. He might be having a broad idea about what he wants to see as a final product, but may not be able to define what the core components of this product are. Customer would say the team to study their business as they are doing it, without getting involved in it. This could be serious and the seriousness if not understood rightly in time (emphasize on ‘understood’, rightly’ and ‘in time’), would lead to disastrous results.

Customer is not for experimentation. Clear and crisp ‘Requirement freezing’ is the right start. Customer may be required to be educated on what business, requirements and rules can be built in the software. A simulations or scenario generation is important to make customer understand how the software will work once completed. Customer needs to understand very clearly at the initial phases - What ease or comfort will the software bring out to business processes by giving out certain set of business results. Customer has to understand very clearly the other part of the story too. The software definitely will require certain extra skill sets, enhancements, or extra efforts once it is completed and implemented at customer site.

Jan 12 2009   10:04AM GMT

Top 5 Quality killers in a software product

Posted by: Jaideep
software quality assurance, software testing, documentation, Project Management, software, Development, software quality, Quality Assurance, SDLC, business management, software development, Project Lifecycle, software requirement, business requirements, Project Development, customer requirements, defect free software

In software development project what matters most is the timely accurate delivery that gives the benefit of defect free product, customer satisfaction, profits, market edge, growth, motivation across the organization etc. All this is not easy to achieve having so many enemies in and outside the organizations that mars the development progress or a sub-standard product. These negative factors or enemies lead to a low in quality product that faces a tough time at customer end resulting in rejection. To name top 5 quality killers in a software product, I would list them as below:
5. Requirements: customer requirements or product requirements is the foundation of software. Any sort of compromise in this would lead definitely to a disastrous product.

4. Management: Intensity of management’s involvement in the product development throughout spells out the success or failure of a product.

3. Documentation: Development plays an important role during a product lifecycle and so does the documentation.

2. Customer Involvement: The involvement of key users at all levels of development and implementation is quite crucial.

1. Testing: ‘When’ to involve the ‘testing’ team defines the earlier successful completion of a project.