CSC 395 – Software Engineering Lecture 4: Software Process

CSC 395 –Software Engineering

Lecture 4:

Software Process

Today’s Lecture

Discuss why people care about software lifecycles What goes on in each step What this has to do with the Unified Process

Introduce dominant organizational methodology

Waterfall Model

Basis of almost all reasonable attempts at software engineering Grows from natural flow of work Proven to deliver good results Very good understanding its workings Extensible & modifiable for individual

circumstances Open for redefinition as times change

Why a Requirement Phase

Deadline Distribution requirements Portability Reliability Responsiveness Cost limitations

Clients often solicit bids to get lowest price Want to get client in for future updates

Deliver combination of what client needs & wants

Requirements

Client unclear or unable expressing desires Discover problem’s application domain

Rarely expressed in stack, list, hash table Specialize in area with high solution reuse -or- Software professionals must be polymaths

Build business model justifying project Need to show investment worth time & money

Work with client in concept exploration

Why an Analysis Phase

Requirements Phase: “Boo-boo” or “Owwie”

Analysis Phase: “Contusion”

Analysis Workflow

Requirements put in client’s language May be imprecise, inconsistent, or use terms

specific to application domain Deals with end product and not how we will get

there Analysis workflow translates requirements

Place in terms development team understands Remove ambiguities & contradictions Vital for eventual testing and maintenance

Client signs off on specification document

Software Project Management Plan

Create after specification document approved Plan for how the project will go

Plan should include all important details: Costs Duration Deliverables Milestones

Results of analysis workflow drives remainder of project Where should numbers for this plan come from?

Design Workflow

Where the developers take over Translate specifications into something that

can be implemented Architectural design divides specifications

into modules May be objects, packages, concepts, windows Process is very hard with few simple rules

Detailed design divides architectural design Selects algorithms & data structures

Design Deliverables

Design is an incredibly difficult process Needs to be specific enough to implement Should be open enough to be added to Companies may try reusing single template

Excellent process when they find good one Limits markets into which they can go, however

Document all ideas & save with deliverables Provides convenient backstop when stuck Helps with implementation & maintenance

Implementation Workflow

Only now does the coding begin Often newest & least trained employees Rarely requires contact with client Easiest skill to teach requiring least training Guess which jobs are most often outsourced?

Excellent coders, however, are valued Create easily reusable components or artifacts Solve tricky & difficult algorithmic issues Optimize the small portion of code most

commonly used

Where’s the Testing?

Testing occurs throughout the project Always check that project is on correct path Every day bug lingers increases odds of it never

being fixed By the time we get to implementation, cost of

finding and fixing errors is very, very high Outside team performs final checks on

artifacts Lack any involvement in development process Bring new set of ideas for how things should work

How Does Testing Occur?

Ultimately, we need to test against our agreement with the client Highly unlikely this involves Exceptions or JPanes

Testing therefore relies on traceability-- ability to trace a decision back to the initial requirements

Traceability starts during requirements Involves meticulous detail keeping afterward Finds where errors originate and helps in fix Explains to client how they asked for final product (Also explains to boss how it is not your fault)

Artifact Testing

All artifacts -- items surviving across workflows -- are tested against requirements Often include reviews for fresh sets of eyes Outside reviews have huge impact on efficiency

Requirements & SPMP often involve client Client generally uninvolved in most other checks

Implementation includes many checks

Implementation Tests

Unit tests check components during coding Integration tests test components play nice Product tests make sure we can be proud

Alpha & beta tests may preview the final test Provides clients with preview of the final product

Acceptance tests find out whether the client approves Usually rolled out across the client site over time May be first test using real data

Postdelivery Maintenance

Money is earned & lost after product delivery Clients often stop paying at this point We still expect them to work, however Over 50% of a product’s budget spent here

Postdelivery is worst time to fix bugs Clients may not be able to describe problems Bug fixing is at its most expensive May be due to simple lack of documentation

Important to keep tests for regression testing Prevent new bugs while fixing old ones

Retiring Software

Similar to sighting a Yeti or Bigfoot Companies loathe giving up on investment

Only occurs when cost of support too high May also happen if products loses clients Usually companies force upgrades or Chapter 11

Unified Process

Dominant method by which object-oriented software processes are analyzed & followed Named as it unifies “Three Amigos” ideas Relies upon UML to perform many of the

analyses Orthogonal to approach of “Gang of Four”

Used by nearly all software engineers Including the book, the instructor, & CSC395 Agile processes the only serious alternative now But this will eventually be replaced

Unified Process

Project also divided up into 4 phases Inception, Elaboration, Construction, Transition Phases follow the business view of a project

Creates grid of technical & business flow by which we can discuss development Also highlights that people are involved in

different workflows at the same time Means of splitting out teams & analyzing work

Inception Phase

Investigates if project should be undertaken Does the business model make sense? Can we complete project on time & what if it’s late?

Examinees possible risks for project Risks may be technical, architectural, or

engineering based Investigates ways by which risks can be mitigated

Develops feel for environment Also does work for other workflows

Implementation limited to proofs-of-concept

Elaboration Phase

Refine work done in inception phase Refine the requirements Perform the vast majority of the analysis Start the design workflow

Phase elaborates & enhances work from inception phase At end of phase, suits disappear for a while Majority of workload now belongs to the geeks

Construction & Transition

Construction phase belongs to technical side Google projects often stay in this phase Often ends when software goes β (beta)

Transition phase moves software to clients Driven by results from beta tests Ends with project released and in postdelivery

maintenance

Improving Software Development

Unified process focused on understanding software engineering Understanding process is first step Does nothing to quantify how software developed

Several systems developed to fix this ISO 9001 establishes base level of quality &

ISO 9000-3 applies ISO 9001 to software Many companies use ISO registered suppliers only ISO registration establishes base quality level

ISO/IEC 15504 & CMM

Also known by original acronym: SPICE Initiated by British MoD Unlike ISO 9000, looks to improve process Extends & improves ISO 9000 and CMM

Capability Maturity Model Placed by American DoD at SEI at CMU Extended to relate to all aspects of software Rates establishments and helps them improve

Levels of CMM

Nicknames1. Heroic

2. Repeatable

3. Defined

4. Quantifiable

5. Predictable Note: Level 5

does not exist

Is CMM Worth It

Hughes Aircraft spent $500K on improvement Level 3 saves $2M/year over level 2

Raytheon moved from level 1 to level 3 Productivity doubled Return of $7.70 per dollar invested

TCS (India) spent 6 years with CMM Estimation errors decreased from 50% to 15% Review effectiveness doubled (40% 80%)

Motorola found level 2 better than level 3

For Next Lecture

Friday’s lecture will Discuss teams, teams, and more teams Give you ideas for running the project Provide chance to discuss material from this week Get head start on homework handed out Friday