Recommended
More Related Content
Similar to Managing software development
Similar to Managing software development (20)
Managing software development
- 1. Managing Software DevelopmentPiVoT Shelley Brown 30th June 2010
- 2. FACT Most software projects fail. In fact, the Standish group reports that over 80% of projects are unsuccessful either because they are over budget, late, missing function, or a combination. Moreover, 30% of software projects are so poorly executed that they are cancelled before completion
- 3. Definition of Software Development? Act of working to produce software Purpose: Meet specific needs of a specific client or business Using techniques (Waterfall vs Agile) Providing structured methods Source : Wikipedia
- 4. Software Development Lifecycle Initiation & Planning Requirements & Analysis Design Build & Code Testing Maintenance
- 5. Initiation & Planning Identify a Need Business Case Funding
- 6. Kervin Pillay : ‘Pivot would be the single provisioning interface for all FMC related config i.e. Broadsoft, Mind, Acme, Siebel, Oracle, SMS provisioning, Version control, client patches and upgrades’ Khetan Gajjar: ‘Pivot would be the single portal to capture, create, update & maintain corporate and end user information whilst configuring the different IS portals.’
- 7. How?
- 8. Requirements & Analysis Define Requirements Expand on PiVoT MMPS Integration 3rd Party Access Allocate Resources
- 9. Design Transformation of requirement to System Design Timescales Change Management Rules of Engagement Price
- 11. Build & Code Converts Design into complete information system Installing systems environments Testing databases Test Case procedures Coding
- 12. Testing Does the system developed match the requirements Test cases drawn up and done
- 14. Maintenance Data Clean up Set up Users Ongoing Maintenance
- 15. Lessons Learnt!! Access Communication System Understanding System Testing Project Management
- 16. How we did it better – Phase 2 Scoping One Point of Contact Project Team Escalation procedure Relationship
- 17. A New Challenge? Prepaid FMC Evaluation Understanding 6 Weeks – On Time – BELOW Budget Scoping Acceptance Development Testing
- 18. My tips Keep things Simple Leave it to the experts Cover yourself Accountability Communication Channels Escalation Procedure
Editor's Notes
- Today I am going to talk to you about my experience managing a software development projectThe issues I faced and the lessons learntI am also going to talk about some research I have done that will give my and you some tips in future development campaignsI chose this picture as a starting point because when I embarked on our PiVoT project it was Chinese to meI started working with people I didn't know, The people I did work with had a very negative attitude towards, Nihilent.
- So what is Software developmentWell its pretty simple – the act of working to produce softwareFor the purpose of eitherMeeting a need for a business or client (this is what PiVoT was designed for in our case)The perceived need of potential usersPersonal use
- So I hopped on the web and searched for Software development management!And it comes back to a process and a lifecycle like most thingsSo we start with a simple structure – there are more parts to this cycle but I have used the ones relevant to my project
- When somebody decides that there is a need for a specific software to do a specific role.In the instance of PiVoT this was Kervin & KethanPivot would be the single provisioning interface for all FMC related config i.e. Broadsoft, Mind, Acme, Siebel, Oracle, SMS provisioning, Version control, client patches and upgradesBecause of the complexities and many different systems IS has to provision a user, they thought it best to develop a web enabled platform that allows the information required to provision 3 different systems for VoIS mobile to happen at one attempt.
- Planning : or Scoping Session, This is where all parties involved come together to put together a project management plan. Bear in MIND – PiVoT was already built – to initially run in line with the mobile application Arecibo and this one platform would cover the entire provisioning process end to end. Our scope was to Integrate with MMPS, provide access for 3rd Party’s to provisionResources were allocated in different departments – MIND, BroadSoft, MMPS and engagement model defined with responsibility HierarchyNihilent then given the required information then outlined a scope of work with a design of the system which was accepted by IS
- What we required is then transformed into a system design.Within this design > process flows are outlined. Specific protocols and system standards are agreed upon as well as programming languageIn the case of PiVoT – LDAP , SOAP and XML were decided upon. The initial platform didnt cater for SOAP for MIND and therefore the XML’s (these are the lines of code that perform the action we require) needed to be changed to matched the protocol requirementsWithin this design
- Based on the scoping document and provided the design is agreed upon the developers build / code the software itself. This
- Testing is done by the users and technical people using the systemTest cases are put together to test each and every function within a software development programIn the case of PiVoT: Nihilent did systems testing offsite but they didnt have any direct access into the BroadSoft & MIND Platforms so their testing produced false results. When they came over here they spent alot of time fixing code that should have been completed in the build and code stage which delayed our testing. I have read up on Software development techniques and the one we should have followed in Phase 1 is Rapid Application Development. – this is where a software platform is built within 90days and testing is done on an ongoing basis.
- In Phase 2 – scoping session done with the right ppl. Systems and lines of communications were clearPhase 2 was done with no escalationsNihilent kept the same people on the project who understood our sustemsAlthough one area (BroadSoft SOAP) wasnt completed, we knew why not and which party was responsible
- Prepaid: was developed by Nihilent -
- I have read up on information which gives me textbook type processes and procedures. But not once during this development did I have to go to a text book and read up on how I should do it.Common sense prevails in some cases, but I would like to leave you with some tips that I think you should adhere to when developing a solutions whatever it may be, Kiss – for the prepaid scenario – i scoped the solution based on a diagram which everyone understood. Leave it to the experts – In the first phase I got too involved in the technical in and outs and how something should work – In the other phases – I stated what i wanted and let the ‘techies’ get on with it. As long as the end result is what you wanted keep that goal in MINDCover your ass : ensure that requirements & requests are always followed up by emails. (Thanks Justin)When you have conference calls and a point is agreed – follow up with an email and if necessary get everyone to agreeAccountability – A big lesson I learnt here – I may be the person who is ultimately accountable for the project however, but there are things out of my control that I dont understand – so why should I be accountable – In the case of PiVot – there were many different ppl involved and by getting them to sign off their piece made them accountable and they paid attention. A Happy Team – everyone needs to strive towards the same goal and if one person is not on the same wavelength as the rest – problems and delays occure – In Ph 1 – I wasnt happy – Nihilent werent happy and it caused friction. Have a mediation or forum to air grievances and get back on trackEscalation procedure – This doesnt seem important at first but it is good to outline at the beginning – everyone thinks that there wont be issues and ‘of course you will attend to it when a problem occurs’ but this never happens. In ph1 we had to have a meeting which got a bit messy – in phase 2 we outlined from the start – if something wasnt happening and we were holding up the process – stop development – we outlined the worse case scenarios and actions each party had to adhere to before we even started. And no escalations occured!