1. Software Process Models and the feasibility study
CS 360
Lecture 2

2. Sequence of processes
We will look at 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.
Prototype, test, analyze, refine, repeat..
Iterative refinement, entire system
Incremental:
Variation of the iterative refinement in which small increments of software are placed in production (sprints).
Prototype, test, analyze, repeat..
Agile refinement, adding individual features during each phase.

3. Sequence of processes Sequential:
As much as possible, complete each process step before beginning the next.
Waterfall model

4. Discussion of the waterfall model
A pure sequential model is impossible
Example:
A feasibility study can’t create a proposed budget and schedule without a study of the requirements and initial design.
Design and implementation will reveal gaps in the requirement specifications.
Requirements and/or technology may change
Solution:
Modified waterfall model

5. Modified waterfall model

6. Discussion of the waterfall model
The waterfall model requires full documentation at each process step.
Advantages:
Process visibility
Separation of tasks
Quality control at each step
Cost monitoring at each step

7. Discussion of the waterfall model
The waterfall model requires full documentation at each process step.
Disadvantages:
In practice, each process stage reveals new understanding of the previous stages.
Often requires earlier stages to be revised.
Reqs  Design  Coding  Updates to reqs  Reqs  Design …

8. Sequence of processes
We will look at three categories of software development processes:
Iterative:
Go through all process steps during each sprint to create a rough system, then repeat to improve the system.
Iterative refinement, entire system

9. Sequence of processes
We will look at three categories of software development processes:
Incremental:
Variation of the iterative refinement in which small increments of software are placed in production (sprints).
Prototype, test, analyze, repeat..
Agile refinement, adding individual features during each phase.

10. Thoughts about software process
Software projects should include all basic process steps.
Implementation process is always partly evolutionary.
No set process standard for this step.

11. Thoughts about software process
Risks are lowered by:
Prototyping key components

12. Thoughts about software process
Risks are lowered by:
Frequent releases, or dividing into phases

13. Thoughts about software process
Risks are lowered by:
Early and repeated testing with users and clients

14. Thoughts about software process
Risks are lowered by:
Making use of reusable components

15. CS 360 Projects: Sequential Development

16. Feasibility Studies

17. Feasibility study Study made before committing to a project.
A feasibility study leads to a decision:
Go ahead/Do not go ahead
Think again/revise
The feasibility study may be in the form of a proposal.
CS 360 – 10 page document, including details on the project requirements

18. Organizational feasibility
Creation of a major software system makes demands on the development team.
Does the team have management expertise?
Does the team have technical expertise?
Can the team accommodate changes in personnel, project requirements, workflow?

19. Organizational feasibility
CS 360 team project objectives:
Management of project teams.
Determining technical level of each team member and assigning tasks appropriately.
Steady progression of a software system while being open to potential change of requirements.
Software documentation management.
Project presentations.

20. Why are feasibility studies difficult?
Uncertainty
Clients and/or development teams may be unsure of the scope of the project.
Benefits are usually very hard to quantify.
Approach is usually ill-defined.
Estimates of resources and timetable are usually too low.
Organizational changes may be needed.

21. Feasibility Study: Scope (Documentation)
Scope expresses the boundaries of the system:
The project will have a list of included functions.
The project will have a list of excluded functions.
The project will have a list of dependencies.
Confusion over scope is a common reason for clients to be dissatisfied with a system.
“I assumed that you were going to do xyz.”
“I can’t use the system without abc.”
Remember, you are building the product for the client, not yourself.

22. Feasibility Study: Scope Example
A project requires a “repository system” to store and make accessible very large amounts of data over a long period of time.
A software development team was hired to build the repository system.
BUT…
No one built the sub-systems needed to organize, validate, and load material into the repository.
A good feasibility report with defined requirements would have foreseen this problem.

23. Feasibility Study: Benefits (Documentation)
Why is this project proposed? Can you quantify the benefits?
Suggested benefits:
Create a marketable product for increasing revenue by 10%
Improve the efficiency of an organization
Control complex systems automatically
Safety or security
Professional benefits are not the reason for doing a project.

24. Feasibility Study: Technical (Documentation)
A feasibility study needs to demonstrate that the proposed system is technically feasible:
An outline of the requirements
A possible system design
Database, distribution techniques, dynamic responses, data pipeline, input/output types, back-end system software, etc.
Possible choices of software to be used or developed
Estimates on number of users, data, transactions, network bandwidth, etc.
These rough numbers are part of the plan used to estimate staffing, timetable, equipment needs, etc.

25. Feasibility Study: Planning and Resources (Documentation)
The feasibility study must include an outline plan:

26. Feasibility Study (Documentation)
What information is needed before beginning a project?
Client:
Who is this project for?
Scope:
What are the boundaries of the project?
Benefits:
What are the benefits? Can they be quantified?
Technical:
Is the project possible? What are the SW/HW requirements?
Resources:
What are the estimates of staff, time, equipment, etc.?

27. Feasibility Study: Risk Management (Documentation)
A feasibility study should identify risks and alternatives.
Risks
Expectation of loss due to lack of information, control, or time.
What can go wrong?
How will risks be monitored and problems identified?
How will the team reduce the probability of risks?
What is the plan if a risk occurs?
Software development loss can come in many ways:
Increased production cost
Development of poor quality software
Missing deliverable deadlines

28. Feasibility Study: Risk Management (Documentation)

29. Feasibility Study: Risk Management (Documentation)
General Types of Risks:
Known knowns: risks that are facts known to the team\project.
Ex: Not enough dedicated time can delay or reduce quality in project deliverables.
Known unknowns: risks that the team is aware of but unsure they exist in this project.
Ex: Poor communication with the client may lead to many requirement/feature updates.
Unknown unknowns: risks the team knows nothing about.
Ex: Client wants development team to use a new (to the team) software language/API/Framework.

30. Techniques for Feasibly studies
The highest priority is to ensure that the client and development team have the same understanding of the proposed product.
For the development team to understand the system:
Interviews with the client
Review of existing systems, including competing/similar systems
Background research, reading journal/conference articles, technical papers, etc.

31. Feasibly study Techniques (Documentation)
Resource budget:
N people for H hours per week for M months
Equipment, development space, etc.

32. Feasibly study Techniques (Documentation)
Phases/Milestones:
Specify deliverables (designs, software, documentations, etc.) at certain deadlines (4 Milestones)
Gantt Charts
Activity Graphs

33. CS 360: Feasibility Report Challenges
Team:
How many hours per week? (should be 6 – 8 hours per person per week)
How often to meet as a group? Work individually?
Skillset of team members?
Time:
Must be completed by the end of the semester.
Including all software, documentation, and presentation resources
Equipment and software:
What special needs are there?
Start-up time:
Team creation, scheduling meetings, acquiring hardware and software, learning new systems, etc..
Too ambitious:
Nothing to show at the end of the semester..
What else?

34. CS 360: How to minimize Risk?
Techniques for managing risk:
Several target levels of functionality for project:
Required
Desirable
Optional
Visible software process:
Intermediate deliverables, models, prototypes, component modules, testing, live demos, etc.
Good communication:
Within the project group
With the client
Well defined development processes:
Good processes lead to good software and reduced risk

35. CS 360: Feasibility Study reports
Appoint one or two team members to read and edit the entire report before it is due.
Content:
If different authors write different sections, are the sections consistent?
Scope, plan, requirements, etc. agree on what is to be done?
Style:
Is the text comprehensible?
Does the report use jargon or sound unprofessional?

36. CS 360: Feasibility Studies Common Problems
Potential problems with feasibility reports:
The report is vague about scope.
The project scope should be clearly defined. Otherwise, it is not clear if the project is feasible.
The report does not describe project group activities in enough detail.
Detail is needed about all activities to convincingly estimate effort.
The project is too ambitious.
The report should describe how you will monitor the progress and adjust the scope if necessary.

37. CS 360: Feasibility Study Project Team Activity:
Meet with your group members to discuss the following:
Discuss project goals and scope
Every team member should read the AP course description
Review of existing systems like your project
Discuss and create your initial project timeline/Gantt chart
Discuss and create tasks/deadlines for the remainder of Sprint 1