1. Exam 0 review
CS 360
Lecture 8

2. Software engineering Introduction to software engineering
If you don’t understand it, you can’t program it.
If you didn’t measure it, you didn’t do it.

3. Software engineering vs. Computer Science
Foundation based on mathematics and theory.
Why does it work?
Software Engineering:
Foundation based on problem solving.
How does it work?

4. Software Engineering Body of Knowledge

5. Software process activities
Software specification:
where clients and engineers define the software that is to be produced and the constraints on its operation.
Software development:
where the software is designed and programmed.
Software validation:
where the software is checked to ensure that it is what the customer requires.
Software evolution:
where the software is modified to reflect changing customer and market requirements.

6. Feasibility Study The feasibility study:
What is the scope of the proposed project?
Is the project technically feasible?
What are the projected benefits?
What are the costs?
Expected timeline?
What resources are needed?
What are the risks and how can they be managed?

7. Basic Process Steps in all Software Development
Feasibility and planning
Requirements
System and program design
Implementation
Acceptance and release
Maintenance
These steps may be
repeated many times
during the development
cycle.

8. Quality control steps in software development
Validating the requirements
Validating the system and program design
Usability testing
Program testing
Acceptance testing
Bug fixing, feature enhancements, and maintenance
Some of these steps will be repeated many times during the life of the system.

9. Types of software process
Three categories of software development processes:
Sequential:
As much as possible, complete each process step before beginning the next.
Waterfall model
Iterative:
Go quickly through all process steps to create a rough system, then repeat to improve the system.
Iterative refinement, functionality of all components increase during each phase.
Incremental:
Variation of the iterative refinement in which small increments of software are placed in production (sprints).
Agile refinement, adding individual features during each phase.

10. Sequential Development
Sequential processes work best when the requirements are well understood, and the design is straightforward.
Ex:
Conversions of existing manual data processing systems.
New models of a product based on earlier versions or similar products.
Parts of a larger system where components are clearly defined.

11. Modified waterfall model

12. Iterative Processes
Iterative processes require documentation refinement during each phase.
This type of software process enables the client to review the planned system early during development:
Software/hardware mock-ups
Sandbox modules
Rapid prototyping
Feature refinement
The goal is to get something working as quickly as possible, for client and user evaluation, but do not release it.

13. Iterative Refinement

14. Incremental Development (sprints)
The project is divided into a large number of small tasks, known as sprints.
For each sprint, the team works through a full software development cycle.
Each sprint is completed in a fixed time period, or milestone and adds new functionality to the project.

15. Incremental Development

16. Project Management To complete a project:
On time
On budget
With required functionality
To the satisfaction of the client
Without exhausting the team
To provide visibility about the progress of the project.

17. Risk management Should be a team activity Risk identification
Identify project, product, and business risks
Risk analysis
Assess the likelihood and consequences of these risks
Risk planning
Define plans to avoid or minimise the effects of the risks
Risk monitoring
Define ways to monitor and log risks throughout the project

18. Risk identification Common risks: Technology risks
Database is too slow, software components contain defects
People risks
Difficult to recruit skilled personnel, key staff unavailable at times
Organizational risks
Management personnel change, reduction in project budget
Requirements risks
Changes require major redesign
Estimation risks
Time requirements, defect repair rate underestimated, project size

19. Aspects of Project Management
Planning:
Outline schedule during feasibility study.
Fuller schedule for each part of a project.
Contingency planning:
Anticipation of possible problems.
Progress tracking:
Regular comparison of progress against plan.
Regular modification of the plan.
Change of scope.
Final analysis
Analysis of project for improvements during next project.

20. Gantt Charts Example
Activities/Chunk ordering will be determined by the software process model your development team decides to use.
As the semester progresses, the Gantt chart may need modifying.

21. Example: Activity graph for a distance learning course

22. Requirement Goals Understand the requirements in appropriate detail.
Define the requirements in a manner that is clear to the client.
Define the requirements in a manner that is clear to developers.
Ensure that the client and developers understand the requirements and their implications.

23. Requirements completeness and consistency
Requirements should be both complete (as much as possible) and consistent
Completeness:
They should include descriptions of all facilities required for the project.
Consistent:
There should be no conflicts or contradictions in the descriptions of the project requirements

24. Steps in the requirements phase
The requirements part of a project can be divided into several stages:
Analysis – to establish the system’s services, constraints, and goals by consulting with clients, customers, and users.
Modeling – to organize the requirements in a systematic and comprehensible manner.
Defining, recording, and communicating the requirements.

25. Functional requirements
Functional requirements describe the functions that the system must perform.
They include topics such as:
Data
User interfaces
Component interfaces
Technical details

26. Non-Functional requirements
Requirements that are not directly related to the functions that the system must perform
Product requirements
performance, reliability, portability, etc...
Organizational requirements
delivery, training, standards, etc...
External requirements
legal, interoperability, etc...
Marketing and public relations

27. Key points on Requirements Engineering
The requirements document is an agreed statement of the system requirements.
The requirements engineering process is an iterative process including:
Requirements gathering
Specification
Validation, testing
Requirements gathering and analysis is an iterative process that may be repeated:
Requirements discovery (new, updated)
Requirements classification and organization
Requirements negotiation (clients, users)
Requirements documentation (SW engineering team)

28. UML diagram types Use case diagrams Activity diagrams
Shows the interactions between a system and its environment.
Activity diagrams
Shows the activities involved in a process or in data processing.
Sequence diagrams
Shows interactions between actors and the system and between system components.
Class diagrams
Shows the object classes in the system and the associations between these classes.
State diagrams
Shows how the system reacts to internal and external events.

29. System boundaries model
System boundaries are established to define what the system should and should not do.
Identifies where the system begins and ends.
Ex:
System scalability (20 node cloud vs. 200 node cloud)
Defining system boundaries
Physical boundaries
Social boundaries
Economic boundaries
Political boundaries

30. Scenarios
A scenario is a scene that illustrates some interaction with a proposed system.
User logging into website
Robot making decisions based on environment
User walking into a building
A scenario is a tool used to describe a specific use of your project.

31. Use case Diagrams Use case diagrams
A use case diagram shows the rela1onships between actors and their interactions with a system.
It does not show the logic of those interactions.

32. Use cases for exam system

33. Exam 0 Exam: five questions, one to omit, graded out of four.
Each question equally weighted (25% each)
Detailed answers must be legible (marked incorrect if I can’t read your answer)
Answer quality/detail will determine your score for each question
Possible multiple section questions; a, b, c, ..
One hour to complete the exam in class (11:30am – 12:30pm, 1:50pm – 2:50pm)
Content on exam 0:
First seven lectures
Chapters 1, 2, 4, 5, 7, 22, and 23
Supplemental reading
Suggested reading: Your group’s project documentation