Software Development Fundamentals

Management fundamentals

Estimation and Scheduling

Well-run projects go through three basic steps to create a software schedule. They first estimate the size of the project, then they estimate the effort needed to build a product of that size, and then they estimate a schedule based on the effort estimate.

Planning

software development problems

•  Ill-defined contract
•  Unstable problem definition
•  Inexperienced management
•  Political pressures
•  Ineffective change control
•  Unrealistic deadlines

 software project includes these activities

• Estimation and scheduling
• Determining how many people to have on the project team, what technical skills are needed, when to add people, and who the people will be
• Deciding how to organize the team
• Choosing which life cycle model to use
• Managing risks
• Making strategic decisions such as how to control the product's feature set and whether to buy or build pieces of the product

Tracking
Once you've planned a project, you track it to check that it's following the plan—that it's meeting its schedule, cost,' and quality targets. Typical management-level tracking controls include task lists, status meetings, status reports, milestone reviews, budget reports, and management by walking around. Typical technical-level tracking controls include technical audits, technical reviews, and quality gates that control whether you consider milestones to be complete.

Measurement

You need to have a basic knowledge of software measurement to develop efficiently. You need to understand the issues involved in collecting metrics, including how much or how little data to collect and how to collect it. You should have a knowledge of specific metrics you can use to analyze status, quality, and productivity. An organization that wants to develop rapidly needs to collect basic metrics in order to know what its development speed is and whether it's improving or degrading over time.

Requirements Management

  Requirements management is the process of gathering requirements; recording them in a document, email, user-interface storyboard, executable prototype, or some other form; tracking the design and code against them; and then managing changes to them for the rest of the project.

Here are the fundamentals of requirements management

• Requirements-analysis methodologies including structured analysis, data structured analysis, and
  object-oriented analysis
• System-modeling practices such as class diagrams, data flow diagrams, entity-relationship diagrams,data-dictionary notation, and state transition diagrams
• Communication practices such as Joint Application Development (JAD), user-interface prototyping, and general interview practices
• The relationships between requirements management and the different life cycle models including evolutionary prototyping, staged releases, spiral, waterfall, and code-and-fix

 Design Management

 Just as it makes sense to create a set of blueprints before you begin building a house, it makes sense to create an architecture and design before you begin building a software system. A design error left undetected until system testing typically takes 10 times as long to fix as it would if it were detected at design time.

 Software Configuration Management

 the practice of managing project artifacts so that the project stays in a consistent state over time. SCM includes practices for evaluating proposed changes, tracking changes, handling multiple versions, and keeping copies of project artifacts as they existed at various times.

Quality-Assurance Fundamentals 

projects try to save time by reducing the time spent on quality-assurance practices such as design and
code reviews. Other projects—running late—try to make up for lost time by compressing the testing
schedule, which is vulnerable to reduction because it's usually the critical-path item at the end of the project.These are some of the worst decisions a person who wants to maximize development speed can make because higher quality (in the form of lower defect rates) and reduced development time go hand in hand.

Error-Prone Modules

An error-prone module is a module that's responsible for a disproportionate number of defects.Barry Boehm reports that about 20 percent of the modules in a program are typically responsible for about 80 percent of the errors (Boehm 1987b).Modules with such high defect rates are more expensive and time-consuming to deliver than less error-prone modules.

Testing

The most common quality-assurance practice is Undoubtedly execution testing, finding errors by executing a program and seeing what it does. The two basic kinds of execution testing are unit tests, in which the developer checks his or her own code to verify that it works correctly, and system tests, in which an independent tester checks to see whether the system operates as expected.

Technical Reviews

Technical reviews include all kinds of reviews that are used to detect defects in requirements, design, code, test cases, or other project artifacts.

• walkthrough:- The term "walkthrough" is loosely defined and refers to any meeting at which two or more developers review technical work with the purpose of improving its quality.
• Code reading:- In code reading, the author of the code hands out source listings to two or more
  reviewers. The reviewers read the code and report any errors to the author of the code.
• Inspections:- The "moderator" hands out the work product to be inspected before the inspection meeting. The "reviewers" examine the work product before the meeting and use checklists to stimulate their review. During the inspection meeting, the "author" usually paraphrases the material being inspected, the reviewers identify errors, and the "scribe" records the errors. After the meeting, the moderator produces an inspection report that describes each defect and indicates what will be done about it.