Upstream Prerequisites “Measure Twice, Cut Once”

“Blueprints” 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”

Importance of Prerequisites 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

Importance of Prerequisites 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

Importance of Prerequisites 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

“What software am I working on?” 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?”

“What software am I working on?” 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?”

“What software am I working on?” 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?”

“What software am I working on?” 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?”

“What software am I working on?” 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?”

“What software am I working on?” 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?”

Problem-Definition Prerequisite “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

Problem-Definition Prerequisite 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

Requirements Prerequisite 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

Problem-Definition Prerequisite 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

Architecture Prerequisite 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

Problem-Definition Prerequisite 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

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

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

How much time to spend on upstream prerequisites 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

Key Points 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