1. Modelling the Process and Life Cycle
Software development usually involves the following stages:
Requirements analysis and definition
System design
Program design
Program implementation (writing the program)
Unit testing
Integration testing
System testing
System delivery
Maintenance

2. What is a process?
A series of steps involving activities, constraints and resources that produce an intended output of some kind
Characteristics of a process:
prescribes all of the major process activities
uses resources, subject to a set of constraints (such as a schedule), and produces intermediate and final results
may be composed of sub-processes that are linked in some way.
each process activity has an entry and exit criteria, so we know when each activity begins and ends

3. What is a process? (continued)
activities are organised in a sequence, so that it is clear when one activity is performed relative to the other activities
a set of guiding principles that explain the goals of each activity
constraints or controls may apply to an activity, resource or product.
e.g. budget or schedule may constrain length of time activity may take

4. Reasons for modelling a process
Common understanding of the activities, resources and constraints
Helps in the finding of inconsistencies, redundancies and omissions
Help evaluate candidate activities for their appropriateness in meeting the goals, such as building high-quality software.
Every process should be tailored for the special situation in which it will be used. Building a model helps the team understand where that tailoring is to occur

5. Waterfall model

6. Waterfall model: advantages
Very useful in helping developers layout (very high-level view) what they need to do
Simplicity – makes it easy to explain to customers (who are not familiar with software developers)
Explicitly states which intermediate products are necessary in order to begin next stage

7. Waterfall model: disadvantages
Failure to treat software as a problem solving process. Software is a creation process not a manufacturing process. Software evolves as the problem is understood and the alternatives are evaluated.
In particular, creation involves trying a little of this or that, developing and evaluating prototypes, assessing the feasibility of requirements, contrasting several designs, learning from failure and eventually settling on a satisfactory solution to the problem

8. Waterfall model: disadvantages
It provides no guidance of how each activity transforms one artefact into another, such as requirements to design. Thus the model provides no guidance to managers and developers on how to handle changes to products and activities that are likely to occur during development.
If requirements change during coding, what changes do we make to design and code?

9. Software development in reality

10. Process models
The software development process can help control the thrashing by including activities and sub-processes that enhance understanding.
Prototyping is such a sub-process; a prototype is a partially developed product that enables customers and developers to examine some aspect of the proposed system and decide it is suitable or appropriate for the finished product.

11. Prototyping model

12. Prototyping model
Prototyping can be the basis of an effective process model. This model allows all or part of the system to be constructed quickly to understand or clarify issues.
The overall goal is to reduce risk and uncertainty in development.

13. Phased development model

14. Phased development model
This is used to reduce cycle time. The system is designed so that it can be delivered in pieces, enabling users to have some functionality while the rest is being developed. There are usually two systems functioning in parallel: the production system and the development system

15. Incremental model
In the incremental model, the system as specified in the requirements is partitioned into sub-systems by functionality. The releases are defined by beginning with one small functional sub-system and then adding functionality with each new release.

16. Iterative model
This model delivers a full system at the very beginning and then changes the functionality of each sub-system with each new release.

17. Phased development: advantages
Training can begin on an early release. The training process allows developers to observe how certain functions are executed, suggesting enhancements for later releases.
In this way, the developers can be very responsive to the users

18. Phased development: advantages
Markets can be created early for functionality that has never before been offered
Frequent releases allow developers to fix unanticipated problems as they are reported
The development team can focus on different areas of expertise with different releases.

19. Question
Should a development organisation adopt a single process model for all of its software development? Discuss the pros and cons.

20. Answer
Pros:
Standardization of training, terminology, the collection of process metrics, planning and estimation. Works well if the projects are very similar in nature.
Cons:
Adopting a single standard process may unnecessarily constrain some projects from using the process that is best suited to the problem and the solution.

21. Question
Suppose your contract with the customer specifies that you use a particular software development process. How can work be monitored to enforce the use of this process?

22. Answer
Conformance to a particular process is often checked with the use of milestones. That is, the process is defined in such a way that there are tangible products in the process whose existence indicates that particular process steps have been carried out.
For example, when using the waterfall process. These intermediate products, or milestones, could be a requirements document, a design document, the code itself, test documents etc. The timing of these products indicate whether or not the process was being followed as planned.

23. Answer (continued)
Another way to monitor use of a process is by measuring effort. Developers working on the project could be required to report the effort they spent on different process activities. By tracking when effort is spent on which activities, progress through the steps of the process could be monitored.

24. The Rational Unified Process
a process framework that can be adapted and extended to suit the needs of an adopting organization.
general and comprehensive enough to be used "as is," i.e., out-of-the-box, by many small-to-medium software development organizations, especially those that do not have a very strong process culture.
From an article by Philippe Kruchten
(check course webpage)

25. The Rational Unified Process
Can also modify, adjust, and expand the RUP to accommodate the specific needs, characteristics, constraints, and history of its organization, culture, and domain.
Process should not be followed blindly, generating useless work and producing artefacts that are of little added value.
Instead, must be made as lean as possible while still fulfilling its mission to help developers rapidly produce predictably high-quality software.
From an article by Philippe Kruchten
(check course webpage)

26. The RUP Captures Software Development Best Practices
RUP captures many of modern software development's best practices in a form suitable for a wide range of projects and organizations:
Develop software iteratively.
Manage requirements.
Use component-based architectures.
Visually model software.
Continuously verify software quality.
Control changes to software.
From an article by Philippe Kruchten
(check course webpage)

27. Develop Software Iteratively
Most software teams still use a waterfall process for development projects, completing in strict sequence the phases of requirement analysis, design, implementation/integration, and test.
idles key team members for extended periods
defers testing until the end of the project lifecycle, when problems tend to be tough and expensive to resolve
pose a serious threat to release deadlines
By contrast, RUP represents an iterative approach that is superior
From an article by Philippe Kruchten
(check course webpage)

28. Manage Requirements
Requirements management is a systematic approach to eliciting, organising, communicating, and managing the changing requirements of a software-intensive system or application.
From an article by Philippe Kruchten
(check course webpage)

29. Continuously Verify Quality
There is no worker in charge of quality in the RUP
Because quality is not added to a product by a few people.
Instead, quality is the responsibility of every member of the development organization.
In software development, our concern about quality is focused on two areas:
product quality
process quality.
From an article by Philippe Kruchten
(check course webpage)

30. Continuously Verify Quality (continued)
Product quality -- The quality of the principal product being produced (the software or system) and all the elements it comprises (for example, components, subsystems, architecture, and so on).
Process quality -- The degree to which an acceptable process (including measurements and criteria for quality) was implemented and adhered to during the manufacturing of the product.
From an article by Philippe Kruchten
(check course webpage)

31. Rational Unified Process
From an article by Philippe Kruchten
(check course webpage)

32. From an article by Philippe Kruchten (check course webpage)

33. Agile Methods
Agile manifesto focuses on four simple value statements, which defines preferences:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Respond to changes over following a plan

34. Agile Processes Extreme Programming(XP) Crystal Scrum
Adaptive Software Development

35. Extreme Programming(XP)
Leveraging the creativity of developers and minimising the amount of administration overhead
Emphasises four characteristics of agility:
Communication
Simplicity
Courage
Feedback

36. XP (continued) Communication Simplicity Courage Feedback
Continual interchange between customers and developers
Simplicity
Encourages developers to select the simplest design or implementation to address the needs of the customer
Courage
Commitment to delivering functionality early and often
Feedback
Loops are built into various activities during development process

37. Crystal
Collection of approaches based on the notion that every project needs a different set of policies, conventions and methodologies
Suggests the following:
quality of the projects and processes improves as the quality of the people involved improves
Productivity increases through better communication and frequent delivery because there is less need for intermediate products

38. Scrum
Uses iterative development, where each 30-day iteration is called a “sprint”
During a “sprint”, implement the product’s backlog of prioritised requirements
Multiple self-organising and autonomous teams implement product increments in parallel
Coordination is done at a brief daily status meeting called a “scrum”

39. Adaptive Software Development
has six basic principles:
A mission that acts as a guideline
Features are viewed as the crucial point of the customer value
Iteration is important
Change is embraced
Fixed delivery times
Risk is embraced

40. ASD (continued) A mission that acts as a guideline
setting out the destination but not prescribing how to get there
Features are viewed as the crucial point of the customer value
so the project is organised around building components to provide features
Iteration is important
so redoing is as critical as doing

41. ASD (continued) Change is embraced Fixed delivery times
so that change is viewed not as a correction but as an adjustment to the realities of software development
Fixed delivery times
force the developers to scope down the requirements essential for each version produced
Risk is embraced
so that the developer tackles the hardest problems first