Business Case Project Report

Business case analysis and recommendations
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
    The Quality Software Solutions Case   i Table of Contents Page  A. Background 1 B. Issues and Problems 2 C. Alternative Courses of Action 3 D. Recommendations 4 E. Implementation Steps   4   1 The Quality Software Solutions Case A. Background Quality Software Solutions (QSS) is a small software development organisation involved in the design and development of library information systems. It was founded in the early 1990s and enjoyed some success and expansion, doubling its staff from 15 to 30 personnel between 1995 and 1998, with plans to recruit additional software developers. Early in 2001, as a direct result of the slump in the software development industry, QSS was forced to retire 10 of its employees. Since then however, the company has been able to nurture and grow its customer base. Because of this, QSS hired 15 staff on a contract basis.  At this time, QSS plans to recruit an additional 15 software developers, some of which may be on a permanent basis. The majority of these new hires are expected to have relevant experience, also it is also planned to recruit a number of recent graduates. QSS approach to project execution The company is made up of three project teams; each one devoted to a separate subsystem of the product. An independent test team has recently been formed. Success in meeting deadlines and delivering quality product has been mainly due to the commitment and experience of a core group of staff who have been with the company since its inception. Developments during the last four months Development during the last four months had a major impact on the operations of QSS. These developments include:   The resignation of two experienced project managers, who were both on contract, for permanent positions elsewhere.   The pirating by other companies of five skilled QSS software developers for specialist development roles. Experience with Version 3.0 of the Library Orders Subsystem The development of version 3.0 of the Library Orders Subsystem encountered the following difficulties:   2   There was an overrun of three months. Team members had to work an average of 16 hours each week just to finish their work.   There is no record of actual time spent by staff in each activity. B. Issues and Problems 1. Responsibility for the quality of the work done by the three teams responsible for creating the library information system is limited not to the entire project but to the subsystem that they are assigned to handle. While this assembly line approach has its merits, team members do not have the opportunity to gain the experience of handling all aspects of software development. Thus, when a resignation occurs, a gap is created, forcing inexperienced staff to fill a position that he is ill-prepared to handle. 2. There is no clear career path defined for each staff. It is possible for a staff to be promoted to a higher position even without the necessary requisite training on project management. An example of this scenario is the assignment of a team leader who has very little previous exposure in project management to the handle the position of project manager because the incumbent manager suddenly resigned. 3. Roles and responsibilities are not clearly defined for project activities. As a result, two significant activities were forgotten until near the end of the project. Five people had to give up their weekend to complete these activities. 4. There appears to be no guide for team members to follow to handle and manage projects. Indicators of this problem are as follows: - A company template for software requirements was never used, because new staff were unaware of its existence. - A number of requirements that were identified during the requirements phase were never implemented, as they were omitted in error during software design. - During system testing, it was identified that an incorrect version of software had been tested. The correct version was re-tested, delaying the project by two days. - An error which had been found in Version 2.0, but fixed in Version 2.1 and subsequent versions, reappeared during early testing of Version 3.0. This was quickly rectified. - Just before release, a significant error was found and tracked to a particular module. The person who developed that module had not used the coding standards, and had left the company 4 months earlier. It took two developers 2 days to correct the problem, and a further day to re-test the module. - An incorrect version of software was shipped to one customer, causing considerable embarrassment.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks