Preparation for coding SCMP 391.00 Special Topic: Software Development Spring 2018 James Skon

Why Prepare? Measure Twice, Cut Once: Without preparation, mistakes are bound to be made. Small mistakes early can make big problems later.

Risk Reduction The overarching goal of preparation is risk reduction… A good project planner clears major risks out of the way as early as possible so that the bulk of the project can proceed as smoothly as possible By far the most common project risks in software development are poor requirements and poor project planning, thus preparation tends to focus on improving requirements and project plans.

Why a lack of preparation? Lack skills: Project Planning Requirement analysis Architectural Design Impatience to start coding Pressure to produce something tangible. WISCA syndrome: “Why Isn't Sam Coding Anything? “

What history tells us Researchers … have found that purging an error by the beginning of construction allows rework to be done 10 to 100 times less expensively than when it's done in the last part of the process, during system test or after release

Finding Defects Average Cost of Fixing Defects Based on When They're Introduced and Detected Time Introduced Requirements Architecture Construction System Test Post- Release 1 3 5-10 10 10-100 15 25-100 10-25

Cost of Fixing Defects

Matching methodology with project type Different kinds of project call for different strategies Good practices for three common kinds of software.

Sequential Approach

Iterative approach Sometimes it is not possible to know complete prerequisites at the start. Iterative approaches uses a cycle: plan, specify, implement, test, plan … The idea is to learn as you goes, finding and fixing problems early rather then later. Rework is still required, but in done sooner. Table

Iterative approach

No true waterfall Activities will overlap to some degree

Activity overlap varies

Choosing Between Iterative and Sequential Approaches Type of project, available resources, risks, manpower, external requirements impact the choice.

Sequential indicators The requirements are fairly stable. The design is straightforward and fairly well understood. The development team is familiar with the applications area. The project contains little risk. Long-term predictability is important. The cost of changing requirements, design, and code downstream is likely to be high.

Iterative indicators The requirements are not well understood or you expect them to be unstable for other reasons. The design is complex, challenging, or both. The development team is unfamiliar with the applications area. The project contains a lot of risk. Long-term predictability is not important. The cost of changing requirements, design, and code downstream is likely to be low.

Problem-Definition The problem definition lays the foundation for the rest of the programming process

Problem-Definition A perfect, error free program that isn’t what we needed is useless. We need to make sure we are solving the right problem!

Requirements Prerequisite Requirements  what software system is supposed to do. The first step toward a useful solution. Provides the detail of what a solution should look like. Without them we will miss the mark.

Stable Requirements Ideally requirements wouldn’t change after defined. Studies at IBM and other companies have found that the average project experiences about a 25 percent change in requirements during development. Thus models should minimize the impact of change.

Changing Requirements – minimize impact Assess the quality of your requirements Make sure everyone knows the cost of requirements changes Set up a change-control procedure Use development approaches that accommodate changes Dump the project Keep your eye on the business case for the project

Checklist: Requirements Review your requirements.

Software architecture high-level part of software design the frame that holds the more detailed parts of the design Good architecture makes construction easy. Bad architecture makes construction almost impossible

Typical Architectural Components - Program Organization

Typical Architectural Components - Major Classes

Typical Architectural Components - Data Design

Typical Architectural Components - Business Rules Validation/Eligibility rule example IF The claim has not been submitted within 30 days of the incident THEN Do not settle the claim ELSE Send to manual resolution queue

Typical Architectural Components - User Interface Design

Typical Architectural Components Resource Management Security Performance Scalability Interoperability Internationalization/Localization Input/Output Fault Tolerance

Typical Architectural Components Architectural Feasibility Overengineering Buy-vs.-Build Decisions Reuse Decisions Change Strategy General Architectural Quality

Checklist: Architecture Code Complete 3.5