1.1 Software Lifecycle

Step 1 — Recall the four framework activities. Every software process model includes inception, elaboration, construction, and deployment.

Step 2 — State what happens in each.

• Inception — planning where the project goals and overall scope are defined.
• Elaboration — analyzing requirements and designing a detailed architecture model.
• Construction — building the software by coding from the design.
• Deployment — releasing the software in a usable form to end users.

Answer: The four framework activities are inception (plan goals and scope), elaboration (analyze requirements and design the architecture), construction (code and build the software), and deployment (release the software to end users).

Step 1 — Pick two umbrella activities. From the list, two examples are quality management and risk management.

Step 2 — Explain why they are called "umbrella." The word umbrella suggests something that spreads over and covers everything below it. These activities are not part of any single phase; instead, they run alongside all of the framework activities at once, holding the whole project together.

Answer: Two examples are quality management (testing, technical reviews) and risk management (project tracking and planning). They are called "umbrella" activities because they span and apply to every framework activity rather than belonging to any single phase.

Step 1 — Define a task set. A task set (or workflow) is all of the tasks required to accomplish a specific software engineering action within a framework activity.

Step 2 — Connect it to an action. Each type of software engineering action (for example, requirements definition) has its own task set: the checklist of every small task needed to complete that one job.

Answer: A task set (workflow) is the collection of all tasks needed to accomplish a specific software engineering action within a framework activity. It relates to an action as its to-do list: one action, such as requirements definition, is carried out by following the tasks in its task set.

Step 1 — Name the four Ps. The four Ps are problem, project, people, and product.

Step 2 — Describe each in one sentence.

• Problem — what the software must solve; its nature and difficulty shape the process.
• Project — the size, constraints, and resources of the effort.
• People — the team's size, skill, and experience.
• Product — the type, complexity, and stakes of the software being built.

Answer: The four Ps are problem (what the software must solve), project (the scale and constraints of the effort), people (the team doing the work), and product (the software being built). A process framework is adjusted to fit these four factors.

Step 1 — Recall the listed objectives. The section names four objectives of traditional prescriptive process models.

Step 2 — List them.

• Improve efficiency — a clear plan helps teams avoid rework.
• Reduce risk — identifying issues early helps prevent project failures.
• Increase predictability — a structured process helps estimate timelines and costs.
• Capture best practices — traditional models incorporate tried-and-true methods.

Answer: The four objectives are to improve efficiency, reduce risk, increase predictability, and capture best practices.

Step 1 — Identify a strength. Traditional models follow an orderly, prescribed sequence, which improves efficiency, reduces risk, and increases predictability for projects with well-understood requirements.

Step 2 — Identify a weakness. They are criticized for being too rigid and inflexible, and they do not adapt well to projects whose requirements change rapidly.

Answer: One strength is that a traditional prescriptive process model brings efficiency, risk reduction, and predictability through an orderly, structured approach. One weakness is that it is too rigid and inflexible for projects with rapidly changing requirements.

Step 1 — Recall the four phases. Inception is planning and scope, elaboration is requirements and design, construction is coding, and deployment is releasing.

Step 2 — Match each task to its phase.

• (a) writing the for loop that does the countdown → construction
• (b) deciding the app only counts down (not up too) → inception (defining scope)
• (c) sketching how the loop will work → elaboration (designing)
• (d) opening the page and watching it count → deployment (releasing to a usable form)

Answer: (a) construction, (b) inception, (c) elaboration, (d) deployment.

Step 1 — Identify the umbrella activity. Testing is listed under quality management (technical reviews, estimations, metrics/measurements, testing).

Step 2 — Sketch a task set. A task set for "test the doubling function" could include: write a few inputs, run the function on each, check that the output is exactly double the input, and fix the function if any check fails.

Answer: Testing belongs to quality management. A task set for testing the doubling function might include choosing inputs, running the function, verifying each output is double the input, and correcting any failure.

Step 1 — Model the example. The greeting example used prompt to ask for a name, stored it in a variable, and printed with console.log.

Step 2 — Adapt it to a favorite sport. Replace the question and the message:

▶ Press Run to see the output…

Step 3 — Label the activity. Writing the JavaScript is construction, because it is the coding that turns the plan into a working program.

Answer: const sport = prompt("What is your favorite sport?"); and console.log("Great choice! " + sport + " is fun to play."); — this writing belongs to the construction phase.

Step 1 — Identify the umbrella activity. Keeping a shared component in sync across projects is configuration management, which tracks and controls the different versions and copies of software work products.

Step 2 — Explain why it matters. If the two apps each carry their own copy of the function and someone fixes a bug in only one copy, the other app still runs the buggy version. Configuration management keeps the copies aligned, so quality improvements reach everywhere they are used.

Answer: Configuration management keeps the two copies in sync. It matters for quality because, without it, a fix made in one app could leave the other app running an outdated, buggy version of the same function.

Step 1 — Recall the weakness of traditional models. They are criticized for being too rigid and inflexible, and they may not suit projects with rapidly changing requirements.

Step 2 — Apply it to the project. The startup example in this section shows that a project whose features change every week is exactly where a rigid, prescribed sequence of activities struggles to keep up.

Answer: No, a traditional prescriptive process model is a poor fit, because it is too rigid and inflexible for requirements that change weekly — the same weakness shown in the startup example, where a rigid process cannot adapt quickly to changing features.

Step 1 — Recall what each phase holds. Construction is the coding; deployment is releasing the software in a usable form.

Step 2 — Give one task per phase.

• Construction: writing a console.log("Hello, world!") line, or typing the code that implements a function.
• Deployment: opening the finished HTML page in a browser to run the JavaScript, or publishing the app so other users can open it.

Answer: A construction-phase task is writing JavaScript code (for example, a console.log or a function). A deployment-phase task is releasing the app into a usable form, such as opening the page in the browser or publishing it for users.