2023/05/27

Foundation of Systems Development – Week 9

3 Different Approaches to SDLC

Predictive Approach

Imagine you’re building a house. With the predictive approach, you’d create a detailed blueprint before starting any construction. You’d know exactly how many rooms the house will have, what materials you’ll need, and how long it should take to build. This is similar to the Waterfall model in software development. You’d set a detailed plan at the start, defining what the software should do, how it should do it, and when it should be done. This approach works best when you know exactly what you want the end result to look like and how to get there, just like knowing exactly what your house should look like before you start building.

Keywords

Waterfall Model
Planned
Structured
Sequential
Fixed requirements
Predictable
Low flexibility
High certainty

Adaptive Approach

Going back to the house-building example, with the adaptive approach, you might start by building one room. Once that’s done, you’d evaluate what works and what doesn’t, maybe get some feedback from the people who will live in the house, and then plan the next room based on what you’ve learned. This is the same as the Iterative model in software development. You develop a part of the software, see how it works, make improvements, and then move on to the next part. This approach is great when you’re not exactly sure what the final product should look like or if you expect that the requirements might change along the way. It allows for flexibility and adjustments as you progress with the project.

Keywords

Iterative Model
Agile
Flexible
Incremental
Evolving requirements
Responsive
High adaptability
Uncertainty

Newer Adaptive Approach

The newer adaptive approach to the System Development Life Cycle (SDLC) was developed to address complex system requirements and unpredictable tech environments. It accepts that projects need to adapt to changing information and circumstances. The process is divided into small cycles, each with a portion of the design and implementation work. It starts with a ‘Walking Skeleton’ or a basic system structure, with additional features added over time. Despite being favored by many developers for its adaptability, some Information Systems (IS) managers express reservations due to its perceived lack of a definitive plan.

Difference when comparing to Traditional Adaptive Approach

The traditional adaptive approach to SDLC is often characterized by a series of phases where each phase depends on the deliverables of the previous one. The development cycle is not strictly sequential as it may involve some overlap of phases, but it still adheres to a general order. Changes in the requirements or design can be made, but these usually occur within the constraints of each phase. Thus, there is a level of flexibility, but it is relatively limited.

In contrast, the newer adaptive approach, often associated with Agile methodologies, embraces change and uncertainty more fully. It recognizes that requirements may not be completely known at the outset and may evolve over time. Development is carried out in short, iterative cycles, and feedback from each cycle is used to inform the next. The focus is on delivering a working product incrementally, starting with a basic version (the “walking skeleton”) and adding functionality over time.

Methodologies, Models, Tools, and Techniques

Methodologies

A methodology in system development is like a detailed roadmap for a project. It gives guidelines on what needs to be done, when to do it, why it’s important, and how to do it. It includes an outline of the System Development Life Cycle (SDLC) with activities and tasks, instructions for project planning and management, models for analysis and design, and techniques for implementation, testing, deployment, and support. Simply put, it’s a collection of various techniques that guide you through every step of a project, from start to finish, like a recipe for creating a complex dish. This term is sometimes also referred to as the System Development Process.

Models

In simple terms, a model is like a simplified representation or a sketch of something much more complex, kind of like a map of a city. It helps us understand a complex concept by focusing only on the parts that matter to us at that moment, leaving out the unnecessary details.

In information systems, models can represent different aspects of a project. Some models illustrate the components of the system that will be developed, like a blueprint for a building. Examples of these are use case diagrams, sequence diagrams, and database schemas, which depict different aspects of the system like its functions, interactions, and data structure.

Other models are more about managing the project itself. These are like tools to plan, track, and assess the progress of the project. For example, a Gantt chart is a type of bar chart that illustrates a project schedule, showing when each task needs to start and finish. Financial analysis models like Net Present Value (NPV) help in evaluating the financial feasibility of the project.

Overall, models are a crucial tool for communication in a project, making complex ideas more understandable and manageable.

Tools

Imagine you’re trying to build a house. You’d need various tools like a hammer, nails, a saw, etc. to get the job done efficiently and correctly. In a similar way, in software development, there are various software applications called ‘tools’ that help developers create and manage different aspects of a project.

For example, there are Visual Modeling Tools, which are like digital drawing boards. These allow developers to create diagrams and models that represent various aspects of the system being developed.

Techniques

A technique is like a recipe or a roadmap. It provides step-by-step instructions to help complete a task or activity. Just like cooking a new dish is easier with a recipe, carrying out activities in software development is more manageable when following a specific technique. The more techniques you learn and master, the more proficient you become in your field.

Agile

Agile Development

Imagine you’re going on a road trip without a set destination. You have a car, a group of friends, and a rough idea of where you want to go. Along the way, you might decide to take a detour to check out an interesting landmark, or you might need to change your route because of roadworks. The important thing is that you’re enjoying the trip, and you’re making progress, even if you don’t know exactly where you’ll end up.

Agile development is a lot like this road trip. It’s a way of developing software where the final destination (the complete software product) isn’t strictly defined from the start. Instead, you begin with a basic idea of what you want to achieve, and you make progress in small steps, or ‘iterations’.

This approach is often described as ‘chaordic’, a blend of chaos and order. It might seem chaotic because you’re not following a strict plan, but it’s also ordered because you’re continually making progress and adjusting as you go.

The Agile philosophy is based on four key values outlined in the “Manifesto for Agile Software Development”:

Responding to change over following a plan: Like on our road trip, the ability to change direction when needed is more important than sticking rigidly to a pre-defined route.
Individuals and interactions over processes and tools: The people on your team and how they work together are more important than any specific method or tool.
Working software over comprehensive documentation: Having something that works and delivers value is more important than having thorough documentation. It’s like preferring to have fun experiences on the trip instead of spending all your time plotting every single detail on a map.
Customer collaboration over contract negotiation: Working closely with your customers and incorporating their feedback is more valuable than sticking to the strict terms of a contract. It’s about being open to new suggestions and ideas, much like deciding on places to visit based on recommendations from locals along the way.

So, in a nutshell, Agile development is about flexibility, collaboration, and making continual progress towards a goal, even if you don’t know all the details from the start.

Agile Principle

Imagine you’re building a LEGO castle. You don’t have an exact blueprint, but you have a bunch of LEGO blocks and a basic idea of what a castle looks like. You start building, one block at a time, adjusting as you go based on what looks good and what doesn’t. You’re not worried about making a detailed plan, you’re just focused on building a great castle. That’s what it’s like to follow the Agile Modeling (AM) principles in software development.

Here they are, explained simply:

Develop software as the primary goal: Like building your LEGO castle, the main goal is to build working software, not to get caught up in extensive plans or paperwork.
Enable the next effort as your secondary goal: Be mindful of what comes next. Like knowing you need a tower for your castle after finishing the walls.
Minimize your modeling activity: Only build what helps move the project forward, like choosing to add only the necessary blocks that contribute to your castle’s structure.
Embrace change and change incrementally: It’s okay to change your mind and adjust your design, just like you might move a LEGO block if it doesn’t fit right.
Model with a purpose: Whether to understand better or to communicate with others, like imagining how your castle will look or explaining to a friend what you’re building.
Build multiple models: Try different designs or perspectives. Maybe you’re building a castle, but could it also be a fort or a palace?
Build high-quality models and get feedback: Make sure what you’re building is good and ask others what they think, like asking a friend’s opinion about your LEGO castle.
Focus on content rather than representation: What matters is what your models do, not how they look, just like the sturdiness of your LEGO castle is more important than its color.
Always focus on stakeholder needs: Build your software (or your castle) to meet the needs of the people who will use it.
Learn from each other with open communication: Talk to each other, share ideas, like discussing with your friends how best to build your LEGO castle.
Know your models and how to use them: Understand what you’re building and why, like knowing that you need sturdy walls for your castle to stand up.
Adapt to specific project needs: Be flexible and adjust your approach based on what your project needs, like changing your castle design if you run out of certain LEGO blocks.

In a nutshell, these Agile Modeling principles guide you to focus on building useful, working software, to communicate openly, adapt to change, and always strive to meet the needs of the people using the software. It’s all about being efficient, adaptable, and focused on delivering value.

The Unified Process, Extreme Programming, and Scrum

UP (Unified Process)

UP is an example of an adaptive methodology, and was one of the first of its kind to gain wide acceptance in the field of software development. Before the advent of Agile methodologies, the Unified Process (UP) was a popular choice among adaptive methodologies for software development.

Let’s imagine you’re planning a big, fun party – that’s similar to the Unified Process (UP), a way of planning and carrying out software development projects.

Just like planning a party, you’ll go through different stages:

Inception phase: You’ve decided to throw a party. You figure out why you’re having it (celebration, holiday, just for fun), who will be there, and make rough estimates for how much it might cost and when it could happen.
Elaboration phase: You’ve got a vision for your party and start making more detailed plans. You decide on a theme, choose the menu, arrange entertainment, and work out the details of when and where it will be held.
Construction phase: It’s time to put your plan into action. You prepare the food, set up the decorations, and ensure everything is ready for the party to start.
Transition phase: The party has started, and now you make sure everything runs smoothly. You check the music is playing, the food is served on time, and everyone is having fun.

During these stages, you perform different activities or “disciplines”. Think of these like tasks you need to do to make your party successful:

Development Disciplines:

Business modeling: Like deciding what kind of party you want to throw.
Requirements: Figuring out what you need for the party, like food, music, and decorations.
Design: Planning how the party will look and feel.
Implementation: Setting up for the party.
Testing: Checking everything is working, like the sound system or the oven.
Deployment: Starting the party!

Planning and Control disciplines:

Configuration and change management: Adapting your plans if things change. For example, if it rains, you might need to move the party inside.
Project management: Organizing all your tasks, like shopping, cooking, and decorating.
Environment: Setting up the space where the party will happen.

These disciplines are carried out across all iterations, or stages, of the process. So, in the context of your party, you’d be considering all these tasks throughout the planning, setting up, and running of your event. That’s how UP works for developing software – except instead of a party, you’re building a software system!

XP (Extreme Programming

Extreme Programming (XP) is a software development methodology that takes common best practices in the industry and amplifies them to enhance the development process. The idea is to use what works really well and use it even more intensely to produce better results.

Here are the main aspects of XP simplified:

Core Values

The philosophy of XP revolves around four core values – Communication, Simplicity, Feedback, and Courage. This means XP encourages clear and frequent communication among team members, keeping solutions simple and straightforward, continuous feedback for improvements, and the courage to adapt to changes and tackle complex problems.

Practices: XP is known for its unique practices.

Planning: The planning process is based on ‘user stories’, which are simple explanations of a feature told from the perspective of the user.
Testing: XP insists on thorough testing at every step of development to catch and fix issues as soon as possible.
Pair Programming: Two programmers work together on the same code – one writes, and the other reviews it in real-time.
Simple Designs: The system is kept as simple as possible at all times, with complexity added only when necessary.
Refactoring: Code is continuously improved and cleaned up to keep it efficient and maintainable.
Collective Ownership: Everyone on the team shares responsibility for the code, and anyone can make improvements to it.
Continuous Integration: Changes are integrated into the project frequently, often several times a day, to detect issues early.
On-site Customer: A representative of the end-user is always available to provide feedback and approve changes.
Small Releases: Updates and new features are delivered to the user frequently.
Work-Life Balance: XP emphasizes a sustainable pace and discourages overworking developers.
Coding Standards: The team agrees on and adheres to a set of coding standards to ensure consistency and readability.

Three-Level Approach

XP follows a cycle of creating user stories and acceptance tests (outer ring), testing and planning (middle ring), and iterative coding and testing (inner ring).

The aim of XP is to create a high-quality product that meets the user’s needs effectively and efficiently, with a development process that’s flexible and responsive to change.

Scrum

Scrum is a method used in Agile software development that takes inspiration from the sport of rugby, where everyone plays a role and teamwork is crucial. It aims to manage and control complex software and product development using iterative, incremental practices.

Here’s a simple explanation of its main components:

Product Backlog: This is a list of all the tasks and requirements that need to be done for the project. It’s prioritized based on what the customer needs first or what will add the most value to the project.
Product Owner: This is usually the person who represents the customer’s interests and knows what they want. The product owner manages the product backlog and decides what tasks are most important.
Scrum Master: The Scrum Master is like the coach of the team. They help make sure the team is working well together and that they’re following the principles and practices of Scrum.
Scrum Sprint: This is a short, set period of time during which the team works to complete specific tasks from the product backlog. The scope of each sprint is fixed and doesn’t change during the sprint, unless it is found necessary to reduce the scope.
Daily Scrum Meeting: This is a quick, daily meeting where each team member answers three questions:
- What did I accomplish since the last meeting?
- What will I work on before the next meeting?
- What obstacles are in my way?
These meetings are designed to promote regular communication amongst team members and to quickly identify and solve any issues that may be slowing down the process.

information