Software Engineering Review - Software Process

IF3250 Proyek Perangkat Lunak Rekayasa Perangkat Lunak-Review
Sem I 2013/2014
Pendahuluan

Software Application Domain Software Engineering

Definitions System/Product Engineering Hierarchy From Requirements to User Acceptance Test Waterfall, Incremental, Iterative, Spiral, etc Unified Process Agile development
Software Development Process

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya
Software Application Domains

System software Application software Engineering or Scientific Software Embedded software Product-line software (includes entertainment software) Web-Applications Artificial intelligence software
IF3250-Proyek Perangkat Lunak (Informatika ITB)
Software Engineering
Software engineering is the establishment of sound engineering principles in order to obtain reliable and efficient software in an economical manner. Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. Software engineering encompasses a process, management techniques, technical methods, and the use of tools.
Software Engineering (2)
System Engineering Hierarchy

Business or product domain
World View
domain of interest Domain View system element Element View
Detail View
The Product Engineering Hierarchy

The Complete Product
Requirement Engineering (World View)
capabilities
Hardware
Software
Component Engineering (Domain View)
processing requirement
Data Function Behaviour
Analysis and Design modeling (Element View)
program component
Construction & Integration (Detail View)
Requirements Analysis
Requirements Gathering
User Requirements
System/ Technical/ Hardware Requirements
Business Requirements and/or Business Rules
Hardware Requirements
10
Software Requirements
Requirements Decomposition
Complete Requirements
R1
R2
R3
R1.1
R1.2
R1.3
R2.1
R2.2
R3.1
R3.2
R3.3
11
Global Design and Detailed Design

Complete Requirements R1 R2 R3
R1.1
R1.2
R1.3
R2.1
R2.2
R3.1
R3.2
R3.3
D1.1
D1.2
D1.3
D2.1
D2.2
D3.1
D3.2
D3.3
DD1
DD2
DD3
DD4
DD5
DD6
DD7
DD8
DD9
DD10
12
From Design to Coding

R1 R1.1 D1.1 DD1 DD2 R1.2 D1.2 DD3 R1.3 D1.3 DD4 R2.1 D2.1 DD5
R2 R2.2 D2.2 DD6 R3.1 D3.1 DD7
R3 R3.2 D3.2 DD8 DD9 R3.3 D3.3 DD10
C1
C2
C3
C4
C5
C6
C7
C8
C9
C10
13
Unit Testing
R1 R1.1 D1.1 DD1 C1 T1

14
R2 R1.3 D1.3 R2.1 D2.1 DD5 C5 T5 R2.2 D2.2 DD6 C6 T6 R3.1 D3.1 DD7 C7 T7
R3 R3.2 D3.2 DD8 C8 T8 DD9 C9 T9 R3.3 D3.3 DD10 C10 T10
R1.2 D1.2 DD2 C2 T2 DD3 C3 T3
DD4 C4 T4
Integration Test
Package1 Package2 Package3 Package4
C1 T1
C2 T2
C3 T3
C4 T4
C5 T5
C6 T6
C7 T7
C8 T8
C9 T9
C10 T10
Integration Test1
Integration Test2
Integration Test3
Integration Test4
15
User Acceptance Test

Complete Program
Package1
Package2
Package3
Package4
C1 T1
C2 T2
C3 T3
C4 T4
C5 T5
C6 T6
C7 T7
C8 T8
C9 T9
C10 T10
Integration Test1
Integration Test2
Integration Test3
Integration Test4
User Acceptance Test

16
Software Development Life Cycle
17
Waterfall Model
Requirement Engineering Requirement Analysis Global and Detailed Design Implementation/ Coding Deployment
18
Maintenance
Prototyping Model
19
Incremental Model
20
Rapid Application Development Model

21
Spiral Model
22
Boehms Spiral Model
23
Concurrent Development Model
24
V Model
User Acceptance Testing Integration Testing
User Requirements
Global Design
Detailed Design
Unit Testing
Coding
25 30-Aug-13
IF3250-Proyek Perangkat Lunak (Informatika ITB) SW Dev Methodologies/Bayu
Hendradjaya
Component Based Development
26
Domain Analysis
SW Arch Development
Reusable Component Development
Domain Model
Structural Model
Application Domain Development

Component Qualification Analysis Architectural Design Component Adaptation Component Composition Component Engineering
Repository Reusable Artifacts/ Components
CBSE
Component Update
Application Software
Component Development
27
IF2036 RPL - IF ITB
Testing
The Unified Process
Consists of A set of principles A collection of processes to use as a starting point Customizable process framework and knowledge base Use-case driven, architecture centric, iterative, and incremental software process Phases

28
Inception phase (customer communication and planning) Elaboration phase (communication and modeling) Construction phase Transition phase (customer delivery and feedback) Production phase (software monitoring and support)
Iteration and Workflow

Core Workflows
Requirements Inception Elaboration
Phases
Construction Transition
An iteration in the elaboration phase Analysis
Design
Implementation
Test
P r e li m i n a r y I te r a t io n ( s ) it e r. #1 it e r. #2 it e r. #n it e r. #n+1 it e r. # n +2 it e r. #m it e r. #m +1
29
It e r a tio n s
IF2036 RPL - IF ITB
Iteration and Workflow
IBM Software Group-Rational Unified Process 30

Agile Software Development
31
Agile Manifesto
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Agile
Traditional
The items on the left is valued more than the right items.
32
IF2036 RPL - IF ITB
What is Agile?
An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.
Core principles

Fits just right process Continuous testing and validation Consistent team collaboration Rapid response to change Ongoing customer involvement Frequent delivery of working software
33
An Agile View of Process
Compromise between Conventional Software Development to a Software Project
Represents a reasonable compromise between conventional software engineering for certain classes of software and certain types of software projects
Deliver a successful system quickly Stresses on Continuous Communication and Collaboration among developers and customers Embraces a philosophy that encourages:

customer satisfaction, incremental software delivery, small project teams (composed of software engineers and stakeholders), informal methods, and minimal software engineering work products
Stress on-time delivery of an operational software increment over analysis and design
IF2036 RPL - IF ITB
34
12 Principles

Highest priority: user satisfaction Welcome changing requirement Deliver working software frequently Business people and developers work together daily Build around motivated individuals Face-to-face conversation Working software: primary measure of progress Promote sustainable development Continuous attention to technical excellence and good design Simplicity is essential Self-organizing team Tune and adjust team behavior at regular intervals
IF2036 RPL - IF ITB
35
Challenges in Agile
Compliance requirement
Low risk Critical, Audited
Geographical distribution
Co-located Global
Entrenched process, people, and policy

Minimal Significant
Agile Development
Application complexity
Simple, single platform Complex, multi-platform
Organization distribution (outsourcing, partnerships)

In-house Third party
Team size
Under 10 developers 100s of developers
Degree of Governance
Informal Formal
36
Agile Process Models

Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Systems Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM) Agile Unified Process (AUP) Essential Unified Process (EssUP) Open Unified Process (OpenUP) Velocity tracking
* SEPA 6th ed, Roger S. Pressman 37
IF2036 RPL - IF ITB

Agile Methodology is develop based on iterative and incremental development It is based on feedback from the clients. In this methodology the requirements and solutions evolve through collaboration between self-organizing, cross-functional teams who work in close liaison with the clients. It promotes evolutionary development, adaptive planning and encourages rapid and flexible response to change. It is suitable for

Product (and less for services) Smaller to medium sized products A team of 100 members was also noted to be a success
Development teams for such products is ranging from 5 to 20-20 members
38
Agile vs. Other Methodologies

The requirements from the client is collected iteratively and in an evolutionary manner. Each stage, including the requirement analysis stage, needs to be completed and finalized, before moving on to the next stage. Less documentation
Because of smaller team size, extensive informal communication makes high quality software development feasible. But it would be difficult to ensure high quality in larger projects, due to this methodological limitation, which is mostly made by choice to ensure faster delivery of software projects.
40

Agile Methodology is develop based on iterative and incremental development It is based on feedback from the clients. In this methodology the requirements and solutions evolve through collaboration between self-organizing, cross-functional teams who work in close liaison with the clients. It promotes evolutionary development, adaptive planning and encourages rapid and flexible response to change. It is suitable for

Product (and less for services) Smaller to medium sized products A team of 100 members was also noted to be a success
Development teams for such products is ranging from 5 to 20-20 members
41
Two dimensions, four (or more) process styles

Waterfall
Few risk, sequential Late integration and testing
Relaxed
Little documentation Light process Low ceremony
Disciplined
Well-documented Traceability Change Control Board High ceremony
Iterative
Risk driven Continuous integration and testing
42
Agile Sweet Spot

Waterfall
Few risk, sequential Late integration and testing
Relaxed
Little documentation Light process Low ceremony
Disciplined
Agile
Agility at Scale
Iterative

43
Unified Process (Rational Unified Process)

Waterfall Common language Common Practices Oversight Flexible resourcing Reuse Relaxed
Little documentation Light process Low ceremony Few risk, sequential Late integration and testing
RUP Framework
Disciplined
OpenUP
RUP Light
RUP for large-scale SOA
RUP for Sys Eng
Iterative
44
Common Difficulties (1)
Process Weight and Perfection
Too much formality / too many artifacts

Only produce the artifacts that add value, minimize formality if possible Use informal resources (brief document templates) and not formal resources When in doubt of value, dont do it You can improve upon things later on move on Focus on phase objectives. E.g. Inception is NOT about describing all requirements in detail
Analysis Paralysis

45
Life Cycle
Following a waterfall process, versus RUPs iterative processes

Look beyond a flawed 5-minute perception of what RUP phases are about Produce working (tested) code every iteration (exception maybe Inception) Problem: Complete misunderstanding of what Elaboration is about RUP focuses on rapidly producing an Executable Architecture 10-20% of code, critical capabilities implemented, not a lot of paper design Attack risks early, or they attack you Hard on you now, but makes life easier later
Big Upfront Architecture

Save the tricky part for later

46
Organization and Mentality
Functional, Specialized Organization

Teams of generalists and multitasking experts No place for I only do <X> mentality Unlikely to build the right product A lot of waste Change enables improvement Document changes in development case
No customer feedback until a late beta

No willingness to change things
Your process is stagnant versus evolving
47
Development Approach
Functional, Specialized Organization

Teams of generalists and multitasking experts No place for I only do <X> mentality Unlikely to build the right product A lot of waste Change enables improvement Document changes in development case
No customer feedback until a late beta

No willingness to change things
Your process is stagnant versus evolving
48
Unified Process in a Nutshell (case study: OpenUp)
Influence RUP XP AMDD
Scrum Eclipse Way RUP
RUP DSDM
49
Executing an Iteration (sample)
Iteration planning
A few hours
Stable weekly build Stable iteration Iteration review / Retrospective build

A few hours
A few days
Upfront planning and architecture

50
Continuous micro-increments / bug-fixing / builds
Continuous bug-fixing / micro-increments / builds
Managing Work Items List

High Priority
Each iteration implements the highest-priority work items New work items can be added at any time Work items can be reprioritized at any time
High-priority work items should be well-defined
Low-priority work items can be vague

Low Priority
Work items can be removed at any time
Work Item List
51
Project Life Cycle
52
Implementing Unified Process using Agile Principles
53
Agile Development with Rational Unified Process (RUP)

Follow RUPs agile practices
Shared vision Regular delivery of working software Active stakeholder participation Test-Driven Development (TDD) Continuous builds Early and frequent system-level testing Just enough process
Add additional agile practices:

Self organization Micro increments managed by work items Iteration Lifecycle (what do you do at what week within an iteration)
Leverage RUPs content around agility at scale

Guidance on how to deal with complexity drivers
54
Customize RUP
Start with a small out-of-the-box process
RUP for Small Projects / RUP for Maintenance Make it smaller by deselecting content packages not needed Remove artifacts not needed (additional support for this in RMC 7.2) Choose to publish only the delivery process, versus entire configuration A 1-3 page description of the process you use Reference your RUP process and other sources, no need to duplicate info Update development case after each iteration review / retrospective Update delivery process if significant changes
Customize it to meet your needs

Publish the (delivery) process
Leverage Development Case

Improve the process every iteration

55
Iterative Development Phases

Major Milestones
Inception
Elaboration
Construction
Transition
Inception: Agreement on overall scope

Vision, high-level requirements, business case Not detailed requirements Baseline architecture, key capabilities partially implemented Not detailed design Develop a beta release with full functionality
Elaboration: Agreement on design approach and mitigation of major risks

Construction: Agreement on complete operational system
Transition: Validate and implement solution
Stakeholder acceptance, cutover to production
56
Inception: Know What to Build

Typically one short iteration Produce vision document and initial business case
Only produce what has value Initial use-case and (optional) domain models (10-20% complete) Focus on what is required to get agreement on big picture Reduce risk by identifying key requirements Acknowledge that requirements will change
Develop high-level project requirements

Manage project scope

Manage change, use iterative process
Produce conceptual prototypes as needed
57
Example: UCs in Inception

Inception: 5 people, 2 weeks (for a 6 month project) => 400 hours 2 hour joint UC workshop with key stakeholders ~10 hours
15 UCs, 4 critical, 5 important, 6 less important Includes some potential UI mockups
Outline UCs: 4 hours per critical, 2 per important, and 1 per less important ~ 32
UC walkthrough: 1 hour per important UC, 30 min for all others x 5 people ~ 48 hours
Focus is on extended team converging on what application they are building, not to lock down on requirements
Further updates based on walkthrough ~ 10 hours Discussion: Is it worth to spend ~100 hours on getting concurrence on an initial UC Model?
Note we know the UC model will evolve as project progresses
58
Elaboration: Know How to Build It by Building Some

Elaboration can be a day long or several iterations Balance mitigating key technical and business risks with producing value (tested code) Detail ~top 3rd most essential requirements (so you can estimate and prioritize) Produce (and validate) an executable and stable architecture

Define, implement and test interfaces of major components. Partially implement some key components. Identify dependencies on external components and systems. Integrate shells/proxies of them. Roughly 10% of code is implemented. 20% of use cases drive 80% of the architecture
Drive architecture with key use cases
59
Construction: Build The Product
Incrementally define, design, implement and test more and more scenarios

Incrementally evolve executable architecture to complete system Evolve architecture as you go along Partial deployment strategy depends greatly on what system you build
Frequent demonstrations and partial deployment
Daily build with automated build process You may have to have a separate test team if you have

60
Complex test environments Safety or mission critical systems

Transition: Stabilize and Deploy

Project moves from focusing on new capabilities to stabilizing and tuning Produce incremental bug-fix releases Update user manuals and deployment documentation Execute cut-over Conduct post-mortem project analysis
61
References

Per Kroll, RUP and Agility at Scale, A slide presentation from IBM Software Group Roger Pressman, Software Engineering: A Practitioner Approach, Prentice Hall
62

Software Engineering Review - Software Process

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Review - Software Process

Uploaded by

Copyright:

Available Formats

IF3250 Proyek Perangkat Lunak Rekayasa Perangkat Lunak-Review

Software Application Domain Software Engineering

Software Development Process

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya

Software Application Domains

IF3250-Proyek Perangkat Lunak (Informatika ITB)

IF3250-Proyek Perangkat Lunak (Informatika ITB)

Software Engineering (2)

IF3250-Proyek Perangkat Lunak (Informatika ITB)

System Engineering Hierarchy

domain of interest Domain View system element Element View

IF3250-Proyek Perangkat Lunak (Informatika ITB)

The Product Engineering Hierarchy

Requirement Engineering (World View)

Component Engineering (Domain View)

Analysis and Design modeling (Element View)

Construction & Integration (Detail View)

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya

System/ Technical/ Hardware Requirements

Business Requirements and/or Business Rules

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya

IF3250-Proyek Perangkat Lunak (Informatika ITB)

Global Design and Detailed Design

IF3250-Proyek Perangkat Lunak (Informatika ITB)

From Design to Coding

R2 R2.2 D2.2 DD6 R3.1 D3.1 DD7

R3 R3.2 D3.2 DD8 DD9 R3.3 D3.3 DD10

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya

R1 R1.1 D1.1 DD1 C1 T1

R3 R3.2 D3.2 DD8 C8 T8 DD9 C9 T9 R3.3 D3.3 DD10 C10 T10

R1.2 D1.2 DD2 C2 T2 DD3 C3 T3

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya

IF3250-Proyek Perangkat Lunak (Informatika ITB)/Bayu Hendradjaya

User Acceptance Test

User Acceptance Test

Software Development Life Cycle

IF3250-Proyek Perangkat Lunak (Informatika ITB)

IF3250-Proyek Perangkat Lunak (Informatika ITB)

IF3250-Proyek Perangkat Lunak (Informatika ITB)

IF3250-Proyek Perangkat Lunak (Informatika ITB)

Rapid Application Development Model

IF3250-Proyek Perangkat Lunak (Informatika ITB)

Boehms Spiral Model

IF3250-Proyek Perangkat Lunak (Informatika ITB)

Concurrent Development Model

IF3250-Proyek Perangkat Lunak (Informatika ITB)

IF3250-Proyek Perangkat Lunak (Informatika ITB) SW Dev Methodologies/Bayu

Component Based Development

IF3250-Proyek Perangkat Lunak (Informatika ITB)

Reusable Component Development

Application Domain Development

Repository Reusable Artifacts/ Components

The Unified Process

Iteration and Workflow

An iteration in the elaboration phase Analysis

Iteration and Workflow

IBM Software Group-Rational Unified Process 30

Agile Software Development

IF3250-Proyek Perangkat Lunak (Informatika ITB)

IF2036 RPL - IF ITB

IF3250-Proyek Perangkat Lunak (Informatika ITB)

An Agile View of Process

Compromise between Conventional Software Development to a Software Project

Entrenched process, people, and policy