CSS 360 - Final Exam Review

User Story Format

"As a <role>, I need to <complete goal>, [so that, benefit]" Example for educational software: "As a student, I need to be able to check assignment due dates, so that I know what is due this week"

DSDM

(Dynamic Systems Development Method) An agile SDLC model that has a fixed time frame and fixed resources, but variable functionality as a result. It is based on the "best" principles of implementation, but is not the best solution for every project.

PERT Chart

(Program Evaluation & Review Technique) A chart specifying the sequence of activities, time requirements, and critical path for performing the steps in a project. Requires all activities are listed and have estimated lengths.

SDLC Models

(Software Development Lifecycle Models) Frameworks defining the tasks performed at each step in the software development process. They provide structure to the development process.

WBS

(Work Breakdown Structure) A document and chart used as a means of identifying all the activities a project must undertake.

Ceremonies of Scrum

- Backlog grooming: maintenance and updating of the product and sprint backlogs, done by the product owner - Sprint planning (a long meeting) - Sprint (typically 2 weeks) - Daily Scrum: a short meeting that happens at the same time and place daily, to make sure everyone is on the same page, aligned with the sprint goal, and can get a plan out - Sprint review: the team gets together at the end of a sprint to view the demo of, or inspect, their increment. Product owner reworks the backlog and and decides whether or not to release the sprint. - Sprint retrospective: the team comes together to document and discuss what worked and didn't work in a sprint

Advantages of Staged Delivery

- Delivers software incrementally, in successive stages, which makes products easier to review - You put useful functionality into the hands of your customers earlier than if you deliver 100% at the end - Provides tangible signs of progress earlier in the project than less incremental approaches do

Spiral Steps

- Determining objectives, alternatives, and constraints - Identifying risks and resolving them - Evaluating alternatives - Developing the deliverables for that iteration, and verifying they are correct - Planning the next iteration - Committing to an approach for the next iteration

Advantages of Waterfall

- Documentation is carried between phases - Works well with product cycles that have stable product definitions and/or well-understood methodologies - Minimizes overhead planning because all the planning is done up front

Advantages of Kanban

- It is adaptable, and commonly used in combination with other methods and frameworks (usually Scrum) - The board is a good visual aid for the development team, capturing both work in progress and company policies through "done" rules - It directly manages workflow using the Kanban board, as each development step has a WIP limit - Problems are visible and evident immediately with this style of management, re-planning can be done consistently

Disadvantages of Waterfall

- It is hard to fully specify requirements at the beginning of a project before any work is done on it - It is not flexible - you have to fully specify requirements before you have any working product, and the goal then becomes achieving everything you can within the time and resources available rather than achieving what you said you would

Disadvantages of Evolutionary Prototyping

- It is impossible to know how long it will take to create an "acceptable" product - It can easily become an excuse to do code & fix development

Disadvantages of Sashimi

- Milestones are ambiguous and it is difficult to track progress due to the levels of overlap - Performing parallel activities can lead to miscommunication and inefficiency

Advantages of Sashimi

- More overlap than "pure" Waterfall, suggesting that architectural and detailed design could be in progress before requirements engineering is fully complete - Reduced documentation compared to Waterfall, because if you can provide personnel with continuity then you do not need as much.

Advantages of Code & Fix

- No overhead - you do not have to spend any time planning - Requires little expertise - if you've programmed, you've done it. Anyone can use it.

Advantages of User Stories

- People can understand requirements better because they are written in a natural language and expressed first person - The product owner is assisted in prioritizing things

Advantages of Evolutionary Prototyping

- The most visible aspects of the system are developed first, and feedback is prioritized as a result - Useful when requirements change rapidly, customers are reluctant to commit to requirements, or neither you nor your customer understand application areas well

Challenges of Agile Models

- The success of the project is highly dependent on customers - Some personalities may not work well in a highly collaborative environment (individuals may prefer working alone) - Prioritization is hard, especially if you have multiple stakeholders - Simplicity takes a lot of time and effort - It is difficult for organizations to adapt to agile methods, because they are entrenched in the existing process

Principles of DSDM:

1. Active user involvement 2. Empowered team members 3. Frequent delivery 4. Criteria for accepted deliverables 5. Iterative and incremental development 6. Reversible changes during development 7. Requirements baselined at high levels 8. Collaborative and cooperative approach

Theme

A collection of related user stories, often sharing 1-2 common attributes. They cannot be completed in one sprint.

Open Source

A community-based approach to software development. There is collaboration among paid and unpaid developers. It is not always free, and it can often contain a license.

Model-Driven Engineering (MDE)

A derivative of the transformation model that updates the model each step of the way.

Cleanroom Development

A formal model derived from chemical engineering, where defects are avoided by manufacturing "ultra-clean" atmospheres. It avoids defects using formal methods (precise mathematical models) and rigorous inspection processes to make sure errors are not overlooked.

Transformation Model

A formal model that transforms requirements into implementation through a series of steps. This can be manual, semi-automatic, or fully automatic. Addresses the difficulty of code modification and eliminates the cost and time spent in design, coding, and testing. It has a simplistic view - the formal requirement specification transforms into the formal low-level requirements specification, which transforms into high-level design, which is transformed into low-level design. With reusable components, low-level design is finally transformed into code.

Interview

A formal or informal approach to elicit information for stakeholders by talking to them directly.

Scrum Team

A group of developers, designers, and other associated personnel who get things done during Scrum sprints. They are tightly knit and usually 5-7 members (per the "two pizza rule").

Epic

A large user story too big for one task, that often needs to be broken down into more specific user stories.

Joint Application Development (JAD)

A methodology that occurs when knowledge workers and IT specialists meet, sometimes for several days, to define and review the business requirements for the system.

Agile Change Management Process (ACMP)

A model and process where work items are addressed in priority order. Items at the top are "high priority" while the ones at the bottom are "low priority." The ones at the bottom are likely to be epics. Work items are re-prioritized at the beginning of each sprint.

Mock-Up

A model devised to expose its parts for study, training or testing.

Sashimi

A modified version of the Waterfall SDLC model, which overlaps the phases of the "pure" waterfall model.

Waterfall

A prescriptive SDLC model featuring an orderly sequence of steps from the initial concept through the testing phases. At the end of each project phase, there is a review to determine whether the project is ready to advance to the next phase. If the review determines that it is not ready, it stays in the current phase until it is. This model is document-driven.

Spiral

A prescriptive SDLC model that is risk-oriented and breaks one project down into several mini-projects, with each one addressing one or more major risks until all major risks are dealt with.

Waterfall With Subprojects

A prescriptive SDLC that is also a Waterfall modification. Breaks down the system into logically dependent subsystems, which makes it easier for you to create separate projects. Allows developers to perform tasks in parallel, but there are unforeseen interdependencies.

Staged Delivery

A prescriptive SDLC where you show software to the customer in successively refined stages - you know exactly what you will build before you set out to build it

Open Interview

A range of issues are discussed with system stakeholders, who develop a better understanding of their needs.

Robustness

A software quality determining the reasonable behavior of a software, even in unexpected circumstances.

Interoperability

A software quality entailing the ability of a system to coexist and cooperate with other systems.

Correctness

A software quality indicating if it behaves according to states and specifications. This is an absolute quality.

Reliability

A software quality indicating the probability that it will operate as expected over a specific period of time. It is possible to have this but be "incorrect."

Timeboxing

A technique used in DSDM as an alternative to the milestone. It is a time interval (4-6 weeks) where a set of tasks are meant to be achieved.

Gantt Chart

A time and activity bar chart that is used for planning, managing, and controlling major programs that have a distinct beginning and end. Requires that activities are defined before its use. Helpful for resource planning and scheduling, but does not show dependencies between tasks.

Kanban Board

A visualization of the work items in the Kanban SDLC, to give participants a view of progress and process from start to finish.

Objectives of SDLC Types

Agile: Rapid Value (early product releases) Prescriptive: High Assurance (making sure the software is correct)

Documentation

All written documents and materials dealing with a product's development and usage. All software development products, whether created by a small team or a large corporation, require some form of it.

Rational Unified Process (RUP)

An SDLC model consisting of four project lifecycle phases: inception, elaboration, construction and transition. A modification of Unified Process.

Prescriptive Model

An SDLC model following a highly structured process, featuring an ordered approach to development and many planning phases. Promotes ordered approaches to development and project management. Also called the "plan-driven model." Examples: Waterfall, Spiral, Unified Process

Agile Model

An SDLC model that emphasizes continuous feedback and cross-functional teamwork. Simple to learn and featuring adaptive software processes, emphasizing unique aspects of software development. Examples: Extreme Programming (XP), Scrum, Kanban

Unified Process (UP)

An SDLC model that maps out when and how to use the various UML techniques for object-oriented analysis and design. It is iterative, incremental, and architecture-centric.

Code & Fix

An SDLC model that would be Agile if it wasn't just done by one person. It starts with a general idea of what you want to build, and you then use combinations of (informal) design, code, debugging, and testing methodologies until you have a product that is ready to use.

Formal Model

An SDLC model type used in critical systems where there is high risk. There are two subtypes.

Scrum

An agile SDLC model that helps teams work together. Encourages teams to learn through experiences, self-organize, and reflect on wins and losses to continuously improve.

Evolutionary Protoyping

An agile SDLC model where you develop the system's concept as you move through the project.

Kanban

An agile SDLC that is meant to manage and improve work across groups by balancing demands with available capacity and handling bottlenecks.

Sprint Planning

An event in Scrum models defining what can be delivered in the upcoming sprint and how it can be achieved.

Performance

An external software quality assessing efficiency, based on user requirements. It affects usability and scalability.

Spiral Into Waterfall

An extremely prescriptive SDLC model that is yet another Waterfall modification. Adds a risk-reduction spiral at the top of the Waterfall model to address requirements risk. Addresses requirements engineering and architectural design during the risk reduction phase.

Closed Interview

An interview where the stakeholder answers a set of predefined questions.

Feasibility Study

An investigation that decides whether or not the system is worthwhile by checking if it contributes to the company's objective, can be designed with current technology and within the current budget, and can be integrated with other systems.

Ethnography

An observational technique used to understand operational processes and derive requirements for software to support these processes, focused on the end user. Can be combined with the development of a system prototype, informs development and can identify problems so that less cycles are needed.

Advantages of Spiral

As costs increase, risks decrease. The more money and time you spend, the less risks you are taking and the more risks you are tackling, which is exactly what you want for a rapid development project.

Differences Between Software Engineering & Computer Science

Both are concerned with computer software and everything related, BUT: SWE is focused on applications of concrete knowledge to engineering processes while CS is focused on both abstract and concrete knowledge.

3 Cs

Card: stories are traditionally written on notecards, which may be annotated with notes, estimates, etc. They should be written by a customer/user. The front contains the user story, with a unique identifier on the top left of the card, and a priority that estimates the priority of the task, and story points that help estimate. The back has confirmations, which are acceptance tests. Conversation: details behind the story come out during conversations with the product owner. Confirmation: acceptance tests confirm the story was coded correctly. It is the criteria the user will utilize to confirm the story is completed.

Requirements Validation

Checking that the requirements actually define the system that the customer wants.

Essential Software Problems

Complexity: No two software parts are alike (if they were, they would be unified into one). Because each part of the software is unique, complexity does not grow on a linear scale with size. Conformity: Software must conform to the existing environment. Changeability: Software is under pressure to change constantly. Other manufactured items are infrequently changed, and all successful software must get changed. Invisibility: Software is invisible and un-visualizable. It is not inherently embedded into space, and communicating concepts about software is difficult. And accidental errors such as human error, poor interface, inadequate abstraction, and lack of training.

Requirements Specification

Converting requirements into a standard form after elicitation and analysis.

MoSCoW Rules

DSDM rules that make sure the project is on time and on budget, and the users are involved. The rules are as follows: - Must have: All features classified in this group must be implemented and if they are not delivered, the system would simply not work. - Should have: Features of this priority is important to the system but can be omitted if time constraints endanger. - Could have: These features enhance the system with functional items which can easily be reassigned to a later timebox. - Want to have: These features only serve a limited group of users and are of little value.

System Requirements

Detailed descriptions of the software system's functions, services, and operational constraints.

Requirements Elicitation & Analysis

Discovering requirements by interacting with stakeholders.

Requirements

Everything that must be true about the software in order for it to be acceptable for customers - it covers the "what" rather than the "how."

Surveys & Questionnaires

Forms that contain sets of questions designed to gather specific information from a targeted population. They gather data from a potentially large number of respondents. Often they are the only feasible way to reach a number of reviewers large enough to allow statistical analysis of the results.

Requirements Analysis

Gathering what the users want and aligning these desires with the ability of the system to meet those desires.

Benefits of Agile Models

Improved communication, awareness of other people's work, and less process overhead

Critical Path

In a PERT chart, this is the sequence of tasks that takes the longest time to complete.

Agile Manifesto

Individuals and interactions are prioritized over processes and tools Working software is prioritized over comprehensive documentation Customer collaboration is prioritized over contract negotiation Responding to changed is prioritized over following a plan

History of Software Engineering

Introduced in the 1960s, because people were building large programs that were complex, over-budget, and behind schedule. Researchers decided that these problems must be systematically addressed, and it was born with the initial goals of building large software systems.

Disadvantages of Staged Delivery

It does not work well without careful planning on management and technical levels

Disadvantages of Spiral

It is extremely complicated, and requires conscientious, attentive, and knowledgeable management as a result.

Constraints

Limitations on the design or the project. Some examples include specific languages the system must be written in, specific features the system must possess, and a specific date for the system to be fully operational by.

Refactoring

Modifying a program to improve its structure or make it simpler to understand.

Feature Creep

Occurs when requirements are added or changed during the development process and there is no control or management of these changes. This is a problem because it is a common cause of project failure. Can cause budget and schedule overruns, instability in design and code, and poor overall quality and satisfaction.

Nonfunctional Requirements

Requirements not directly concerned with specific functions but relating to emergent system properties, like reliability, response time, and security. They may be more critical than functional requirements.

Functional Requirements

Requirements that describe the functionality and service of the software system. They have to specify a function that the user must need from the system.

Testing Functional Requirements

Running software and seeing if the functions work from there.

Sprint

Short, time based periods in Scrum when a team works to complete a set amount of work.

User Stories

Statements written in a "natural language," plus diagrams, of what services the system is expected to provide to system users and the constraints under which it must operate.

Sprint Backlog

The list of items, user stories, and bug fixes in the product backlog selected by the development team for implementation in the current sprint cycle.

Product Backlog

The master list of work that the Scrum team needs to get done. Maintained by the product owner, it is a dynamic list of features, requirements, enhancements, and fixes that is the input for the sprint backlog. It is constantly revisited, reprioritized, and maintained by the product owner.

Overhead

The ongoing administrative expenses of a business that cannot be attributed to the creation of a product or service, but are still necessary for the business to function.

Scrum Master

The person in charge of a Scrum project, similar to a project manager. Coaches teams and businesses on the Scrum process and looks for ways to fine-tune the process.

Product Owner

The person responsible for the business value of the project and for deciding what work to do and in what order when using a Scrum method. Responsible for understanding company, customer, and market requirements, and prioritizes the work to be done by the team.

Risk

The probability of occurrence for uncertain events and their potential for loss within an organization. Encompasses poorly understood requirements, or architecture, performance problems, etc.

Prototyping

The process of building a model that demonstrates the features of a proposed product, service, or system. It is a good way to satisfy the principles of frequent delivery and incremental development, because it implements functionality first so that errors and difficulty can be discovered.

Requirements Engineering

The process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed.

Slack Time

The time that an activity can be delayed without delaying the entire project; the difference between the late and early start times of an activity. Shaded in a Gantt chart.

Major Activity

The top of the WBS chart, identifying the main task at hand. Every node after it is broken down into smaller tasks.

Increment

The usable end product from a sprint, the team's version of "done" from each sprint. Also called the "sprint goal."

Challenges of Functional Requirements

They can be imprecise, as they can have different interpretations, and it is difficult to achieve completion and consistency. All services should be defined, and requirements should not have contradictory definitions or statements.

Main Functions of SDLCs

To establish the order in which a project specifies, prototypes, designs, implements, reviews, tests, and performs activities, and establish the criteria used to determine when to proceed from one task to the next.

Testing Nonfunctional Requirements

Two ways: - Using metrics - which test size and speed - or transforming them into testable requirements with a user story. - Restating them, and turning them into functional requirements. This allows for easier testing and better quality assurance.