4: Chapter Software-Development Fundamentals One path to success in software is paying attention to fundamentals. If you don't master fundamentals, you'll do OK on the easy projects, but your hard projects will fall apart. 1. Management Fundamentals Organizations that attempt to put software-engineering discipline in place before putting project-management discipline in place are doomed to fail. Management fundamentals consist of (1) determining the size of the product (which includes functionality, complexity, and other product characteristics), (2) allocating resources appropriate for a product of that size, (3) creating a plan for applying the resources, and then (4) monitoring and directing the resources. A. Estimating and Scheduling Three basic steps to create a software schedule (1) estimate the size of the project, then (2) estimate the effort needed to build a product of that size and then (3) estimate a schedule based on the effort estimate. An inaccurate estimate reduces development efficiency. Accurate estimation is essential input for effective planning, which is essential for efficient development. B. Planning Best projects are characterized by strong up-front planning to define tasks and schedules. Planning included these activities: 1. Estimation and scheduling 2. 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. 3. Deciding how to organize the team 4. Choosing which lifecycle model to use 5. Managing risk 6. Making strategic decisions such as how to control the product's feature set and whether to buy or build pieces of the product. C. Tracking On a typical project, project management is almost a black-box function. You rarely know what's going on during the project and you just have to take whatever comes out at the end. On an ideal project you have 100 percent visibility at all times. On an efficient project, you always have at least some visibility and you have good visibility more often than not. See p. 57 for graphs. If you don't track a project, you can't manage it. You have no way of knowing whether your plans are being carried out and no way of knowing what you should do next. You have no way of monitoring risk to you project. Effective tracking enables you to detect schedule problems early, while there's still time to do something about them. D. Measurement One key to long-term progress in a software organization is collecting metric data to analyze software quality and productivity. II. Technical Fundamentals 1. Requirements Management Is the process of gathering requirements, recording them in some form, tracking the design and code against them, and then managing changes to them for the rest of the project. Top three reasons that projects were delivered late, over budget, and with less functionality than desired (1) lack of user input (2) incomplete requirements, and (3) changing requirements. Success at requirements management depends on knowing enough different practices to be able to choose the ones that are appropriate for a specific project. Fundamentals of requirements management: 1. Requirements analysis methodologies including structured analysis, data structured analysis, and object-oriented analysis. 2. System-modeling practices such as class diagrams, DFD, ERD, data-dictionaries, and state-transition diagrams. 3. Communication practices such as JAD, user-interface prototyping, and general interview practices. 4. The relationships between requirements management and the different lifecycle models. 2. Design Fundamental topics 1. Major design style--such as object design, structured design, and data structure design 2. Foundational design concepts--such as information hiding, modularity, abstraction, encapsulation, cohesion, coupling, hierarchy, inheritance, polymorphism, basic algorithms, and basic data structures
3. 4. 5. 6.
Stand design approaches to typically challenging areas--including exception handling, internationalization and localization, portability, string storage, input/output, memory management, data storage, floating-point arithmetic, database design, performance, and reuse Design considerations unique to the application domain--such financial, as scientific, embedded systems, real-time systems, and safety-critical software. Architectural schemes--such as subsystem organization, layering Use of design tools.
Design serves as the foundation for construction, project scheduling, project tracking, and project control. 3. Construction Fundamentals 1. Coding practices--including variable and function naming, layout, and documentation 2. Data-related concepts --such as scope, persistence, and binding 3. Guidelines for using specific types of data--such as integer, floating-point, arrays ... 4. Control-related concepts--including organizing strait-line code, using conditionals, controlling loops ... 5. Assertions and other code-centered error-detection practices 6. Rules for packaging code into routines, modules, classes, and likes 7. Unit-testing and debugging practices 8. Integration strategies--such as incremental integration, big-bang integration, and evolutionary development 9. Code-tuning strategies and practices 10. The ins and outs of the particular programming language you're using 11. Use of constructions tools--including environments, group work support, and code generators 4. Software Configuration Management Is the practice of managing project artifacts so that the project stays in a consistent state over time. Includes practices for evaluating proposed changes, tracking changes, and handling multiple versions. Without configuration management, your teammates can change part of the design and forget to tell you. I. Quality-Assurance Fundamentals When a software product has too many defects, developers spend more time fixing the software than they spend writing it. Some 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. Poor quality is one of the most common reasons for schedule overruns. Up to four times the normal number of defects are reported for released products that were developed under excessive schedule pressure. Rule of thumb, every hour you spend on defect prevention will reduce your repair time 3 to 10 hours. The further from its origin that a defect is detected, the more it will cost to fix. A. Error Prone Modules About 20% of the modules in a program are typically responsible for about 80 % of the errors. Error prone modules tend to be more c...