Software Development Life Cycle

Transcription

1 Software Development Life Cycle Author : harvix-distrogmail-com When people are asked to define the SDLC (Software Development Life Cycle), they often come up with something like the following: 1. Planning 2. Requirement analysis 3. Design 4. Implementation & Coding 5. Testing 6. Deployment 7. Maintenance What they are, in fact, describing is the Waterfall method. The Waterfall method comes from Civil Engineering. The reason was, at the time, there was no formal method for Software development. The Waterfall method only allows you to return to the previous step. This is because in the Construction industry you can only go back one step. Yet in most software development you can return to any step. Consider the building of a tower block. When building a tower block you cannot change your mind half-way through the build. Even so, Waterfall may work where you need defined steps. Especially when working in a hostile environment. NASA considered this in As a result NASA adapted the Waterfall model to an 8 stage process with lots and lots of testing throughout. The thinking being that you must get each stage right. In Space there is little opportunity to make changes. When is Waterfall appropriate? When you cannot afford to make a mistake and you're rich. Change Waterfall to be less suitable to civil engineering. Instead, make it more appropriate to software production. An evolving method Competition forced Software to evolve away from the Waterfall model. This led to more time efficient methods such as the Spiral Method. An adaption allowing the developer to go back more than one step. 1 / 7

2 Again, competition over development time led to Rapid Application Development aka RAD. RAD relies on constant user feedback throughout the development cycle. Some criticised RAD. They believed it may result in sub-optimal designs. They believed that users may push the software design in a direction that is not optimal. The most important consideration is providing the customer with a usable product. A product that fits their requirements and not the software vendors. Agile Many promote Agile as a modern software method. But, those that do promote the Agile method are wrong. Agile is not a method but a set of principles and values. Thus anyone can create a software development process as 'Agile'. Provided it adheres to the values and principles of the Agile manifesto. The following is the Agile manifesto. The stuff on the right is important but the stuff on the left i.e. before the 'over' is much more important: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The Principles behind the Agile Manifesto: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 2 / 7

3 Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity - the art of maximizing the amount of work not done is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. One of the drivers behind Agile is the myth of the 'man-month'. This myth states that if it takes one man 6 months to complete a task then 6 men can complete the same task in one month. This is never the case. Instead, identify the optimal amount of people working on a task to complete it in the fastest time. Agile promotes small software teams, regular increments and constant communication. Communication should occur between team and customer. Another point worth mentioned is that in an Agile team, the manager reports to the team - not the other way around. Why? Because this promotes self-organising teams where 'many heads are better than one'. Agile also promotes a non-rigid approach where one method does not rule over them all. For example, I worked on a team that started as pure SCRUM but then evolved to alter the scrum board for a KANBAN board. Later, for those that wanted, pairs programming (EXTREME PROGRAMMING) was introduced. This kept the whole process fluid and reactive to provide an optimal environment that produced regular working software fast. Throughout the process one part of the team was constantly testing and bug hunting to ensure every release was capable and secure. This constant testing is also refereed to as TDD (Test Driven Development). So to sum up, 'Agile' working is to utilise small self-organising teams that constantly communicate in a non-rigid environment to produce working software at short regular intervals in a test driven environment. Many large vendors have developed their own methods, many of which follow the spirit of Agile: Microsoft software development process created in 1997 produced a 4 phased procedure. This consisting of Planning, Development, Stabalization (testing) and Daily builds. Continuous customer feedback throughout. Facebook involves testing new features against a small subset of users. Teams develop new features. This include daily small features with Tuesday being big push feature day. Google gets everyone in the team, including the Managers, to get their hands dirty coding. Their process involves no deadline, no specific method. Instead, they give Developers a priority 3 / 7

4 queue of tasks. Peers will do code review before deployment. Linux, VALVe and Github also have very different programming methodologies. Yet whatever the method they have developed, it's definitely not Waterfall! SCRUM Lets look at one method that sits under Agile e.g. SCRUM. SCRUM involves a small team that follows an iterative process called sprints. It is a streamlined approach that is time boxed i.e. work by time not by feature and is very collaborative. The Client needs to be responsive and available. Why? Because SCRUM involves constant communication between the SCRUM team and the client. For large projects, divide the project up with each part handled by a different SCRUM team. Each team has a Project Manager known as the Scrum Master. All SCRUM masters must meet and communicate at regular times. This is to ensure full visibility throughout the project life cycle. The initial part of SCRUM is identifying the the User Stories. Collect user stories or narratives to create the requirements. A User Story is like this: "As a (describe your role), I want (detail the feature you want), so that (describe the benefit produced as a consequence of the feature)". Collect these User Stories together to form the product backlog. The role positioned before the Scrum Master is the Product Owner. Often the Product Owner sits between the Client and the Scrum Master/Team. To reflect User Stories, the Product Owner creates the Product Backlog. The Product Owner sets the direction of the Project. Whereas the Scrum Master facilitates the needs of the team. Note, Scrum Masters report to the team and not the other way around. The Scrum Master facilitates the the Release Planning aka the Sprints. For the Sprint, the team takes the backlog and decide which backlog features they wish to include. Next they estimate the time required to complete each User Story. Remember User Story and feature are the same. Where necessary, break User Stories into more usable chunks. Estimate the total Project time by adding together the individual User Story times. Note, this is still an estimate. It may be necessary to lose, add or replace Features; remembering you need to stay 'Agile'! The SCRUM team itself will generally consist of coders and testers and often not more than 10. This includes the Scrum Master and Product Owner. Sprints tend to be about 2 weeks but can be as short as 1 day or as long as a few months. That said, the priority of Agile working is to keep release times as short as possible. For clarification, refer to the the Agile manifesto. Another task for the Scrum Master is to create the 'Burn Down' chart. To reiterate, User Stories become the product backlog, which are then prioritised. Give a time estimate to each User Story and divide the User Stories into sprints. The time, in hours, for the User Stories within a specific sprint are all added together. This total time forms the first vertical bar above the x-axis. In other words, the bar represents the total time (hours) for the sprint. This sets the height for the y-axis. Over time the bars should get shorter. This indicates completed code necessary to create a Feature. Time is all the days that make up the sprint and each day is one increment long the x- axis. The Burn Down chart is a tool used to track the progress of the Sprint. As the Sprint progresses, the Scrum Master can calculate the slope of the chart. This slope will predict the 4 / 7

5 completion time for the Sprint. This slope will assist the Scrum Master to see whether the Sprint is ahead or behind schedule. To bring the Sprint back on schedule, the Scrum master and team will need to make changes. To keep the Sprint timely, it may be necessary to remove a user story and add it to the next sprint. To be clear, construct a burn down chart like so: Y-axis = Work remaining in hours; X-axis = days. Another important feature of Scrum is the SCRUM BOARD. These Scrum boards follow many variations but generally consist of 3 or more columns. For example: Column 1 = Backlog; Column 2 = Doing (current coding); Column 3 = Testing; Column 4 = Done. Write Each task/user Story on a card or post-it-note. Place the task on the front and the persons working on the task and on the rear with a brief summary of the task/user Story. So, all tasks start in the Backlog and make their way across the board to the Done or completed column. A separate area or column is sometimes created to reflect Blockers. A Blocker indicates when coding has stopped due to something out of the teams control. For example waiting for a specific piece of equipment. Especially if the feature relies on this equipment. It is good practice to ensure that senior management attend, at least once a week, the Daily Stand-up. Bring transparency and inform management of the Blockers. Management can now take ownership of the Blockers. This brings us to the other important feature of SCRUM. The 'Daily Stand-up'. The Daily Standup does follow rules: Rule 1. It must done every day. Rule 2. It must occur at exactly the same time. Rule 3. Everyone must speak without exception. Rule 4. Daily Stand-up must never take more than 15 minutes. Those that have a lot to say about a particular problem/point/question, let them take it 'offline'. Rule 5. Everyone stands (Why? because people tend to witter less when standing). Each person must states three things: 5 / 7

6 1. What they did yesterday. 2. What they intend to do today. 3. Any foreseen impediments (Blockers). Put Blockers to the team and take immediate answers or solutions 'off-line'. The Daily Stand-up is often chaired by the Scrum Master who 'works the board'. Working the board involves starting on the Right and working towards the Left. This is the point where cards are also moved e.g. from Testing to Done. The Scrum Master does not have to chair the Daily Stand-up. Why? Because the Daily Stand-up must always happen. After the Sprint, conduct a Retrospective meeting. Discuss what went well, what didn't and what you would have done different. To sum up, SCRUM consists of three 'ceremonies':? 1. Sprint Planning.? 2. Daily stand-up.? 3. Retrospective post sprint & Sprint review (showcase after the final sprint). As already mentioned, many choose to change and bring in different methodologies. For example, changing a Scrum board for a Kanban board. Scrum and Kanban boards are similar. The main difference is a Kanban board has a limit to the amount of tasks in each column. One way to achieve this may be to create a Kanban board with space for only 5 post-it-notes in each column. Kanban stand-ups tend to focus on Blockers and what moves across the board. But whatever method, or mix of methods, you follow is up to you. As long as it follows the values and principles of Agile. So why do Waterfall projects often fail? Requirements Analysis. This is where most projects will fail to produce usable and efficient software for the end user. Why? Because they often collect user requirements from management and not end users. In short they do not collect 'user stories'. For example, management given a monthly report with specific statistics. The completed report/stats are taken as the 'requirements'. Yet, management are often ignorant on how the end-users compile, or create, the report. This results in a 'new' software product. In reality, this 'new' software hinders the end-user from producing the required reports. A common gripe being, 'the previous product was better!' Remember, if waterfall is the method used, you can only return one step. So if a user requirements change at the coding stage then it is too late! Trying to capture all user requirements often results in a further consequence. It will often produce a complicated and crowded user interface. This results in further time and money spent on training users on how to 6 / 7

7 Powered by TCPDF ( HarvixDesign use the 'new' product. Understand this, the whole waterfall process is slow, rigid and expensive. Ironically, software firms now complain that 'Clients' (Project Managers responsible for contracting in software development) shy away buying their services. Why is this? 'Clients' are too scared to be the one held responsible for hiring the firm that led to the Project failing. A classic example is the multi-billion pound failure to upgrade the NHS patient record system (2013). For more insight into Agile over Waterfall in the context of the NHS, I recommend the following article: So why do these firms try to persuade Clients that their (Waterfall) method is best? Money! It pays to get a contract that goes on and on for years. It is not in the interest of the Software developing contractor to get things done too fast. Looking for new contracts takes time and time costs money. After reading the article in the link above, consider the following question. Is it a sad state of affairs when Doctors, Nurses and NHS staff are having to write computer code? It also appears that NHS staff are writing more efficient code, on time, at much reduced cost. What's next, Police officers writing code? So unless you are sending Rockets to the moon, move away from the Waterfall method. Consider embracing Agile. Recall that no Project is 'too large' for Agile. 7 / 7