Monday, January 27, 2014

Software Project Management


Q. Explain the four P’s for the effective software project management.
Ans: The effective   software project management focuses on four   P's.

·         The  People
·         The  Product
·         The  Process
·         The  Project

The People
The following categories of people are involved in the software process.

Senior Managers
Project Managers
Practitioners
Customers
End Users

Senior Managers define the business issue. Project Managers plan, motivate, Organize and control the practitioners who do the Software work. Practitioners deliver  the technical   skills  that  are necessary  to  engineer a  product  or  application.Customer specifies  the  requirements  for  the software  to  be developed.End Users interact  with the  software once  it   is released.

The  Product
Before  a  software  project  is  planned, the  product  objectives  and  scope  should  be  established, technical  and  management   constraints  should   be  identified. Without  this  information  it  is  impossible  to  define   a  reasonable   cost,amount  of  risk   involved,the  project  schedule etc. A  software  project  scope  must  be  unambiguous     and understandable  at  the  management   and   technical    levels. To  develop  a  reasonable project  plan  we  have  to  functionally   decompose  the   problem to  be  solved.

The  Process
Here  the  important  thing  is  to   select   an appropriate  process  model  to  develop  the  software.There  are different  process  models  available.They  are Water  fall  model,Iterative  water fall  model,Prototyping  model,Evolutionary  model,RAD(Rapid  Application  Development) model, Spiral model.In practice we  may  use  any  one  of  the  above    models  or a   combination  of  the  above   models.   

The  Project
In  order to manage  a  successful  software  project,we  must  understand  what  can  go  wrong (so  that  problems  can be Avoided)and  how to  do it  right. A  project  is  a  series  of steps  where we  need  to  make  accurate  decision  so as to  make  a  successful  project.

Q. Explain grant chart. Also give advantages and disadvantages of it.
Ans:  Gantt chart is a type of a bar chart that is used for illustrating project schedules. Gantt charts can be used in any projects that involve effort, resources, milestones and deliveries.At present, Gantt charts have become the popular choice of project managers in every field.Gantt charts allow project managers to track the progress of the entire project. Through Gantt charts, the project manager can keep a track of the individual tasks as well as of the overall project progression.In addition to tracking the progression of the tasks, Gantt charts can also be used for tracking the utilization of the resources in the project. These resources can be human resources as well as materials used.Gantt chart was invented by a mechanical engineer named Henry Gantt in 1910. Since the invention, Gantt chart has come a long way. By today, it takes different forms from simple paper based charts to sophisticated software packages.



Advantages of Gantt Charts.
It creates a picture of complexity. I am quite a fan of diagrams and charts. We think in pictures. Therefore, if we can see complex ideas as a picture, this will help our understanding.
It organises your thoughts. I am also a big fan of the concept of dividing and conquering. A big problem is conquered by dividing it into component parts. A Gantt chart will force you to do this.

It demonstrates that you know what you’re doing. When you produce a nicely presented Gantt chart with high level tasks properly organised and resources allocated to those tasks, it speaks volumes about whether you are on top of the needs of the project and whether the project will be successful.
It (should) help you to set realistic time frames. The bars on the chart indicate in which period a particular task or set of tasks will be completed. This can help you to get things in perspective properly. And when you do this, make sure that you think about events in your organisation that have nothing to do with this project that might consume resources and time.
It can be highly visible. It can be useful to place the chart, or a large version of it, where everyone can see it. This helps to remind people of the objectives and when certain things are going to happen. It is useful if everyone in your enterprise can have a basic level of understanding of what is happening with the project even if they may not be directly involved with it.

Disadvantages of Gantt Charts.
They can become extraordinarily complex. Except for the most simple projects, there will be large numbers of tasks undertaken and resources employed to complete the project. There are some very good software programs that can cope with all this complexity (e.g. Microsoft Project). However, when the project gets to this level, it must be managed by a small number of people (perhaps one) who manages all of the details. Sometimes this does not work so well in a business that is not used to this type of management. Big businesses will frequently employ one or more project managers who are very skilled in this. For a range of reasons, this may not work so well in a smaller enterprise.
The size of the bar does not indicate the amount of work. Each bar on the chart indicates the time period over which a particular set of tasks will be completed. However, by looking at the bar for a particular set of tasks, you cannot tell what level of resources are required to achieve those tasks. So, a short bar might take 500 man hours while a longer bar may only take 20 man hours. The longer bar may indicate to the uninformed that it is a bigger task, when in fact it is not.
They need to be constantly updated. As you get into a project, things will change. If you’re going to use a Gantt chart you must have the ability to change the chart easily and frequently. If you don’t do this, it will be ignored. Again, you will probably need software to do this unless you’re keeping your project management at a high level.
Difficult to see on one sheet of paper. The software products that produce these charts need to be viewed on a computer screen, usually in segments, to be able to see the whole project. It then becomes difficult to show the details of the plan to an audience. Further, you can print out the chart, but this will normally entail quite a large “cut and paste” exercise. If you are going to do this frequently, it can be very time-consuming.

Using a Gantt chart is a tried and true method of managing a project. If you haven’t used a project methodology before, you might like to start with this one.







Q. A project has been defined to contain the following list of activities along with their required times for completion

Ans: 
 

 

 

Q. Differentiate between ISO 9001 & SEI-CMM.
Ans: The Capability Maturity Model for Software (CMM), developed by the Software Engineering Institute, and the ISO 9000 series of standards, developed by the International Standards Organization, share a common concern with quality and process management. The two are driven by similar concerns and intuitively correlated. The purpose of this report is to contrast the CMM and ISO 9001, showing both their differences and their similarities. The results of the analysis indicate that, although an ISO 9001-compliant organization would not necessarily satisfy all of the level 2 key process areas, it would satisfy most of the level 2 goals and many level 3 goals. Because there are practices in the CMM that are not addressed in ISO 9000, it is possible for a level 1 organization to receive 9001 registration; similarly, there are areas addressed by ISO 9001 that are not addressed in the CMM. A level 3 organization would have little difficulty in obtaining ISO 9001 certification, and a level 2 organization would have significant advantages in obtaining certification.

There are many differences between CMMI and ISO. Some of them are given below:
A. 1st Difference (CMMI VS ISO)
CMMI has been developed by Software Engineering Institute. It’s an improvement of the previous CMM model. The basic use of CMM model was to determine whether the software intensive systems are mature enough or not. CMMI V 1.3 is the most recent version which has been released on November 1, 2010. CMMI addressed three different areas :
·           Development (CMMI-DEV)
·           Services (CMMI-SVC)
·           Acquisition (CMMI-ACQ)
For example, CMMI-DEV is used for checking the organizational maturity in development process by making a comparison with some best industry practices available.
ISO belongs to a family of quality management standards. These standards have been developed by International Organization for Standardization (ISO). There are different standards of ISO for different things and there is change in specification of ISO with time.
B. 2nd Difference (Conceptual Difference)
The main difference between CMMI and ISO is the conceptual difference.
CMMI is referred to as process model. On the other hand, ISO is referred to as an audit standard. In CMMI, different organizations can get rating from level 1 to level 5 depending upon the maturity of processes defined in every process level. ISO is a certification tool and one organization can get this certification after confirming some standards.
C. 3rd Difference (Scope Difference)
There is also scope difference between CMMI and ISO. CMMI is considered only to improve businesses related to software industry. Main focuses of CMMI are on project management and other engineering disciplines. There are 22 process areas in CMMI (V1.2) and organizations can select any process area relevant to organization’s own need. ISO is generic in nature. ISO is very flexible and can be implemented in any manufacturing industry. ISO certification requirements are same for all organizations and industries.
D. 4th Difference (Approach Difference)
There is requirement in the CMMI for an organization to adopt ingraining processes. The main purpose of this adoption is that all processes can become the part of the organizational culture and these processes can’t be affected with pressure of deadlines as well. There are also organized and technical disciplines in CMMI for managing risk. There was a neutral approach in ISO for risk management before ISO 31000:2009. This ISO standard now provides some general guidelines for risk management.
CMMI links processes to different business goals for getting maturity and ISO gives emphasis to customer satisfaction.
E. 5th Difference (Implementation Difference)
For implementation, CMMI makes a comparison between existing processes and industrial best practices [11]. On the other end, ISO makes an adjustment between existing processes and specific ISO requirements.
Figure 3. ISO 9000 Approach [13]
ISO is very cheaper than CMMI. CMMI is more expensive because there are very minimum chances of misuse and all details need to be fulfilled.






Q. Differentiate between black box and white box testing techniques.
Ans: A simple difference between Black Box Testing and WhiteBox Testing
Black Box testing is also known as behavioral or closed box testing. It is a software testing technique in which the internal workings of the item to be tested are not known to the tester or they are not taken into consideration.
White Box Testing is also known as structural, open box, clear box or glass box testing. It is a software testing technique in which an explicit knowledge of the internal workings of the item to be tested is tested.

White box testing:

·           White box testing is done by the Developers. This requires knowledge of the internal coding of the software.
·           White box testing is concerned with testing the implementation of the program. The intent of this testing is not to exercise all the different input or output conditions, but to exercise different programming structures and data structures used in the program. It is commonly called structural testing.
·           White box testing mainly applicable to lower levels of testing: Unit testing and Integration Testing.
·           Implementation knowledge is required for white box testing.


Black box testing:

·           Black box testing is done by the professional testing team. This does not require knowledge of internal coding of the application. Testing the application against the functionality of the application without the knowledge of internal coding of the software.
·           In Black box testing the structure of the program is not considered. Test cases are decided solely on the basis of the requirements or specification of the program or module.
·           Black box testing mainly applicable to higher levels of testing: Acceptance Testing and System Testing.
·           Implementation knowledge is not required for black box testing.
                                            
Q. Explain Business Process Reengineering.
Ans: Business process reengineering (BPR) is the analysis and redesign of workflow within and between enterprises.
BPR reached its heyday in the early 1990's when Michael Hammer and James Champy published their best-selling book, "Reengineering the Corporation". The authors promoted the idea that sometimes radical redesign and reorganization of an enterprise (wiping the slate clean) was necessary to lower costs and increase quality of service and that information technology was the key enabler for that radical change.
Hammer and Champy felt that the design of workflow in most large corporations was based on assumptions about technology, people, and organizational goals that were no longer valid. They suggested seven principles of reengineering to streamline the work process and thereby achieve significant levels of improvement in quality, time management, and cost:

1. Organize around outcomes, not tasks.
2. Identify all the processes in an organization and prioritize them in order of redesign urgency.
3. Integrate information processing work into the real work that produces the information.
4. Treat geographically dispersed resources as though they were centralized.
5. Link parallel activities in the workflow instead of just integrating their results.
6. Put the decision point where the work is performed, and build control into the process.
7. Capture information once and at the source.

By the mid-1990's, BPR gained the reputation of being a nice way of saying "downsizing." According to Hammer, lack of sustained management commitment and leadership, unrealistic scope and expectations and resistance to change prompted management to abandon the concept of BPR and embrace the next new methodology, enterprise resource planning (ERP).

Everything a company does is either an ad-hoc activity, or part of a process.   Ad-hoc activities are often inefficient, and where similar activities occur often, there may be scope for turning them into a more manageable and efficient business process.
Business Process Reengineering, ideally, is when organizations start with a clean slate, and draw up those processes that would best enable them to carry out their business.   The organisation then runs a transformation programme, managed by a professional Programme Manager to transition from its current state, to the new model.   The transformation programme is likely to consist of a number of projects, each managed by a professional Project Manager.   Sometimes, the Business Process Reengineering may be more limited in scope, perhaps concentrating on one or two inefficient business processes.
Business process reengineering is also known as BPR, Business Process Redesign, Business Transformation, or Business Process Change Management.   Reengineering is a fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in cost, quality, speed, and service.   BPR combines a strategy of promoting business innovation with a strategy of making major improvements to business processes so that a company can become a much stronger and more successful competitor in the marketplace.
An important theme of Business Process Reengineering, is to remove 'silo thinking', where tasks are inefficiently handed over from one department to another.   Instead, tasks are joined up into processes that run across the organisation, often using multi-disciplinary teams.

The role of Information Technology in Business Process Re-engineering
Information Technology plays a strong role, applications that support Business Process Reengineering include work-flow, groupware, collaborative systems, enterprise resource planning, supply chain management, and customer relationship management.

The Business Process Re-engineering cycle
Business Process Reengineering is not conceived as a one off activity, but an ongoing activity, continuously renewing the enterprise.   A sufficient time interval between each iteration is needed to learn from the processes, and to recoup the investment.   The optimum length of the interval depends on factors such as the level of investment, and the anticipated benefit from each iteration.

No comments:

Post a Comment