Implementing Software Development Project Management Best Practices - Essay Example

Mobile Computing Software Development Strategies Affiliation] Executive Summary Of Best Software Development Practice In The Context Of Mobile Computing 1. Streamlining The Software Development Process When considering streamlining the software development process, the first thing to be considered is the chief goals to be achieved. These are fourfold : to successfully develop, test, deploy and maintain software systems. Therefore, the software development process must best implement these four goals. All the chief features that the software development process must follow in order to achieve these four goals are fully described within Somerville [Software Engineering. Ian Sommerville. Fifth Edition. Addison-Wesley 1996. Hardback. ISBN 0-201-42765-6]. Somerville [1996 - Page 7] explains that successful software development, deployment, testing, deployment and maintenance are all built around four basic precepts : software specification, software development, software validation and software evolution. The obvious way of streamlining the software development process is to make these discrete stages flow into one another in a seamless end-to-end process. This requires, in practice, that the specific methods adopted for Rapid Application Development (RAD) (see (2) below) must be adopted, in order to avoid the hold-ups that always occur when discrete documents have to be updated to take account of changes in user requirements, for example. The greatest obstacle to software development, in practice, is the ‘big bang’ approach, where all the functionality is supposed to be introduced at once(!). The consensus of the available literature is that this may be charitably described as a recipe for disaster! The best, and therefore most streamlined approach is the incremental one, where software development is carried out in a series of relatively small steps. It is therefore vital that this principle is incorporated within the contract with the client (for a bespoke development) or the vendor’s marketing and sales departments (for a market-led project) 2. Comparing & Contrasting Traditional Software Development Models Three of the most commonly used software development methods are cited below, as per Somerville [1996 - Page 8] 1. The Waterfall approach. This is where the requirements specification, design specification, test specification, implementation plan and maintenance plan are all produced in sequence as individual work products, and each is approved by the key stakeholders before the next is produced. 2. Evolutionary Development. Here, the specification, development and testing stages are interleaved, beginning with the very rapid development of a prototype system from a very basic specification. This is what us usually meant by Rapid Application Development (RAD). This prototype is then progressively defined with the aid of input from the intended users to produce a system that meets at least the initial business or scientific requirements of the latter. As an alternative, which will be particularly application to application domains such as financial services or online gaming, where close regulation will be expected. In such cases, a more structured approach must be used to produce a more robust and maintainable system. The outstanding problem here is that RAD often results in poor recording of the development process, leading not only to problems with maintaining and enhancing the system, but also severe problems with regulators! 3. System Assembly From Reusable Components. This is the process that is most often associated with Object Oriented development techniques, where libraries of modules (expressions of ‘classes’) are already available, and may be combined to achieve the requirements of the customer. 3. Risks Posed By Improper Requirements Engineering Three of the most serious risks posed by improper requirements engineering are defined by Brooks [The Mythical Man-Month. Frederick P. Brooks Jnr. Addison Wesley. October 1995. Paperback. ISBN 0-201-83595-9 - Pages 199 - 200] as, firstly, the implicit requirements of the users (which are what really make an application work well!) will not be accurately captured. To be more precise, the users do not know what they want, and it is down to the development team to draw it out of them. Secondly, the complexity of the system will be underestimated - something that always comes to light once several months’ of effort have been expended! Therefore, when conducting the analysis, ensure that all the practicable ramifications of the system have been agreed with the customer. Anything else will form part of the post-deployment enhancement package(s). Thirdly, developing the wrong prototype! It is now the custom, as part of the requirements management process, particularly when large bespoke developments are under negotiation, for a series of prototypes to be developed by the team in conjunction with customer representatives. Not pausing to take the closest notice of what the client’s people are saying will send the development team down a completely wrong path, which will, at the very least, lead to the loss of the contract(!). 4. Software Project Management Plan All software development projects., which will apply to mobile computing applications (as tablet computers are simply another technology platform for the software application) at least as much to any other technology, must, as a matter of best practice, follow the following fundamental stages. Somerville [1996 - Pages 30- 36] identified these stages as follows. System Requirements Definition System Design Sub-system Development System Integration System Installation System Operation System evolution (both in terms of ‘bug fixes’ and enhancements) System Decommissioning (often forgotten, but essential if the data set is to be successfully transferred to the successor application) Although the body of academic material does not articulate it, it is critically important to the success of the project that the project management plan is an integral part of the formal proposal and Bid to a potential client (for a bespoke IT solution project) or the agreement with the vendor’s marketing and sales departments (for a market-led package). To be more specific, the System Requirements Definition and the System Design must be part of the Contract, in order that the agreement between the development team and the customer, that is contractually (and therefore legally withy respect to an external party) enforceable, in order that the development process may not be ruined (there is no other way to describe it!) by constantly changing requirements. 5. Software Project Management Best Practices Three good examples of software project management best practices are given in Brooks [1995 Pages 73-75]. To begin with, the team must communicate. Brooks defines this in terms of means : informally, in terms of (in current terms) good email service (which also provides a precise record not present in Brook’s day) and inter-group dependencies, in order to encourage the common interpretation of the key requirements and design documents on which the whole project depends. Secondly, regular project meetings, often twice a day (what are sometimes called ‘morning and evening prayers’) to catch and remedy the inevitable minor misunderstandings that, together, can wreck a project - as a Chess player might put it, the Von Steinitz Principle cuts both ways! Thirdly, compile and maintain a Project Workbook. Brooks defines this as the key project repository of, objectives, external specifications, interface specifications of all kinds, technical standards, internal specifications and administrative documents fo all kinds. This will be an electronic repository in current terms, but must still be maintained, a task made far easier by modern Configuration Management System (CMS) packages. References Software Engineering. Ian Sommerville. Fifth Edition. Addison-Wesley 1996. Hardback. ISBN 0-201-42765-6. The Mythical Man-Month. Frederick P. Brooks Jnr. Addison Wesley. October 1995. Paperback. ISBN 0-201-83595-9 Further Reading Software Requirements : Objects, Functions and States. Alan M. Davis. Prentice Hall International Editions. 1993. Paperback. ISBN 0-13-562174-7 Read More