# Software processes

###### tags: `SPM`

## What is a software process?
A software process model describes:
**systematic**,
**engineering**,
and **Quantifiable** approaches,
to **solve task** of a particular class in a **repreatable manner**.

Software process address
Structural orgsnization
Process organization
Artifact models

## SMP Chapter 4 & 6
## Chapter 4 Selection of an appropriate project approach

### 4.1 Introduction

Develop of software in-house:
- developers and users belong to the same organization
- the application will slot into a portfolio of existing computer-based systems;
- the methodologies and technologies are largely dictated by organizational standards and policies, including the existing enterprise architecture.

decision-making process = technical planning = project analysis
(or methods engineering and mehods tailoring)

process model -> waterfall - prototyping - incremental delivery
(prototyping and incremental delivery = agile methods)

### 4.2 Build or buy?
Software development can be seen from two different viewpoints : developers // client or users

Either be in-hourse or outsources. (in same organization or not)

***Run-of-the-shelf software:***
**Advantages:**
- the supplier of the application can spread the cost of development over a large number of customers and thus the cost per customer should be reduced.
- the software already exist and so
- it can be examined and perhaps even trialed before acuisition
- there is no delay while the software is being built
- where lots of people have already used the software, most of the bugs are likely to have been reported and removed, leading to more reliable software.

**Disadvantages:**
- as you have the same application as everyone else, there is no competitive advantage
- modern off-the-self software tends to be very customizable: the characteristics of the application ca be changed be means of various paramenter tables. However, this flixibility has limits and you may end up having to change your office procedures in order to fit in with the computer system.
- you will not own the software code. This may rule out making modifications to the application in response to changes in the organization or its environment.
- Once you have acquired your off-the-self system, your organization may come to be very relient upon it. This may create a considerable barrier to moving to a different application. The supplier may be in a position to charge inflated licence fees because you are effectively a captive customer.

### 4.3 Choosing methodologies and technologies
Methologies -> should refer to "study of methods"
- collection of methods
- not the same as techniques

Project analysis should select the most appropriate methodologies and technologies for a project
Which will effect:
- the training requirements for development staff
- the types of staff to be recruited
- the development enviroment - both hardware and software
- system maintenance arrangements

#### Steps of project analysis
- Identify project as either objective-driven or product-driven
- Product-driven = create product defined before the start of the project
- Object-driven = defined the general software solution that is to be implemented

- Analys other project characteristics (questian to ask, about writing a software tool)
- Is a data-oriented (substiantial database - information system) or process-oriented (embedded control system) system to be implemented?
- Will the software that is to be produced be a general tool or application specific?
- Are there specific tools available for implementing the paricular type of application?
- Does it involve concurrent processing?
- Will the system to be created be knowledge-based?
- Will the system to be produced make heavy use of computer graphixs?
- is the system to be crafted safety creitical?
- is the system designed primarily to carry out predefined services or to be engaging and entertaining?
- What is the nature of the hardware/software environment in which the system will operate?

- Identify high-level project risks (uncertainty and complexity)
- Product uncertainty
- How well is the requirements understood?
- Process uncertainty
- Any change in the way the system are developed?
- Resource uncertainty
- Availability / experience of staff?

- Taking into account user requirements concerning implementation
- Select general life-cycle approach
- Control systems
- Information systems
- Availability of users
- Specialized techniques
- Knowledge-based systems
- Graphics-based systems
- Hardware environment
- Safety-critical systems
- Imprecise requirements

### 4.4 Choice of process models
"process" = the idea of the system *in action*, in this context.
The system will have to execute one or more activities: this is its process.
These activites can be organized in different ways -> process models

### 4.5 Structure versus speed of delivery
Structered methods = "get it right first time"
- consist of sets of steps and rules -> generate system products (such as use case diagrams)
- more time comsuming
- expensive
- pay-off = less error prone and more maintainable final system
- often called *heavyweight methods*

### 4.6 The waterfall model
Classic -, one-shot -, once-through model

> Think we know it :wink:

Can be expanded into the **V-process model**
- expanding the testing process into different types of testing (see chapter 13)

### 4.7 The spiral model
*Another way of looking at the waterfall model*

### 4.8 Software Prototyping
one way of buying knowledge and reduce uncetainty.
A prototype is working model of one or more aspects of the projected system.

either
- throws-away prototype
- evolutionary prototypes

### 4.10 Incremental delivery
breaks the application down into small components which are then implemented and delivered in sequence.

*time-boxing* is often associated with an incremental approach. the scope of delieverables for an increment is rigidly constrained by an agreed deadline.

## Chapter 6

### 6.1 Introduction
A detailed plan for the project must also include a schedule indicsating the start and completion times for each activity.
this enables us to:

- ensure that the appropriate resources will be available precisely when required.
- avoid different activites competing for the same resources at the same time.
- produce a detailed schedule showing which staff carry out each activity.
- produce a detailed plan against which actual achievement may be measured
- produce a timed cash flow forecast
- replan the project during its lifetime to correct drift from target.

### 6.3 When a plan
Planning is an outgoing process of refinement, each iteration becoming more detailed and more accurate then the last.

### 6.5 Project and activites

**Defining activities**
A project is composed of a number of interrelated activities.
A project may start when at least one of its activities is ready to start
A project will be completed when all of the activities it encompasses have been completed.
an activity must have a clearly defined start and a clearly defined end-point.

**Identifying activities**

3 different approaches.
- activity-based approach
- product-based approach
- hybrid approach

***Activity-based***
list all activities. might require brainstorming session.

Work Breakdown Structure
- identify main (high-level) task required to complete a project
- break them down to a set of lower-level tasks.

Advantage:
- result in a task catelogue is complete - composed of non-overlapping activities.

***Product-based***
see chapter 3 for more information.

***Hybrid***
mix of the two approaches.

### Notes for rest
you remember the lecture.

### 6.17 Conclusion
the use of the critical path method and precedence network to obtain an ideal activity plan.
the plan tells us the order in which we should execute activities and the earliest and latest we can start and finish them.

These techniques helps us identify which activities are critical to meeting a target completion date.

## Managing the Development of Large Software Systems

**Computer program development functions**
two essential steps common to all computer program developments:
1. an analysis step
2. followed by a coding step.


very simple implementation concept... is required if the effort is sufficiently small.

Implementation plan to manufacture larger software systems are doomed to failure using *the plan*
- many additional development steps are required.

The prime function of management is to sell these concepts to both groups (developers & customers) and enforce compliance on the part.

Figur 2: Waterfall method
- addtitions are treated seperately from analysis and coding. Two different in the way they are executed.

Figur 3: Iterative waterfall method
- Ordering of steps:
- each step progresses and the design is further detailed.
- design proceds the change process in scroped down.
- The requirements analysis is completed there exists a firm and closeup baseline.
- Effective fallback position -> maximize the extent of early work that is salvageable and preserved.

Figur 4: Risks with concept from figur 3
- The required design change are likely to be so disruptive that the software requirements upon which the design is based has to change too.

**The fix**
Step 1: Program design comes first.
- A preliminary program design phase inserted between: software requirements & analysis
- Begin the design process with program designers.
- design, define and allocate the data processing modes.
- write an overview document.

Step 2: Document the design
- First rule of manageing software development is ruthless enforcement of documentation requirements.
- Why so much documentation?
1. Each designer must communicate with interfacing designers, with hers mangement and possibly with the customer.
2. During the early phase of software development the documentation is the specification and is the design. Until coding begins: Documentation, specification, design.
3. Monetary value of good documentation begins downstream in the development process. During testing -> operations and redesign.
4. Value of documentation is 3 concrete situations every manager faces:
1. During testing phase: the manager can concentrate personnel on the mistakes in the program
2. During the operational phase: The manager can use operation-oriented personal to operate the program.
3. Following initial operations: improvements are in order, good documentation permits effective redesign, updating, and retrofitting in the field.

Step 3: Do it twice
- second most important criterion for success revolves around the product is totally orginal.
- the second version insofar as critical design/operations areas are concerned.
- The entire process done in miniature, to a time scale that is relatively small with respect to the overall effort.

Step 4: Plan, Control, and Monitor testing
- without question the biggest user of project resources
- It is the phase of greatest risk in terms of dollars and schedule.

Step 5: Involve the customer
- Important to involve the customer in a formal way so that he has committed herself at earlier points before final delivery.

## Iterative and incremental developments. a brief history

Dates back to the mid-50s.
Agile methods become more popular: iterative, evolutionary, and incremental software development.
- as the modern replacement for waterfall method.

IID: Iterative and Incremental Development

"Iterative development" : merely for rework, in modern agile methods in term implies not just revisiting work, also evolutionary advancement.

**Pre-1970**

Plan-do-study-act (PDSA) cycles for quality improvement.

Extreme Programming practice of test-first development: planning & writing tests before each micro-increment.

top-down development with stubs.

The basic approach:
- recognizes the futility of separating design, evaluation, and documentation processes in software-system design.

Robert Glass:
>"Incremental development is worthwhile [it] leads to a more though system shakedown, avoids implementer and management discouragement."

**The Seventies**

The Article:
Managing the Development of Large Software Systems
Read notes higher up.

Top-Down Programming in Large System: Harlan Mills.
- Iterative development
- advice to begin developing from top-level control structures downward