Reviewing software development methodologies
Video: Reviewing software development methodologiesIt's a common question from people new to programming. Is there one process, one roadmap, one predefined template that will take me through all the necessary steps from start to finish, to make a piece of software? And no, there isn't one process. There are many that promise to help you do just that. These are just a few of the formal software development methodologies. Now why so many? Well, first and most simply, because software development isn't one thing.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Reviewing software development methodologies
It's a common question from people new to programming. Is there one process, one roadmap, one predefined template that will take me through all the necessary steps from start to finish, to make a piece of software? And no, there isn't one process. There are many that promise to help you do just that. These are just a few of the formal software development methodologies. Now why so many? Well, first and most simply, because software development isn't one thing.
If I want to build a quiz application for my iPhone, that requires one level of thought. One style of planning. But if I want to build an international banking system, or a safety monitoring system for a nuclear reactor, that's something quite different. So some of these are quite loose and formal, and some are very formal, detailing every aspect of what's called the software development lifecycle. Including project management and people management, budgeting, documentation requirements, down to how many meetings you should have and how often those meetings should occur.
But this is not what we are doing in this course. What we are doing here is part of these. It would work with any software development process, formal or informal. We are working on the part where we understand our problem and design a solution. Not on budgeting, not on personnel. An object-oriented design will tell you what classes to write, it won't tell you how many people your team should have. It won't tell you what platform to build this on. It won't estimate how long this project should take, but it can help you figure these things out if you need to.
Now if you work in an organization, you may have one of these formal methodologies already in place, or something that's been developed in-house and unique to your company, or something loose and informal, or no process at all. I am not expecting any particular methodology. The one assumption I am going to make is that we are using an Agile Iterative approach to developing software, as opposed to a Waterfall approach. Now if those terms are new to you, let me briefly explain. In the first decades of software development, and even when I started programming, it was usual to have what was referred to as a Waterfall approach, a strict linear plan with several distinct steps.
You go through these methodology step by step, completely finishing each step, getting signed off and moving on to the next one. Sounds like a good approach. Just one problem. It doesn't work. The moment you get to implementation to writing code you are going to hit problems you didn't think off. You are going to get new requirements that will make whatever you wrote in the first phase seem like a joke. Your customer is going to change their mind, you are going to change your mind. So this kind of approach might work for building a suspension bridge.
It doesn't work very well for software. Software development needs to be responsive. We need to add new features, we need to fix bugs, we need to support continual development. That's continual programming, supported by continual analysis and design. So instead, we use an Iterative or Agile approach. We imagine that any development will involve several incremental cycles, iterations, each including analysis, design, and programming.
These are measured in weeks, not months, and that we will move through these multiple times. Now this is a much more effective approach for most projects, and it's a great one for us, and that we don't have to know everything upfront. We don't need to create a perfect analysis and design. In fact, we expect our initial iterations to be inaccurate and incomplete, and we will improve them as we go. Now if you think your first object- oriented design is perfect, it's either very small, or you probably spent too long in it.
It's not meant to be perfect, it's meant to be good enough, and that's our focus in this course. Just enough design to let us move forward successfully.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.