Essential attributes of good software
Essential Attributes of Good Software
Maintainability: Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment.
Dependability and Security: Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system.
Efficiency: Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc.
Acceptability: Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable, and compatible with other systems that they use.
In order to do Software Development Well we Need the:
A Small, Well-Integrated Team:
Small teams have fewer lines of communication than larger ones. It’s easier to get to know your teammates on a small team. You can get to know your teammates’ strengths and weaknesses, who knows what, and who is the “go-to guy” for particular problems or particular tools. Well-integrated teams have usually worked on several projects together. Keeping a team together across several projects is a major job of the team’s manager. Well-integrated teams are more productive, they are better at holding to a schedule, and they produce code with fewer defects at release. The key to keeping a team together is to give them interesting work to do and then leave them alone.
Good Communication Among Team Members:
Constant communication among team members is critical to day-to-day progress and successful project completion. Teams that are co-located are better at communicating and communicating more than teams that are distributed geographically (even if they’re just on different floors or wings of a building). This is a major issue with larger companies that have software development sites scattered across the globe. Good Communication Between the Team and the Customer: Communication with the customer is essential to control requirements and requirements churn during a project. On-site or close-by customers allow for constant interaction with the development team. Customers can give immediate feedback on new releases and be involved in creating system and acceptance tests for the product.
A Process that Everyone Buys Into: Every project, no matter how big or small, follows a process. Larger projects and larger teams tend to be more plan-driven and follow processes with more rules and documentation required. Larger projects do require more coordination and tighter controls on communication and configuration management. Smaller projects and smaller teams will, these days, tend to follow more agile development processes, with more flexibility and less documentation required. This certainly doesn’t mean there is no process in an agile project, it just means you do what makes sense for the project you’re writing so that you can satisfy all the requirements, meet the schedule, and produce a quality product.
The Ability to be Flexible about that Process: No project ever proceeds as you think it will on the first day. Requirements change, people come and go, tools don’t work out, and so on. This point is all about handling risk in your project. If you identify risks, plan to mitigate them, and then have a contingency plan to address the event where the risk actually occurs, you’ll be in much better shape.
A Plan that Every One Buys Into:
You wouldn’t write a sorting program without an algorithm, so you shouldn’t launch a software development project without a plan. The project plan encapsulates what you’re going to do to implement your project. It talks about process, risks, resources, tools, requirements management, estimates, schedules, configuration management, and delivery. It doesn’t have to be long and it doesn’t need to contain all the minute details of the everyday life of the project, but everyone on the team needs to have input into it, they need to understand it, and they need to agree with it. Unless everyone buys into the plan, you’re doomed.
To Know Where You Are at All Times:
It’s that communication thing again. Most projects have regular status meetings so that the developers can “sync up” on their current status and get a feel for the status of the entire project. This works very well for smaller teams (say, up to about 20 developers). Many small teams will have daily meetings to sync up at the beginning of each day. Different process models handle this “spot” meeting differently. Many plan-driven models don’t require these meetings, depending on the team managers to communicate with each other. Agile processes often require daily meetings to improve communications among team members and to create a sense of camaraderie within the team.
To be Brave Enough to Say, “Hey, We’re Behind!” : Nearly all software projects have schedules that are too optimistic at the start. It’s just the way we are. Software developers are an optimistic bunch, generally, and it shows in their estimates of work. “Sure, I can get that done in a week!” “I’ll have it to you by the end of the day.” “Tomorrow? Not a problem.” No, no, no, no, no. Just face it. At some point, you’ll be behind. And the best thing to do about it is to tell your manager right away. Sure, she might be angry. But she’ll be angrier when you end up a month behind and she didn’t know it. Fred Brooks’ famous answer to the question of how software projects get so far behind is “one day at a time.? The good news, though, is that the earlier you figure out you’re behind, the more options you have. These include lengthening the schedule (unlikely, but it does happen), moving some requirements to a future release, getting additional help, etc. The important part is to keep your manager informed.
The Right Tools and the Right Practices for this Project: One of the best things about software development is that every project is different. Even if you’re doing version 8.0 of an existing product, things change. One implication of this is that for every project one needs to examine and pick the right set of development tools for this particular project. Picking tools that are inappropriate is like trying to hammer nails with a screwdriver; you might be able to do it eventually, but it sure isn’t easy or pretty, and you can drive a lot more nails in a shorter period of time with a hammer than with a screwdriver.
The three most important factors in choosing tools are the application type you are writing, the target platform, and the development platform. You usually can’t do anything about any of these three things, so once you know what they are, you can pick tools that improve your productivity. A fourth and nearly as important factor in tool choice is the composition and experience of the development team. If your team are all experienced developers with facility on multiple platforms tool choice is much easier. If, on the other hand, you have a bunch of fresh-outs and your target platform is new to all of you, you’ll need to be careful about tool choice and fold in time for training and practice with the new tools.
Realize that you Don’t Know Everything you Need to Know at the Beginning of the Project: Software development projects just don’t work this way. You’ll always uncover new requirements; other requirements will be discovered to be not nearly as important as the customer thought; still, others that were targeted for the next release are all of a sudden requirement number 1. Managing requirements churn during a project is one of the single most important skills a software developer can have. If you are using new development tools (say that new web development framework) you’ll uncover limitations you weren’t aware of and side-effects that cause you to have to learn, for example, three other tools to understand them.