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

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

3. 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.

4. 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? “

5. 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

6. 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

7. Cost of Fixing Defects

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

9. Sequential Approach

10. 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

11. Iterative approach

12. No true waterfall
Activities will overlap to some degree

13. Activity overlap varies

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

15. 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.

16. 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.

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

18. 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!

19. 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.

20. 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.

21. 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

22. Checklist: Requirements
Review your requirements.

23. 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

25. Typical Architectural Components - Program Organization

26. Typical Architectural Components - Major Classes

27. Typical Architectural Components - Data Design

28. 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

29. Typical Architectural Components - User Interface Design

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

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

32. Checklist: Architecture
Code Complete 3.5