Lecture
Это окончание невероятной информации про виды методологий.
...
core task must be defined, but implementation details may evolve over time.
The «Spiral Model» is similar to the incremental model, but with an emphasis on risk analysis. It works well for solving business-critical tasks, where failure is incompatible with the company's operations, for releasing new product lines, and where scientific research and practical testing are needed.
The spiral model calls for 4 stages on each loop:
This model is not suitable for small projects; it makes sense for complex and expensive ones, such as, for example, developing a document management system for a bank, where each subsequent step requires more analysis to assess the consequences than the programming itself. On the project to develop an EDMS for the Siberian Regional Dispatch Office of the Unified Energy System, two meetings about changing the classification of sections of the electronic archive take 10 times longer than a programmer merging two folders. The government projects we took part in began with the expert community preparing a costly concept, which is not always useless, since it pays for itself on a national scale.
The spiral approach is a combination of the iterative model with some controlled aspects of the waterfall method. It is focused on continuously releasing software through iterations.
The name comes from the spirals that the product typically passes through.
What's nice about the Spiral model is that, like the iterative method, it lets you test every step of the process. This way, you can be confident that you have come up with a flawless product build.
The four stages of the software development life cycle in the Spiral model are: identification, design, construction, evaluation.
This is the stage where planning and document creation actually happen. Here you will be interviewing your end users and gathering feedback.
You also list the requirements for the software you are going to build — timelines, budget estimates, features. The more detailed the software development life cycle documentation, the easier it will be for developers to build the product.
Similar to the V model, this stage involves building the system design, the architectural design, as well as designing the module.
You mainly analyze the entire development process in order to identify potential risks. Once the risks are identified, you can start brainstorming risk-mitigation strategies.
This is the stage where the software is actually developed.
By the end of this stage, developers already have a piece of software ready for deployment. Once you deploy it, you can gather feedback from the market and keep evolving.
At this stage, monitoring and observation dominate.
Here you need to evaluate how the entire spiral went. You can also see how the market reacts to your first functional piece of software.
You mainly gather feedback on what you did right and wrong. Then, on the next spiral, you double down on what was right and try to avoid what you did wrong.
The entire product build goes through a couple of spirals until the final product is developed. And, hopefully, at every stage of the spiral build you were able to adapt to market needs in order to create a product your users truly need.
Today's spiral model defines the following common set of checkpoints
Well, if the project involves some risky budget estimates, you can be sure the spiral model will minimize overruns. That's because there is constant evaluation of the product.
If thorough documentation was not created initially, it may be a good option to stick with the Spiral approach, since it allows the product to evolve along the way.
If you want to show your customers the immediate value of the product you are building, you can use the spiral model. This lets you deploy after each spiral and see how the market reacts to working software.
The spiral approach is also great for teams that are looking for constant user feedback. After each deployment, you can gather customer feedback and make adjustments.
If you expect to adopt new technologies, then the Spiral model will also suit you.
Nevertheless, it cannot withstand a strongly changing environment, which can cause the spirals to continue indefinitely.
The Scrum software development life cycle method is actually a subset of the Agile model. This means Scrum also adheres to the 12 principles of the Agile methodology.
The Scrum framework works in timeboxes called sprints. Each sprint lasts from two to four weeks. During that time the team works on delivering working software. Once the software is finished, it is deployed to the market and feedback is gathered.
There are usually three main roles in the Scrum methodology. There is the Product Owner, the Scrum Master, and the Scrum Team.
The Product Owner exchanges information with stakeholders and customers in order to come up with a great product. The Product Owner then creates the product backlog. This is where all the features that need to be developed are listed.
Then the Scrum Master reviews the product backlog and creates the sprint backlog. In the sprint backlog, each feature is broken down into smaller tasks that need to be completed throughout the sprint. These tasks are called user stories.
User stories usually show what the product looks like through the customer's eyes. And what steps the customer needs to take to complete a specific task.
It's important to note that the Scrum Master is not a manager. Each member of the Scrum team is responsible for their own tasks and must make sure they meet the product requirements.
The Scrum team is cross-functional. Since everyone is responsible for their own assignments, every team member must have a lot of experience. Team commitment is also absolutely essential, since changes will happen along the way.
The Scrum team also holds daily Scrum meetings. This is the time and place where everyone shares what they did yesterday, what they are going to do today, and whether they are facing any problems. This way, if someone is falling behind, others can get them back on track.
Each daily scrum lasts from 5 to 15 minutes.
Once the sprint is finished, a Scrum Review meeting is held, at which the work done so far is discussed. Then the Scrum team looks back at the development process and improves it based on what went right and what didn't.
The Scrum team also uses burndown charts to track progress.
What's nice about the Scrum method is that it can adapt to changes while sticking to a strict process. During a sprint it is not recommended to make changes to the backlog. However, once the sprint ends, the team can fix mistakes and add extra tasks to the backlog.
Since Scrum is part of Agile, you don't have a clear picture of the final product. The end result may differ greatly from what was originally planned.
That's because there is constant team communication, and everyone must be on the same page.
There is also constant interaction between the product and the market. This way, you can make the necessary changes to your software to meet market needs. For this you will need an experienced team of mid-level and senior developers.
Overall, Scrum is the most popular Agile methodology. Feel free to give it a try.
The XP methodology is also a subset of Agile.
It consists of 5 core components:
Simplicity
Everything should be done in the simplest way possible. There should be no more tasks and features than necessary.
The XP method supports the MVP (Minimum Viable Product) structure. It aims to develop a «good enough» product that meets market needs well.
Team Communication
The Extreme Programming system is aimed at daily face-to-face communication so that everyone is on the same page.
Effective team communication is especially important in the early stages of product development, since documentation is lacking. And yes, with the XP model you don't need to plan much initially to get your team started. But you need to communicate a lot within the team.
In XP, developers are usually the same people who also do the testing.
Customer Feedback
You also continuously release working software to see how the market reacts to it. After release, you gather feedback, assess the situation, and make the necessary changes to satisfy the customer.
Courage
Yes, courage. You and your team must be bold. This means you must have the courage to accept changes when they occur. You must have the courage to adopt new technologies when necessary. And you must have the courage to constructively accept feedback in order to create an outstanding software solution for your market's problems.
Respect
Your team members must respect one another. They must help each other. Because most of the time, a successful product is made by a strong team. You must make sure the atmosphere in your team is great. You must make sure everyone can't wait to get back to work after the weekend (that may be a bit of an exaggeration).
Overall, XP is a typical Agile methodology. You must embrace the changing environment and tailor your product to the market.
You place emphasis on team communication and constructively gathering customer feedback to make sure you are developing a real solution to market problems.
It's useful to use the XP methodology if your team is highly experienced and consists of 10 people or fewer.
In addition, if your client doesn't impose special requirements on you, the XP method will suit you well.
If the technology you're currently using lets you run automated unit and functional tests, the XP model will streamline your workflow.
And finally, if you believe there's a high risk associated with inaccurate time estimates, you can still use the XP model, since it will reduce that risk.
The Software Prototype method also consists of building working prototypes (obviously).
However, the difference here is that the Software Prototype approach only develops "just enough" prototypes. This means the prototypes may have limited capabilities.
Nevertheless, with this approach you can deliver working prototypes fairly quickly and gather user feedback rapidly.
If team management leaves something to be desired, you may end up creating prototypes that differ greatly from the originally planned software. In addition, poor management can render your prototypes unusable for future projects.
So keep in mind that this is a very delicate model. It can be an enormous help, since it quickly produces "just enough" prototypes. But it can also harm your project, since it can waste a great deal of time and money if you don't manage your team properly.
Several types of software prototyping are available:
The first is rapid prototyping . This is used to develop the functional part of the end product very quickly, and rarely more than that. This type of prototyping contains only the core functions and features the client wants.
The second type of prototyping is evolutionary . It's based on extensive user feedback. You jump straight into the fray with a quickly built prototype and adjust it along the way.
The third is called extreme prototyping . It's mainly aimed at web application development. It consists of three main components. The first is known as the static prototype. It builds a basic prototype together with all the necessary HTML pages. In the second stage, a lot of programming takes place in the chosen web environment using a simulated services layer. In the third and final stage, the prototype is deployed.
And finally, there's incremental prototyping . This stage encourages you to build several functional prototypes and then integrate them into the final product.
There are several basic stages of software prototype development, regardless of type. Here they are:
A software prototype can be developed in two ways. The first way demonstrates a broader view of the end product. It emphasizes the user interface without going deep into the internal systems.
The second way you can develop a prototype is to focus on a specific function or system. This way is more technical, since it shows what a particular function can do and exactly how it does it.
However, if your team has terrible management, you might want to skip the Software Prototyping method. That's because your team will put a lot of effort into developing a prototype that probably won't work properly.
So, if you have a very small project on your radar and want to jump right into it with virtually no upfront planning, the Big Bang method is the right choice for you.
Of course, this type of development isn't suitable for large projects where you need specific requirements to start development.
The Big Bang method is great for small groups of 5 people working on small projects lasting no more than a month.
It's also a good model to use when the client doesn't describe the instructions in detail and doesn't know what the end product should look like.
Here are the pros and cons of the Big Bang model:
It's also good to use this method with your junior developers, since it's easy to adopt.
If you don't have a clear picture of the end product, you can also use this model.
The Big Bang method isn't a good option for long-term, complex projects that require a lot of upfront planning.
Design solutions to maintain and optimize the availability and performance of services, ensuring a fantastic and reliable experience for our customers.
Care about designing and building tools and solutions to keep services healthy and responsive
Continuously improve the methods and processes used in operations to optimize costs and increase performance.
Willingness to evaluate and adopt the latest technologies emerging in the industry to keep the solution on the leading edge
Collaborate across different teams - development, quality engineering, product management, program management, etc. - to foster a genuine engineering culture for building the right systems and solutions to rapidly deliver a growing portfolio of SaaS applications, product releases, and infrastructure optimizations.
work effectively across multiple time zones to collaborate with peers in other regions.
Handle escalations from different parties - customers, customer support specialists, and engineers - resolving problems and effectively communicating status across the board.
Simple processes are becoming increasingly programmable and dynamic through the DevOps approach. DevOps seeks to maximize the predictability, efficiency, security, and maintainability of operational processes. Automation very often supports this goal
Lean software development — a software development methodology that applies the methods of the lean manufacturing concept. It emerged from the community of proponents of the agile development methodology.
It was first presented in the book of the same name (Lean Software Development) by Mary Poppendieck and Tom Poppendieck. The book presents traditional lean manufacturing principles as applied to software development, together with a set of 22 tools (practices) and a comparison with the agile development methodology. Mary and Tom took part in a number of different conferences devoted to Agile techniques, which explains the popularity of the lean manufacturing concept within the agile development community.
Some lean development practices are similar to rapid development practices, while others differ somewhat. Examples of practices:
The slide demonstrates the differences between the two most common methodologies.
In current practice, software development models come in many variations. There's no single model that's correct for every project, every set of starting conditions, and every payment model. Even Agile, which we all love so much, can't be applied everywhere, due to some clients' unreadiness for it or the impossibility of flexible financing. The methodologies partially overlap in their tools and are partly similar to one another. Some other concepts were used only to promote their own compilers and did not bring anything new into practice
Using an agile cycle is justified for large projects spread out over time, with constantly changing user requirements, as well as in other cases where precise planning isn't possible. A waterfall cycle is a good fit for small projects with clearly defined requirements and where specialists of the required qualification are available.
The degree of risk in software development varies depending on the cycle chosen. With an agile cycle, the likelihood of ending up with a poor architecture is higher, but fixing errors is easier. With a waterfall cycle, architectural flaws are discovered at the end of the project, and correcting shortcomings is significantly harder and more expensive.
| Agile cycle | Waterfall cycle |
| No detailed specification is required. | A detailed specification per the applicable standard is required. |
| At the start there's no precise understanding of the budget; the estimate is approximate. | The exact cost and timeline are specified in the contract. |
| Development can start right after the contract is signed. | Time is needed to write and agree on the technical specification. |
| It's easy to change a given implementation requirement if it's become outdated or the project vision has changed. | Changing implementation requirements requires signing an additional agreement. |
| The project cost is lower. | The project cost is higher. |
| You pay for the time actually spent. | The cost of the work includes a buffer in case of unforeseen labor costs. |
Work on Agile is generally carried out for a lower price and with finished blocks delivered in installments. A waterfall cycle implies a fixed, large payment for the final product, often without demonstrating intermediate results.
The "great" answer to this question ... is: it depends.
It depends on the size of your team, the size of the project, the complexity of the project, the experience of your developers, the tools you use, and, more importantly, your preferences.
If you believe you have an experienced development team and want to save time by avoiding documentation as much as possible, then one of the Agile models might suit you.
They're flexible and let you adapt to changing conditions. But they aren't so easy to get used to.
On the other hand, if you want everything to be clear and for everyone to know each step, then the Waterfall model or the V-model will suit you. If the team has junior developers, they can easily adapt to the Waterfall model.
But keep in mind that changes to the "Waterfall" model are either very costly or impossible.
In the end, I'd recommend you choose the one your gut tells you to. You'll have to try most of them to see which one suits you best. You rarely pick the right model the first time. So take it with a grain of salt and just choose the one that you think will suit your team right now.
All right, if you still can't decide, let's look at the software development life cycle models that other companies use, and what they achieve with them.
« Our SDLC varies depending on the project and the client, but we primarily lean toward an agile-leaning model. We like the flexibility and the ability to change quickly based on feedback. However, many stakeholders need roadmaps , release dates, and forecasts, which don't align very well with an agile methodology. So, to make everyone happy while still remaining a productive team that focuses on what matters and can adapt to changes and feedback, we tend to pick parts of agile development together with parts of the waterfall method to build a development life cycle that serves the team. In the end, if something doesn't help us increase value, we won't do it, regardless of whether it falls within the definition of agile or not. »- Justin R. Pennington, Director of Growth at Ceetus .
« We typically work with the Agile methodology for software development. We used to use the Waterfall model, but that led to a lot of back-and-forth discussion, and in the end the client's expectations mostly changed anyway. In Agile we usually run a sprint over 2–4 weeks and interact with the client regularly to get feedback and iterate on it. The Agile methodology reduced our bug rate and increased productivity for our teams. In addition, it keeps the team motivated, since there's a fast feedback loop and opportunities to fix mistakes that were made. Thanks to Agile, we realized that we pay more attention to the actual outcome than to the documentation process. - Saurabh, founder of Talk Travel .
« I like what's often called the« V »model, except I'd describe it more as a zigzag model. That is, there are far more iterations than the V model suggests, so it takes the shape of a «W» or even more — a continuous zigzag until the product has all the features intended for that release, and also finishes the testing needed for that iteration. - John M. Quigley has more than 20 years of experience developing software products at Value Transform .
«Since we're a small company, we don't follow any well-known software development processes. Instead, I just give my developers a task, and they work on it at their own, reasonable pace. I don't micromanage my developers, but sometimes I ask them for an update. I also ask them to tell me if they get stuck on something. That means we have no deadlines! As a software developer myself, I know that software developers hate estimates and deadlines. I don't want my developers worrying about deadlines. I want them to focus on what they enjoy doing most, which is coding, and as soon as their code is tested and ready, we ship it. - Gene, CTO of Static Jobs .
«We moved to something we called "organic." It's very agile, but we chose a different name to avoid the connotations we now have with capital-A Agile. Every two weeks we plan a new iteration and give the previous one a two-week death. We pick the most valuable feature of the project, hand-in-hand with the client, and focus on it relentlessly. It sounds agile, and largely because we do try out ideas from that camp. But the key is that it isn't dogmatic. Giving it a different name and running a two-week review cycle gives us the freedom to try out new ideas and decide whether existing ideas are working for us. For example, the morning stand-up works well. But we found that, because of remote work, pair programming doesn't work for us, so we don't do it. So our life cycle keeps evolving, in a truly Darwinian way: the best methods and tools survive, the rest don't. And since this has shaped our culture, there's no hesitation about critically flagging even my own ideas as useless if they don't pass the test.- James Dunn, CTO of The Fresh UK .
« Momentum uses a combination of Kanban and Scrum: Scrumban. We set up boards in Jira to use sprints the way they'd be used for Scrum development, but those sprints aren't planned out. We manage the sprint backlog using a Kanban-style system. Whenever we're ready to work on something new, we simply pull a card from the To-Do column and start working on the story. We have daily updates with product demos every two weeks. - Matthew Wardenaar, Head of Product at Momentum .
« In our organization we use the Agile SDLC Model; with this approach, each team member focuses on one task at a time. The Agile methodology involves a smaller workload compared to waterfall models. That's because each team member focuses on specific tasks at the same time. This is very useful for accurately estimating project timelines and quickly meeting short-term deadlines. Short-term goals and deadlines motivate employees to work at their best. This methodology helps increase employee productivity and improves customer satisfaction. »- Ayushi Sharma, business consultant, iFour Technolab Pvt Ltd -«a Custom Software Development Company .
« Choosing an SDLC model largely depends on the project's goal. We use both waterfall and agile models, which aren't binary, mutually exclusive alternatives, as they might seem. We start with waterfall, so we can estimate rough dates and refine the task along the way. Basically the template looks like this: Requirements gathering -> Solution design -> Solution implementation -> Solution testing -> Solution deployment. The waterfall method provides a value chain with several points of failure from idea to rollout.
However, for actually implementing the project, we use Agile. Agile methods don't have a single point of failure in the value chain. The client usually needs flexibility, especially when it comes to product development. A trend toward more flexible, agile principles is most likely to lead to a more successful outcome. A pure waterfall or sequential approach can be riskier and have a higher chance of failure. It's more a question of how iterative you want to be. In some cases you want much shorter feedback loops. In others, it's better to plan large chunks of work and have longer feedback loops. Roman Kolos, Product Manager at LAB325 .
« My name is Kean Graham, and I'm the CEO of MonetizeMore , an eight-figure ad tech company that is a certified Google partner with a team of more than 100 people working around the world.
We have more than 20 engineers split across three agile teams. Software development was quite a challenge, since our technical work kept getting delayed again and again. We then made several important improvements, such as:
- Involve design in sprint planning
- Daily, sprint, and monthly KPIs to evaluate performance
- Get engineers closer to users
- Automate testing
- move to CI/CD
- improve overall communication
- Make documentation more thorough and consistent
The above significantly improved our sprint completion rates, which improved delivery consistency; technical features were built faster, and the quality of the technology improved, since the expected user outcomes are achieved more consistently. - Kean Graham, CEO of MonetizeMore .
All the software life cycle stages presented above apply to any development model, but their duration and sequence can differ. This article has taken a detailed look at the main models and practices used by modern IT companies in the software development process.
So that's everything covered in this guide! I hope it helps you. Feel free to share your thoughts on the SDLC methods you've used so far in the comments below.
Часть 1 All Types of Software Development Methodologies and the Software Development Life Cycle
Часть 2 7. «Spiral Model» (spiral model) - All Types of Software
Comments