Presentation is loading. Please wait.

Presentation is loading. Please wait.

CPSC4175 Intro to Software Engineering Neal Rogers Common Processes Elements.

Similar presentations


Presentation on theme: "CPSC4175 Intro to Software Engineering Neal Rogers Common Processes Elements."— Presentation transcript:

1 CPSC4175 Intro to Software Engineering Neal Rogers Common Processes Elements

2 Lesson: Common Process Elements Strategic Objective: To understand components common to all software processes Tactical Objectives: –to understand what a life cycle is –know the common types of life cycles –know how the common lifecycles affect the software production process –be able to select a lifecycle for a sample problem Immediate-use skills: –life cycles Support material: –Readings: The Spiral Model as a Tool for Evolutionary Acquisition

3 Further information: –Boehm, B A spiral model of software development and enhancement. Computer, 21, 5. pp –Royce, W Managing the development of large software systems. Proceedings of IEEE WESCON. IEEE. –Thayer, R Software engineering management: A top-down view. Software Engineering Management. IEEE Press. pp –Pressman, R Software Engineering: A Practitioner’s ApproachI, 5 th ed. McGraw Hill.

4 Software engineering raison d’être Process foundations Common process elements Conceptual design Size estimation Task decomposition Scheduling Measurements Reviews Technical templates Scaling up Misc processes Process descriptions Infrastructure Retrospective Syllabus Process commonality Lifecycle models  foundation  engineering activities  lifecycle definition  models  ad hoc  linear  prototype  evolutionary  component-based  transform

5 Process Commonalities NeedSolution Identify Synthesize Articulate Interpret Roles Lifecycle model Product model Property model Success model Infrastructure model w/ known characteristics

6 Process Commonalities NeedSolution Identify Synthesize Articulate Interpret Roles Lifecycle model Product model Property model Success model Infrastructure model w/ known characteristics

7 Process Commonalities Lifecycle model –tasks needed to produce a solution –purpose: to identify how the pieces of the development puzzle fit together –more about this in a minute …

8 Process Commonalities Product model –mechanisms to produce an artifact in a specific form –purpose: to ensure that the product contains what it should (and doesn’t contain what it shouldn’t) –examples configuration management –configuration identification –configuration control –configuration status accounting –configuration auditing system/software architecture language-specific logistics

9 Process Commonalities Property model –mechanisms to attain a solution with desired characteristics –purpose: to ensure that the product is “engineered” –examples planning, scheduling, costing security interoperability reuse methodology employment

10 Process Commonalities Success model –mechanism to assure and assess “correctness” –purpose: V&V verification: “are we building the product right” validation: “are we building the right product” –examples proof of correctness formal review walkthrough audit certification testing (unit, integration, system, etc) process integrity

11 Process Commonalities Success model (con’t) SystemReqDesignCodeTest Deploy PMRSRRSSRPDRCDRTRRFCAPCAFQT

12 Process Commonalities Infrastructure model –fundamental mechanisms needed to carry out a project –purpose: to permit all engineers to engineer –examples tools training administration quality assurance

13 Process Commonalities NeedSolution Identify Synthesize Articulate Interpret Roles Lifecycle model Product model Property model Success model Infrastructure model w/ known characteristics

14 Lifecycle Models Foundation –a process strategy is required when a system is too large to be built in one piece it must then be partitioned into elements these elements must then be developed the developed elements are then integrated into the finished system –the strategy: define the smaller elements establish the order in which they are developed establish the way in which they are integrated

15 Lifecycle Models Foundation (con’t) –software engineering activities to be managed: identification synthesis articulation interpretation –software engineering models... determine the order in which the activities are performed a.k.a. lifecycle (hopefully) give engineering discipline to production process

16 Lifecycle Models Foundation (con’t) –models (con’t) characteristics: –pros »organized »management visibility –cons »no unified theory »rigidifies thinking (changes difficult to handle) »assumes users know what they want

17 Point of Discussion ad hoc –code-and-fix linear –waterfall prototype –prototype evolutionary –incremental –synchronize and stabilize –spiral component-based –OO fountain transform –transform

18 Ad hoc Concept: quickly get code on the road Example: Code-and-fix Pattern –repeat code fix –until working Can you say “Level 1”?

19 Ad hoc … code-and-Fix Characteristics –advantages no overhead requires little expertise –disadvantages no management visibility errors seldom detected in advance Used for –small throwaway programs –fluid systems (where may not be cost effective to formally engineer or document)

20 Linear Concept: step-by-step construction Pattern –analyze then –design then –code then –test then –maintain Example: Waterfall –History Royce 1970 –what he said: phased development –what we heard: phase after phase development used widely in procurement

21 Linear … Waterfall Characteristics –pros simple –cons specification vs aspiration unrepresentative of real life assumes specs frozen guidelines for swimming upstream vague

22 upfront knowledge certain »req. »methods »arch »resource avail stableexperiencedtraditional hierarchy guidelines on: »next phase »backup »stopping »req creep »stds technology: stable ethics: audits Success criteria PlanningOrganizingStaffingDirectingControllingMisc Linear … Waterfall

23 Prototype Concept: development process defines requirements Pattern –analyze –repeat design (rapidly) code(rapidly) test(with user) –until system adequate –complete and release Example: Prototype –Assumption user can not specify all requirements development process will reveal requirements

24 Prototype Used for –HCI –research –software structure ill-defined –requirements ill-defined

25 Prototype Characteristics –Pros gaps in client-developer understanding discovered difficult-to-understand-services refined limited working system at each iteration specs for quality system –Cons early iteration may be used as real system users may not use in same way as real system may lead to unrealistic delivery expectations questionable legal contractual vehicle validation demonstrates adequacy, not conformance to spec possible inefficiencies and maintenance difficulties

26 Prototype flexibility in scope, schedule, cost User involvement flexibleuser-friendly disciplined non- traditional hierarchy stringent cost monitoring stopping criteria available requirements creep containment strong configuration management technology: architecture stable ethics: user willing to assume risk Success criteria PlanningOrganizingStaffingDirectingControllingMisc

27 Iterative Concept: build solution in parts General pattern –analyze (to desired level of abstraction) –design (to desired level) –code (to desired level) –test –deliver –repeat until complete Example 1: Incremental waterfall –overlapping waterfall –subproject waterfall –staged waterfall

28 Iterative … synchronize and stabilize Example 2: Synchronize and stabilize Pattern –analyze –specify as “feature sets”, sort sets by criticality –for the each feature set loop diurnal loop –build feature set –synchronize »integrate »fix –exit when feature set built to satisfaction end loop stabilize (baseline) –end loop

29 Iterative … synchronize and stabilize Characteristics –Pros repeated synchronization yields piece-wise integration early insight into inter-component interaction working software early –Cons working software early delicate team dynamics

30 Iterative … synchronize and stabilize flexibility in scope, schedule, cost User involvement flexibledisciplined dedicated non- traditional hierarchy stringent cost monitoring stopping criteria available strong configuration management technology: architecture unstable ethics: early delivery Success criteria PlanningOrganizingStaffingDirectingControllingMisc

31 Iterative … spiral Example 3: Spiral Pattern Process (Win-win spiral) –repeat identify next-level stakeholders identify stakeholders’ win conditions reconcile win conditions; establish objectives, constraints, alternatives evaluate product and process alternatives; resolve risks define next level of product and process validate product and process –until (review decision = stop) or (project = complete)

32 Iterative … spiral 1. identify stakeholders 2. identify win conditions 3. reconcile win conditions; establish objectives, constraints, alternatives 4. evaluate alternatives 5. define next level 6. validate 7. review, commit

33 Iterative … spiral concurrent determination of key artifacts each cycle includes objectives, constrains, alternatives, risks, review, and commitment to proceed level of effort driven by risk considerations degree of detail driven by risk considerations use of anchor point milestones: –life cycle objectives –life cycle architecture –initial operational capability emphasis on system and life-cycle activities and artifacts

34 Iterative … spiral Characteristics –Pros flexibility “systems” approach provides termination condition objectives vs requirements answers “what should we do next” addresses risk –Cons contract acquisition nightmare relies on project team educated in risk management

35 Iterative … spiral previous experience flexibility in schedule and cost stable for duration of spiral sweep flexibility to vary task nature between spiral sweeps risk conscious non- traditional or traditional guidelines on number of spirals technology: need not be stable Success criteria PlanningOrganizingStaffingDirectingControllingMisc

36 Component-based Concept: reuse General pattern –identify candidate components –look up components in library –extract components if available –build components if not available –put new components in library Example: Fountain OO

37 Component-based … OO fountain relies on depth and breadth of software pool flexibleknowledge of software pool non- traditional or traditional guidelines for fit-for- reuse heavy reliance on previously developed technology Success criteria PlanningOrganizingStaffingDirectingControllingMisc

38 Transform Concept: automation General pattern –analyze –repeat specification translate to code validate –until system adequate

39 Transform … RAD Example 3: Rapid Application Development Pattern: Business modeling Data modeling Process modeling Application generation Testing & Turnover days … …

40 Transform Characteristics –Pros modify upstream artifact (such as specs or models), not code no design time –Cons tracking costs difficult cost estimation difficult auto transform not always available

41 Problem domain well defined Previous experience in costing, scheduling stabletheoretical experienced non- traditional or traditional risk abatement if transform not possible technology: must be available Transform Success criteria PlanningOrganizingStaffingDirectingControllingMisc

42 Summary Key Points A product with integrity requires integrity-based processes Software engineers are faced with projects of multiple levels of complexity: lifecycle modeling is a way of dealing with complexity Lifecycles determine sequence of activities Common lifecycle patterns are ad hoc, linear, prototype, iterative, component-based, transform Topics Process commonality Lifecycle models  foundation  engineering activities  lifecycle definition  models  ad hoc  linear  prototype  iterative  component-based  transform

43 View of software engineering NeedSolution Roles Lifecycle model Product model Property model Success model Infrastructure model w/ known characteristics Identify Synthesize Articulate Interpret temporal ordering form characteristics goodness support

44 Software process model processes definition –Prescriptive descriptions of tasks required to develop a software solution examples –IEEE 1074 –MIL-STD-2167A –MIL-STD-498 –Extreme Programming –Crystal –Cleanroom process models definition –Descriptive characteristics of an effective development effort examples –ISO 9001 –CMM –CMMI –SPICE –Bootstrap SOFTWARE PROCESS instantiate as


Download ppt "CPSC4175 Intro to Software Engineering Neal Rogers Common Processes Elements."

Similar presentations


Ads by Google