What / who / why is Process Models?

• **What**: Follow a series of planned steps, like a map, to help you create software on time and with good quality.

• **Who**: Software engineers, their managers, and clients. People adjust the process to suit their needs and follow it.

• **Why**: It brings order and control to the project, which would otherwise be chaotic. Modern software methods
should be flexible and only include steps that are really needed.

• **Work products**: Things produced during the process, like programs, documents, and data.

• **Steps**: The process you follow depends on what you're building. For example, the process for creating airplane
software is different from making a website.

• **How to ensure it's done right**: There are ways to assess if the software process is mature and effective, but the
best signs are the quality of the software, whether it was delivered on time, and how well it holds up over time.
A Generic Process Model
• We talked earlier about the main steps in a software process:
communication, planning, modeling, construction, and deployment.
These are the core activities.

• Along with these, there are ongoing activities, like project tracking,
managing risks, ensuring quality, handling changes, technical reviews,
and more. These run throughout the whole process.

• Now, the question is: how are these steps and tasks arranged in order,
and when do they happen? The process flow gives the answer to that.
 Identifying a Task Set
Before starting, ask: What steps are right for this situation,
based on the problem and the people involved?
A "task set" tells you what work needs to be done for each
step.
•A list of jobs to finish.
•A list of things to make (like documents or programs).
•A list of checks to ensure everything is done well.
Identifying a Task Set

• For a small software project with simple needs, you might only need a
quick phone call with the person who requested it. The steps for this are:

• 1. Call the person.

• 2. Talk about what they need and write it down.
• 3. Turn your notes into a short document.
• 4. Send it to them by email for approval.
Example of a Task Set for Elicitation

• 1. Make a list of people involved in the project.

• 2. Interview each person separately to understand what they want and need.
• 3. Create an initial list of features and functions based on what you learned.
• 4. Plan and schedule meetings to define the application details.
• 5. Hold the meetings.
• 6. Write simple examples of how users will use the system.
• 7. Update these examples based on feedback from the stakeholders.
• 8. Create an updated list of what stakeholders require.
• 9. Use methods to rank the importance of each requirement.
• 10. Organize the requirements so they can be delivered in stages.
• 11. List any limitations or restrictions on the system.
• 12. Talk about how to test and ensure the system works as expected.
• Both do the same work with different depth and formality.
Process Patterns
A process pattern helps solve common problems in software engineering. It
explains the problem, describes the situation where it happens, and
suggests proven solutions. It’s like a guide or template for handling these
issues during the software development process.

• These patterns can be at different levels:

• - Solving problems related to the entire process, like using prototyping.
• - Solving problems within a specific activity, like planning.
• - Solving problems with specific tasks in an activity, like estimating project
costs.
 Process Pattern Types

- **Stage patterns**: Focus on problems related to a big activity in the process and include smaller tasks.
- For example, "Establishing Communication" might include tasks like gathering requirements.

- **Task patterns**: Focus on problems related to specific tasks or actions in software development,
- helping to ensure good practices.

- **Phase patterns**: Focus on the sequence of activities in the process, even if the process repeats in cycles.
- Examples include models like the Spiral Model or Prototyping.
15
• **Pattern name**: RequirementsUnclear

• **Intent**: This approach helps when stakeholders have a rough idea but aren’t sure about the exact software needs. It creates a model that stakeholders can review and improve to clarify the requirements.

• **Type**: Phase pattern

• **Initial context**: Before starting:

• 1. Stakeholders are identified.

• 2. There is a way for stakeholders and the software team to communicate.

• 3. The main problem the software will solve is known.

• 4. There’s a basic understanding of the project scope, business needs, and limitations.

• **Problem**: The requirements are unclear, and stakeholders don’t know exactly what they want.

• **Solution**: The prototyping process is used, where a basic model is built for stakeholders to review.

• **Resulting context**: A software prototype is created and approved by stakeholders. After that:

• 1. The prototype may evolve into the final software through improvements, or

• 2. The prototype may be thrown away.

• **Related patterns**: CustomerCommunication, IterativeDesign, IterativeDevelopment, CustomerAssessment, RequirementExtraction.

Process Assessment and
Improvement
**SP** (software process) can’t guarantee that software will be delivered on time, meets all needs, or has the
right technical features. However, the process can be checked to ensure it meets important criteria for
successful software development.

• **SCAMPI** (Standard CMMI Assessment Method for Process Improvement): A five-step process
evaluation method with phases: starting, diagnosing, setting up, taking action, and learning.

• **CBA IPI** (CMM-Based Appraisal for Internal Process Improvement): A technique to check how mature a
software organization is, using the SEI CMM model.

• **SPICE** (ISO/IEC 15504): A standard that helps organizations evaluate how effective their software
process is.

• **ISO 9001:2000 for Software**: A general standard for improving the quality of products, systems, or
services, which can also be used for software companies.
17
Prescriptive process models were created to bring structure to chaos in
software development, promoting an organized approach. But could
allowing a bit of flexibility (less rigid) actually encourage creativity?

• This raises some questions:6

• - If prescriptive models aim for structure and order, are they unsuitable
for the constantly changing world of software development?
• - On the other hand, if we abandon traditional models and their order
for something more flexible, do we risk losing coordination and clarity
in the software development process?
Drawbacks of Waterfall Model

• The **waterfall model** has a major drawback: it’s hard to make changes once the process has started.
Each phase must be finished before starting the next one, making it difficult to adjust to new customer
needs. This model works best when the requirements are clear and changes are expected to be minimal
during design.

• Once a project reaches the testing stage, it’s tough to go back and fix issues that weren’t addressed earlier.
Also, working software isn’t available until late in the process, which increases risks and uncertainties.

• This model isn’t good for complex projects or those that are long-term and ongoing, especially if there’s a
high chance that requirements will change.

• Most businesses don’t have stable requirements, so the waterfall model is mainly used for large systems
engineering projects where development happens across multiple locations.
21
• - Once the application reaches the testing stage, it’s very hard to go
back and fix things that weren’t planned properly in the beginning.
• - No usable software is available until much later in the project.
• - There is a lot of risk and uncertainty involved.
• - It’s not a good model for complex or object-oriented projects.
• - It’s a poor choice for long-term, ongoing projects.
• - It’s not suitable for projects where the requirements are likely to
change a lot.
22
• - This model is used only when the requirements are very clear, well-
known, and unchanging.
• - The product's definition stays stable throughout the project.
• - The technology being used is well understood.
• - There are no unclear or confusing requirements.
• - Plenty of resources and skilled people are available to work on the
project.
• - The project is short in duration.
- If any issues are found after the product is built, fixing them is expensive
because everything from the documents to the logic needs to be updated.
V shaped model
• - **Left Side of V-Model**: Basic requirements are broken down into
more detailed and technical descriptions of the problem and its
solution.
• - **Right Side of V-Model**: A series of tests are done to check and
confirm the models created on the left side.

• In practice, there’s not much difference between the traditional life

cycle and the V-Model. The V-Model simply shows how checking and
confirming (verification and validation) are applied during the
engineering process.
The Incremental Model

• The **Incremental Model** mixes steps that happen in order (linear)

and at the same time (parallel). It’s used to give users a basic version
of the software quickly, then improve it with more features in future
updates.

• The first version is called the **core product**. It meets the main
requirements, but many extra features (both planned and unplanned)
are left out for now. The customer uses the core product to give
feedback.
• The customer's **evaluation plan** is used to guide the next update.
The plan focuses on improving the current product and adding new
features.

• The early versions are simpler than the final product, but they still
work and give users something to test and provide feedback on.
Advantages of the Incremental
Model
• There may not be enough staff to finish the full project by the set
deadline, but more people can be hired for the next update if needed.

• This model handles technical risks, like hardware maintenance, by

planning ahead. It also produces working software early in the
process.

• It’s more flexible and less expensive to make changes to the scope
and requirements.
Evolutionary Models

• Software systems change over time as requirements often shift during

development. So, it’s not possible to follow a straight path to the final product.
However, a basic version must be delivered to stay competitive.

• The main product requirements are usually clear, but the details and extensions still
need to be worked out. You need a process model that allows the product to grow
over time.

• An **iterative** model helps you create more complete versions of the software
with each cycle. Two common examples of this are the **Prototyping** and
**Spiral** models.
Evolutionary Models: Prototyping
• Prototyping can be used on its own or with any other process model.
It helps to clarify unclear or vague requirements.

• Prototyping cycles are planned and done quickly. If the prototype

needs to be built fast, existing tools and code can be reused.

• A prototype is often seen as a **first version** or something to

**throw away**. Some prototypes are temporary, while others can
be improved and turned into the final system (evolutionary).
Advantages of Prototyping Model
• Users are actively involved in the development process. Since this
method provides a working version of the system, users can better
understand what’s being created.

• Errors can be found earlier, and feedback from users comes quickly,
leading to better solutions. Missing features are easier to spot, and
confusing or hard-to-use functions can be identified.

• This approach helps to validate requirements and allows for fast

implementation of an incomplete but working system.
Disadvantages of Prototyping Model
This approach can lead to a "build first, fix later" way of creating
systems. In practice, it might make the system more complex because
the scope can grow beyond the original plan.

• An incomplete application might not be used as intended, and there

may be insufficient or incomplete problem analysis.
When to use Prototyping Model
• The **Prototype model** is best when the system needs a lot of
interaction with users. It's ideal for things like **online systems** or
**web interfaces** that require user-friendly designs.

• Building a system that is easy to use and requires little training may
take time. Prototyping helps because users test the system and give
feedback, which is used to improve the design.

• This model is great for creating good **human-computer

interfaces**.
Use of spiral model
• Here’s the easiest version:

• - Best for **large systems** and software.

• - Useful when **costs and risks** need to be checked at every stage.
• - Ideal for **medium to high-risk projects**.
• - Prototyping helps to **reduce risks**.
• - Not good for long-term projects due to possible **changes in priorities**.
• - Works when **users are unsure** of what they need.
• - Good for **complex requirements** or **new product lines**.
• - Suitable when **big changes** or **research** are expected.