Upstream Prerequisites

1. Upstream Prerequisites “Measure Twice, Cut Once”

2. Before construction, preparations must be made. • These preparations are custom built to the projects specific needs • The success or failure of the project is determined before the construction begins. • “Measure twice, cut once”: construction can account for up to 65% of total project cost. “Blueprints”

3. High quality practices = high quality software. • Quality start: Focus on planning • Quality middle: Focus on construction • Quality End: Focus on testing • The goal of preparation is risk reduction. • Most common project risks are poor requirements and planning. • Preparation for construction is not an exact science. Importance of Prerequisites

4. Causes of Incomplete preparation • Developers with lack of expertise. • “I want to code now!!!!” : Coding ASAP • “I want to SEE code now!!”: Unsympathetic managers • Refuse, Trick, Educate, Relocate • Educate people about the development process. • Appeal to logic • Use Analogies • Show the data Importance of Prerequisites

5. Boss Test • We’d Better start coding right away because we’re going to have a lot of debugging to do. • We haven’t planned much time for testing because we’re not going to find many defects. • We’ve investigated requirements and design so much that I can’t think of and major problems we’ll run into during coding or debugging. Importance of Prerequisites

6. Different kinds of software projects require different balances between preparation and construction. • Projects tend to fall into development styles. • Business Systems • Mission-Critical Systems • Embedded Life- Critical Systems “What software am I working on?”

7. Business Systems • Internet site, Games, Management information systems, Payroll • Planning is interleaved with construction • Less quality assurance activities, done in house. • Informal “What software am I working on?”

8. Mission –Critical Systems • Embedded software, Software tools, Web services • Up- front planning and semi-formal requirements • Informal check-ins while coding • Testing with a separate group. (In house always done) “What software am I working on?”

9. Embedded Life- Critical Systems • Avionics software, Medical devices, Operating Systems • Formal and extensive planning, requirements, and design • Formal check-ins while coding • Extensive out of house testing. • Everything must go correctly “What software am I working on?”

10. Sequential approach • Upfront prerequisites • Requirements are stable • Design is straightforward • Low risk project • Long term predictability • High change cost. “What software am I working on?”

11. Iterative approach • As you go prerequisites • Unclear requirements • Complex design • Lots of risks • Long term is not important • Low change cost. • Adapt approaches based on your specific project. “What software am I working on?”

12. “Mission Statement” • Problem definition defines what the problem is without a reference to a solution. • If it sounds like a problem it is a good problem definition. • “GGC students have a hard time managing all they have to do at the school.” Problem-Definition Prerequisite

13. Problem definition lays the foundation of the programming process. • State the definition in the users language and not in computer terms. • The best solution may not require programming. • Exception: When it deals with computers • Programming tools are buggy, compile times are slow, ect. Problem-Definition Prerequisite

14. Requirements describe in detail what a software system is supposed to do. • First step toward a solution. • Allows the user to determine system functionality. • Minimizes changes mid project. • Stable requirements don’t really happen but must be strived for. • On average a 25% change in requirements is bound to happen. Requirements Prerequisite

15. How to handle requirement changes. • Requirement checklist at the end of each section • Make the change cost known to everyone • Set up a change-control procedure • Use development approaches that can accommodate changes. • If all else fails: Dump the project. (Or at least think about it) Problem-Definition Prerequisite

16. Software architecture is the high-level part of software design. • The frame that holds the detailed parts together. • A single document that defines constraints that apply system wide. • Provides guidance to programmers because it is detailed to the skills of the coders. Architecture Prerequisite

17. Architectural Components • Program Organization • How many subsystems, what are the building blocks • Major Classes • Data Design • Major files and tables • Business Rules • User Interface Design • Input/Output Problem-Definition Prerequisite

18. Architectural Components Con’t • Resource Management • Security • Performance • Scalability • Growth? • Interoperability • Localization • Error Processing Problem-Definition Prerequisite

19. Architectural Components Con’t • Fault Tolerance • Architectural Feasibility • Overengineering • Buy vs Build • Reuse Decisions • Change Strategy • General Architectural Quality Problem-Definition Prerequisite

20. 10 to 20% of its effort and 20 to 30% of its time. • Allow time to consult the requirements and for revisions. • Treat requirements as its own project if necessary. • Smaller the project, less time necessary. How much time to spend on upstream prerequisites

21. Main goal is risk reduction • Educate everyone about the development process. • Different projects means different prerequisites. (Iterative vs Sequential) • Problem definition • Requirements • Architectural design Key Points