1 / 21

Upstream Prerequisites

Upstream Prerequisites. “Measure Twice, Cut Once”. 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.

bairn
Télécharger la présentation

Upstream Prerequisites

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related