Process Models

Chapter 2 – Process Models

CS485/540 Software Engineering Cengiz Günay

Fall 2014

Günay Ch 2 Process Models Fall 2014 1 / 5 A Generic Process Model

 A task set defines the actual work to be done to accomplish the objectives of a software engineering action.  A list of the task to be accomplished  A list of the work products to be produced  A list of the quality assurance filters to be applied

 A process pattern  describes a processrelated problem that is encountered during software engineering work,  identifies the environment in which the problem has been encountered, and  suggests one or more proven solutions to the problem.  Stated in more general terms, a process pattern provides you with a template [Amb98]—a consistent method for describing problem solutions within the context of the software process.

 Stage patterns—defines a problem associated with a framework activity for the process.  Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice  Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

 Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions …  If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?  Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

Communication project initiation Planning requirement gathering estimating Modeling scheduling analysis tracking Construction design code Deployment test delivery support feedback

increment # n

C o m m u n i c a t i o n P l a n n i n g

M o d e l i n g analys is C o n s t r u c t i o n des ign code D e p l o y m e n t t es t d e l i v e r y f e e d b a c k

delivery of increment # 2 nth increment

C o m m u n i c a t i o n P l a n n i n g

M o d e l i n g analys is C o n s t r u c t i o n des ign c ode D e p l o y m e n t t es t d e l i v e r y delivery of f e e d b a c k increment # 1 2nd increment

C o m m u n i c a t i o n P l a n n i n g M o d e l i n g

analys is C o n s t r u c t i o n des ign c ode D e p l o y m e n t t es t d e l i v e r y delivery of f e e d b a c k 1st increment

project calendar time

QuQuickick plan Communication plan communication

Modeling Modeling Quick design Quick design

Deployment Deployment Construction Delivery of prototype delivery& Feedb &ack Construction feedback Constructionof pofr oprototypetotype

communication

modeling analysis design start

deployment construction delivery code feedback test

Modeling activity

represents the state Under of a software engineering activity or task Evolutionary Models: development Concurrent Awaiting changes

Under review

Under revision

Baselined

Done

• Several commonly‐acknowledged models • All the models aempt to describe “how to get it done” – Linear – Iterave – Evoluonary – Parallel • In real world, hybrids abound – A lile of this, a lile of that – What is the project? Who are the people? When is the deadline? These (and more) are all factors in determining the right process model for the project, team, or company.

CS‐584/Fall 2009/Emory U 2 Traditional Process Models Summary

Basically: Linear vs. incremental/evolutionary. Protoyping: needed when all requirements cannot be obtained without an example. 1st protoype thrown away? Take home message: set milestones for iterative production

Günay Ch 2 Process Models Fall 2014 2 / 5 Still Other Process Models  Component based development—the process to apply when reuse is a development objective  Formal methods—emphasizes the mathematical specification of requirements  AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects  Unified Process—a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

AOSD: aspect-oriented development aspects are horizontal slices across a vertical development process. Example: interfaces, security, persistancy, memory management, etc. Uniﬁed process: nontraditional approch; enter agile computing (Ch 3)

Günay Ch 2 Process Models Fall 2014 3 / 5 The Unified Process (UP)

Eelaborationlaboration

inceptionInception

construction Release transition software increment

production

Inception Elaboration Construction Transition Production Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

Inception phase

Elaboration phase Vision document Initial use-case model Construction phase Initial project glossary Use-case model Initial business case Supplementary requirements Transition phase Initial risk assessment. including non-functional Design model Project plan, Analysis model Software components phases and iterations. Software architecture Integrated software Delivered software increment Business model, Description. increment Beta test reports if necessary. Executable architectural Test plan and procedure General user feedback One or more prototypes prototype. Inc ept i o Test cases n Preliminary design model Support documentation Revised risk list user manuals Project plan including installation manuals iteration plan description of current adapted workflows increment milestones technical work products Preliminary user manual

 Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created.  Highlevel design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked.  Highlevel design review. Formal verification methods (Chapter 21) are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results.  Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results.  Postmortem. Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness.

 Build selfdirected teams that plan and track their work, establish goals, and own their processes and plans. These can be pure software teams or integrated product teams (IPT) of three to about 20 engineers.  Show managers how to coach and motivate their teams and how to help them sustain peak performance.  Accelerate software process improvement by making CMM Level 5 behavior normal and expected.  The Capability Maturity Model (CMM), a measure of the effectiveness of a software process, is discussed in Chapter 30.  Provide improvement guidance to highmaturity organizations.  Facilitate university teaching of industrialgrade team skills.

• Fact 2 The best programmers outperform the worst by a factor of 28*

• Data – Decades‐old studies led to the original performance rao – Widely accepted, widely ignored! – Some interesng reading on the topic: • hp://www.devtopics.com/programmer‐producvity‐the‐tenﬁnity‐factor/ • hp://ibmsystemsmag.blogs.com/idevelop/2008/09/looking‐for‐way.html • hp://www.joelonsoware.com/arcles/FieldGuidetoDevelopers.html • hp://www.arma.com/weblogs/viewpost.jsp?thread=4738

– An excellent book on the topic, widely regarded as the best: • Peopleware: Producve Projects and Teams by Tom DeMarco and Timothy Lister.

*From Robert Glass, “Facts & Fallacies of Soware Engineering”

CS‐584/Fall 2009/Emory U 4 Student Performance Data

• From Prof. Eisenstat at Yale, results of CS‐323 course • Courtesy of Joel Spolsky: – hp://www.joelonsoware.com/arcles/HighNotes.html

CS‐584/Fall 2009/Emory U 5 Improving Performance

• Process – Fit the process to the project and the team – Understanding‐Planning‐Developing‐Tesng‐Documenng – Waterfall, Evoluonary, Agile, Hybrid, etc.: Select, know, use • Tools – IDEs (Visual C++) and Frameworks (Rails) – Make/Build tools & scripts (Ant) – Automated tesng tools (Junit) • Teams – Pair programming + solo programming – Code reviews & walk‐throughs – Analyzing examples of quality code • Workplace – Opon for “Do‐Not‐Disturb” – Ergonomics overall • An interesng discussion is here: – hp://www.nerdymusings.com/LPMArcle.asp?ID=11

CS‐584/Fall 2009/Emory U 6 Integrated Development Environments (IDEs)

Beneﬁts Syntax highlighting – automatic checking Syntax completion – keeps consistency, no typos Project environment – saves, searches many ﬁles Uses make/build tools Knows dependencies Integrated reference manuals Better organization of code Support for version control Support for complex builds Debugging Based on the language, there are many choices (see Wikipedia page)

Günay Ch 2 Process Models Fall 2014 4 / 5 Software Process Tools

Trello: http://trello.com Simple to use Pivotal Tracker: https://www.pivotaltracker.com (video?) Highly recommended Free educational edition Rally: http://www.rallydev.com/ Simple to use Free for one project with up to 10 users Target Process: http://www.targetprocess.com (video) More complex features, kanban board, custom processes Free up to 5 users Version One: http://versionone.com Free for one project with up to 10 users

Günay Ch 2 Process Models Fall 2014 5 / 5