Introduction to Software Engineering
Here are some notes or highlights I took from the book Beginning Software Engineering by Rod Stephens. I liked this book a lot, because it has many jokes in between that makes you enjoy the reading. Actually everything starts with a pretty nice joke in the book introduction:
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to build bigger and better idiots. So far the universe is winning. - Rick Cook
And Rod a reflection about Software Engineering importance:
To produce applications that are effective, safe, and reliable, you can't just sit down and start typing. You need a plan. You need … <drumroll> … software engineering. - Rod Stephens
So, What is Software Engineering?
Formal mode: “An organized, analytical approach to the design, development, use, and maintenance of software.”
Intuitive mode: Software engineering is everything you need to do to produce successful software. It includes the steps that take a raw, possibly nebulous idea and turn it into a powerful and intuitive application that can be enhanced to meet changing customer needs for years to come.
One of the big differences between software engineering and most other kinds of engineering is that software isn't physical. It exists only in the virtual world of the computer. That means it's easy to make changes to any part of a program even after it is completely written.
The flexibility granted to software by its virtual nature is both a blessing and a curse. It's a blessing because it lets you refine the program during development to better meet user needs. But is a curse because adding a new feature can break existing code or turn a simple, elegant design into a confusing mess. Constantly adding, removing, and modifying features during development can make it impossible for different parts of the system to work together. In some cases, it can even make it impossible to tell when the project is finished.
Because software is so malleable, design decisions can be made at any point up to the end of the project. Actually, successful applications continue evolving after the initial release.
The fact that changes can come at any time means you need to consider the whole development process as a single, long, complex task. You can't simply “engineer” a great design, turn the programmers loose on it, and walk off into the sunset wrapped in the warm glow of a job well done. The biggest design decisions may come early, and software development certainly has stages, but those stages are linked, so you need to consider them all together.
Why is Software Engineering important?
Software engineering includes techniques for avoiding the many pitfalls that otherwise might send your project down the road to failure. It ensures the final application is effective, usable, and maintainable. It helps you meet milestones on schedule and produce a finished project on time and within budget. Perhaps most important, software engineering gives you the flexibility to make changes to meet unexpected demands without completely obliterating your schedule and budget constraints.
Steps of Software Engineering (Big Picture)
No big project can succeed without a plan. Sometimes a project doesn’t follow the plan closely, but every big project must have a plan. The plan tells project members what they should be doing, when and how long they should be doing it, and most important what the project’s goals are. They give the project direction.
- Requirements gathering
One of the first steps in a software project is figuring out the requirements. You need to find out what the customers want and what the customers need (because there is a really big difference there). Depending on how well defined the user’s needs are, this can be time-consuming.
In any project, you should try to identify your customers and interact with them as much as possible so that you can design the most useful application possible. Something is really easy to identify the customer, but in some cases this can be really vague.
After you determine the customers’ wants and needs, you can turn them into requirements documents. Those documents tell the customers what they will be getting, and they tell the project members what they will be building. Throughout the project, both customers and team members can refer to the requirements to see if the project is heading in the right direction.
Keep in mind that change happens, and customers like to request those changes at the last minute. Document your requirements in formal agreements, and be open to change, only when this can be propely managed.
- High-level Design
After you know the project’s requirements, you can start working on the high-level design. The high-level design includes such things as decisions about what platform to use, what data design to use, and interfaces with other systems.
The high-level design should also include information about the project architecture at a relatively high level. You should break the project into the large chunks that handle the project’s major areas of functionality. Depending on your approach, this may include a list of the modules that you need to build or a list of families of classes.
You should make sure that the high-level design covers every aspect of the requirements. It should specify what the pieces do and how they should interact, but it should include as few details as possible about how the pieces do their jobs.
- Low-level Design
Once your high-level design breaks the project into pieces, you can assign those pieces to groups within the project so that they can work on low-level designs. The low-level design includes information about how that piece of the project should work. The design should give enough guidance to the developers who will implement those pieces, but not necesarily every single detail.
- Development
The programmers continue refining the low-level designs until they know how to implement those designs in code. As the programmers write the code, they test it to find and remove as many bugs as they reasonably can.
- Testing
Effectively testing your own code is extremely hard. Even if a particular piece of code is thoroughly tested and contains no (or few) bugs, there’s no guarantee that it will work properly with the other parts of the system.
One way to address both of these problems (developers don’t test their own code well and the pieces may not work together) is to perform different kinds of tests. First developers test their own code. Then testers who didn’t write the code test it. After a piece of code seems to work properly, it is integrated into the rest of the project, and the whole thing is tested to see if the new code broke anything.
Any time you change the code, whether by adding new code or fixing old code, you need to test it to make sure everything works as it should.
- Deployment
Ideally this should be an easy step, but sometimes deployment can be difficult, time-consuming, and expensive. It might involve any or all of the following:
- New computers for the back-end database
- A new network
- New computers for the users
- User training
- On-site support while the users get to know the new system
- Parallel operations while some users get to know the new system and other users keep using the old system
- Special data maintenance chores to keep the old and new databases synchronized
- Massive bug fixing
- Other nonsense that no one could possibly predict
- Maintenance
As soon as the users start playing around on your software, they’ll find bugs. Then you need to fix them, but, fixing a bug sometimes leads to another bug, so now you get to fix that one as well.
If your application is successful, users will use it a lot, and they’ll be even more likely to find bugs. They will also think up a bunch of enhancements, improvements, and new features that they want added immediately.
- Post-mortem
You need to evaluate the project and decide what went right and what went wrong. You need to figure out how to make the things that went well occur more often in the future. Conversely, you need to determine how to prevent the things that went badly in the future. This will be part of a continuous improvement process for your own Development process.
So, now we know that all software engineering projects must handle the same basic tasks. Different development models may handle them in different ways, but they’re all hidden in there somewhere. In fact, the strengths and weaknesses of various development models depend in a large part on how they handle these tasks.
Comentarios
Publicar un comentario