ASSIGNMENT 01 Software Project Management NOVEMBER 8, 2022 AQEEL ZAFFAR UW-19-CS-BS-001 Table of Contents 1. Lightweight Software Development .................................................................................................. 2 Introduction ................................................................................................................................................. 2 2. 1.1 Scrum (1995)................................................................................................................................ 2 1.2 Crystal Clear ............................................................................................................................... 4 1.3 Extreme Programming (1996) ................................................................................................... 6 1.4 Adaptive Software Development ............................................................................................... 8 1.5 Feature-Driven Software Development..................................................................................... 9 1.6 Dynamic Systems Development Methods (1995) .................................................................... 11 Which Software process model is suitable for which environment? ............................................ 13 1. Lightweight Software Development Introduction Lightweight processes are beginning to replace more formal methods. The motivation for this transition is based on many factors. The Internet, time to market, cost reduction, quality increases, market pressures, as well as the popularization of these programming methods. This series of articles will investigate the various lightweight methods, their impact on the management of software development projects, and the processes by which managers can determine the appropriateness and usefulness of the various processes. The definition of a lightweight Process is more difficult than it would first appear. A lightweight methodology is a software development method that has only a few rules and practices, or only ones that are easy to follow. Examples of lightweight methodologies include1: Adaptive Software Development by Jim Highsmith, described in his 1999 book Adaptive Software Development. Crystal Clear family of methodologies with Alistair Cockburn. Extreme Programming (XP), promoted by people such as Kent Beck and Martin Fowler. Feature Driven Development (FDD) developed (1999) by Jeff De Luca and Peter Coad. ICONIX process, developed by Doug Rosenberg: An UML Use Case driven approach that purports to provide just enough documentation and structure to the process to allow flexibility, yet produce software that meets user and business requirements. 1.1 Scrum (1995) Scrum is an agile project management methodology involving a small team led by a Scrum master, whose main job is to remove all obstacles to getting work done. Work is done in short cycles called sprints, and the team meets daily to discuss current tasks and any roadblocks that need clearing. Scrum is a method for managing projects that allows for rapid development and testing, especially within a small team. Scrum uses Iterative process2. Silent features of Scrum are: 1 https://en.wikipedia.org/wiki/Lightweight_methodology#:~:text=A%20lightweight%20methodology%20i s%20a,considered%20a%20%22heavyweight%20methodology%22. 2 https://www.geeksforgeeks.org/scrum-software-development/ Scrum is light-weighted framework Scrum emphasizes self-organization Scrum is simple to understand Scrum framework help the team to work together Life Cycle of Scrum a) Sprint A Sprint is a time-box of one month or less. A new Sprint starts immediately after the completion of the previous Sprint. b) Release When the product is completed then it goes to the Release stage. c) Sprint Review If the product still have some non-achievable features then it will be checked in this stage and then the product is passed to the Sprint Retrospective stage. d) Sprint Retrospective In this stage quality or status of the product is checked. e) Product Backlog According to the prioritize features the product is organized. f) Sprint Backlog Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning meeting. Advantages of using the Scrum framework Scrum framework is fast moving and money efficient. Scrum framework works by dividing the large product into small sub-products. It’s like a divide and conquer strategy In Scrum customer satisfaction is very important. Scrum is adaptive in nature because it have short sprint. As Scrum framework rely on constant feedback therefore the quality of product increases in less amount of time Disadvantage of using Scrum framework Scrum framework do not allow changes into their sprint. Scrum framework is not fully described model. If you wanna adopt it you need to fill in the framework with your own details like Extreme Programming(XP), Kanban, DSDM. It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear definition. The daily Scrum meetings and frequent reviews require substantial resources. Examples of Scrum Bill meets with a customer to discuss her company’s needs. Those needs are the product backlog. Bill chooses the most important tasks to work on in the next two weeks. His team meets in a daily scrum to target work for the day ahead and address roadblocks. At the end of the sprint, Bill delivers the work, reviews the backlog, and sets the goal for the next sprint. The cycle repeats until the software is complete. 1.2 Crystal Clear Crystal Clear focuses on people rather than processes. It is not at all prescribed and stresses flexibility. Teams using RVP, XP, or other methodologies can “borrow” useful techniques from Crystal Clear and vice versa. Crystal Clear is a book of what worked best for teams on successful projects. It describes the things that make the most difference to the success or failure of a project. Principles and Goals of Crystal Clear Crystal Clear methodology operates on a set of 7 principles, three of which are paramount and the remaining four are optional but highly advisable3. a) Frequent Delivery It is more critical to deliver working frequently, proper codes to users otherwise you may find that you provided a useless product when it is too late to make changes. b) Reflective Improvement Crystal Clear isn’t prescriptive and surrenders many things over to the team to think about them and agree after discourse. Experimentation is vital here. Thus, the team should cooperate to find out which ideas work better and how they enhance their future functioning practices. c) Osmotic Communication The team should work in the same room. Doing this enables members to gain from each other regardless of whether it is inactively and gradual. This way the project gets completed without so much structure. d) Personal Safety Members should accept and respect the ideas of one another without ridiculing or reprimanding them. The main thing here is that there should exist mutual trust within the team so that members can work through their problems and improve performance. e) Focus Project leaders should set priorities for the project and communicate them clearly to the team. Afterward, team members should be given space and time to work on their tasks without interruption. f) Easy Access to Expert Users Developers should put their software out there and listen to users feedback. They have to do this frequently so that they can use the feedback to improve their products. 3 https://www.agilest.org/scaled-agile/crystal-clear/ g) Technical Environment The project should be undertaken under suitable environment, fully equipped with automates tests, frequent integration, and effective configuration management. Examples of Crystal Clear The most popular example of the Crystal agile methodology is the development of IBM’s Orange platform, which was developed to help companies maintain compliance and security over their technological devices, such as servers, desktop computers, laptops, and mobile devices. Cockburn developed this strategy in response to the need for fast product delivery, close communication, and frequent testing, feedback, and modification. This methodology is also ideal for app development where small teams are involved. Frequent testing and user input allow teams to identify errors early on in the developmental phase, which not only helps the company save money but also speeds up the delivery time. Additionally, osmotic or close communication is crucial for this type of development process4. While Crystal agile is considered a lightweight methodology, it still requires the use of effective communication and reporting tools. 1.3 Extreme Programming (1996) Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team. XP is the most specific of the agile frameworks regarding appropriate engineering practices for software development5. The easiest way to understand XP is to think of it as Scrum with an added layer of coding best practices. XP takes agile principles, gives you some processes like Scrum, and tells you exactly how to approach coding. XP starts with an idea that software development is hard. That's why, according to XP, the 4 most important things in software development are: Extreme Programming Practices a) Small releases Finished work is delivered to the customer at the end of each week, so the customer gets value sooner rather than later. 4 5 https://monday.com/blog/project-management/agile-crystal/ https://asana.com/resources/extreme-programming-xp b) Weekly cycle The team plans what features to deliver at the end of each week, works in one-week cycles, and reviews progress each Friday. If some feature takes more time, it's broken down into several cycles. c) Quarterly cycle Because work is delivered in small releases, you need some long-term strategy to make sure stories fit together and software doesn't end up all over the place. Workflow in Extreme Programming 1.4 Adaptive Software Development ASD is a development methodology that encourages continuous learning throughout the software development project. It believes that this is the only correct way to sail through software development’s inherent complexity smoothly6. ASD Life Cycle7 a) Speculate The term plan is too deterministic and indicates a reasonably high degree of certainty about the desired result. The implicit and explicit goal of conformance to plan, restricts the manager's ability to steer the project in innovative directions. In Adaptive Software Development, the term plan is replaced by the term speculate. While speculating, the team does not abandon planning, but it acknowledges the reality of uncertainty in complex problems. Speculate encourages exploration and experimentation. Iterations with short cycles are encouraged. b) Collaborate Complex applications are not built, they evolve. Complex applications require that a large volume of information be collected, analysed, and applied to the problem. Turbulent 6 7 https://www.geeksforgeeks.org/adaptive-software-development-asd/ https://www.bacancytechnology.com/blog/adaptive-software-development environments have high rates of information flow. Hence, complex applications require that a large volume of information be collected, analysed, and applied to the problem. This results in diverse Knowledge requirements that can only be handled by team collaboration. Collaborate would require the ability to work jointly to produce results, share knowledge or make decisions. In the context of project management, Collaboration portrays a balance between managing with traditional management techniques and creating and maintaining the collaborative environment needed for emergence. c) Learn The Learn part of the Lifecycle is vital for the success of the project. Team has to enhance their knowledge constantly, using practices such as: Technical Reviews Project Retrospectives Customer Focus Groups Reviews should be done after each iteration. Both, the developers and customers examine their assumptions and use the results of each development cycle to learn the direction of the next. The team learns: About product changes More fundamental changes in underlying assumptions about how the products are being developed The iterations need to be short, so that the team can learn from small rather than large mistakes. 1.5 Feature Driven Software Development FDD stands for Feature-Driven Development. FDD was first applied in the year 1997 on a realworld application by Jeff De Luca for large software development with specific needs of 15-month and 50 persons and published as a discussion in book Java Modeling in Color with UML in the year 19998. 8 https://www.geeksforgeeks.org/fdd-full-form/ It is an agile iterative and incremental model that focuses on progressing the features of the developing software. The main motive of feature-driven development is to provide timely updated and working software to the client. In FDD, reporting and progress tracking is necessary at all levels. Feature Driven Development Life Cycle Characteristics of FDD9 a) Short iterative FDD lifecycle works in simple and short iterations to efficiently finish the work on time and gives good pace for large projects. b) Customer Focused This agile practice is totally based on inspection of each feature by client and then pushed to main build code. c) Structured and feature focused Initial activities in lifecycle builds the domain model and features list in the beginning of timeline and more than 70% of efforts are given to last 2 activities. 9 https://www.planview.com/resources/articles/fdd-agile/ d) Frequent releases Feature-driven development provides continuous releases of features in the software and retaining continuous success of the project. Advantages of FDD Reporting at all levels leads to easier progress tracking. FDD provides continuous success for larger size of teams and projects. Reduction in risks is observed as whole model and design is build in smaller segments. FDD provides greater accuracy in cost estimation of the project due to feature segmentation. Disadvantages of FDD This agile practice is not good for smaller projects. There is high dependency on lead programmers, designers and mentors. There is lack of documentation which can create an issue afterwards. 1.6 Dynamic Systems Development Methods (1995) The Dynamic Systems Development technique (DSDM) is an associate degree agile code development approach that provides a framework for building and maintaining systems. The DSDM philosophy is borrowed from a modified version of the sociologist principle 80 % of an application is often delivered in twenty percent of the time it’d desire deliver the entire (100 percent) application. DSDM is an iterative code method within which every iteration follows the 80% rule that simply enough work is needed for every increment to facilitate movement to the following increment. The remaining detail is often completed later once a lot of business necessities are noted or changes are requested and accommodated10. Dynamic Systems Development Methods Life Cycle Stages11 a) Feasibility Study It establishes the essential business necessities and constraints related to the applying to be designed then assesses whether or not the application could be a viable candidate for the DSDM method. 10 11 https://www.agilebusiness.org/business-agility/what-is-dsdm.html https://www.geeksforgeeks.org/dynamic-systems-development-method-dsdm/ b) Business Study It establishes the use and knowledge necessities that may permit the applying to supply business value; additionally, it is the essential application design and identifies the maintainability necessities for the applying. c) Functional Model Iterations It produces a collection of progressive prototypes that demonstrate practicality for the client. d) Design and build iteration It revisits prototypes designed throughout useful model iteration to make sure that everyone has been designed during a manner that may alter it to supply operational business price for finish users. e) Implementation It places the newest code increment (an “operationalized” prototype) into the operational surroundings. It ought to be noted that: the increment might not 100% complete or, changes are also requested because the increment is placed into place. In either case, DSDM development work continues by returning to the useful model iteration activity. 2. Which Software process model is suitable for which environment? There are many kinds of process models for meeting different requirements. We refer to these as SDLC models (Software Development Life Cycle models). The most popular and important SDLC models are as follows: Waterfall Model V Model Agile Model Iterative and Incremental Model Spiral Model No. Software Process Model 1 Waterfall Model Suitable Environment Simple small or mid-sized projects with clearly defined and unchanging requirements (small company website development). Projects with the need for stricter control, predictable budget and timelines (e.g., governmental projects). Projects that must adhere to multiple rules and regulations (healthcare projects). Projects where a well-known technology stack and tools are used. 2 V Model Projects where failures and downtimes are unacceptable (e.g., medical software, aviation fleet management software). 3 Agile Model Practically any startup initiatives, when end users’ early feedback is required. Most of mid-sized projects in custom software development where business requirements cannot be confidently translated to detailed software requirements. Large projects that are easy to divide into small functional parts and can be 4 Iterative and Incremental Model 6 Spiral Model developed incrementally over each iteration. Large, mission-critical enterprise applications that preferably consist of loosely coupled parts, such as micro services or web services. Projects with unclear business needs or too ambitious/innovative requirements. Projects that are large and complicated. Research and development (R&D) activity or the introduction of a new service or a product.
