1. CS 5150 Software Engineering Lecture 4 Feasibility Studies

2. CS 5150 2 Projects You should have a team at this point Contact your (potential) client soon, if you haven’t already The feasibility study and plan is due in just over 2 weeks Agreement with client is the most important step If you’re doing your own project, also check with course staff before the feasibility study

3. CS 5150 3 Software Processes for Open Source Last time you talked in small groups about whether software processes make sense for open source projects... or maybe some kinds of open source projects What are your thoughts?

4. CS 5150 4 Feasibility Study Analysis undertaken before committing to a project Leads to a yes/no/rework decision Often contains a projected budget, and leads to a formal budget request Sometimes takes the form of a proposal

5. CS 5150 5 Major Difficulty: Uncertainty Benefits are hard to quantify Approach is usually ill-defined. Cost, risk and timetable estimates are very rough at this point Organizational/external changes may be needed for the project Feasibility studies depend heavily on the judgment of experienced leaders Mistakes made early in a project are often expensive to correct

6. CS 5150 6 The Importance of Advocacy Advocacy is often a major factor in overcoming the inaction that naturally accompanies uncertainty Enthusiasm is necessary, but enthusiasts under-emphasize costs and risks (sometimes intentionally; always subconsciously) The people evaluating a project often have an interest in seeing it go forward

7. CS 5150 7 The Decision Maker’s Criteria Client: Who is the project for? Do we care? Scope: What are the boundaries of the project? Benefits: Can the benefits be quantified? Technical: Do we have a clear sense for how to implement the project? Resources: Estimated staff, time, equipment needs? Alternatives: What are the options if we don’t do the project?

8. CS 5150 8 Decision Makers Hate Risk Technical There must be a rough initial plan for completing the project The plan must acknowledge substantial uncertainties External Every project depends to some extent on external stakeholders Are there potential users? people who don’t want to see the project succeed?

9. CS 5150 9 System Ecosystem Systems live in an ecosystem. Is there a friendly one for this project? Management expertise in developing organization? Technical expertise in-house or contracted?

10. CS 5150 10 Example 1 Decision before feasibility report Government agency that manages a huge number of documents is slowly moving from paper to digital storage

11. CS 5150 11 Chronology University S developed a prototype system Funds were “procured” from congress to develop a major system The National Academy of Sciences was commissioned to do a feasibility study Problems: The money was already there! Feasibility study only looked at technical issues

12. CS 5150 12 Obvious Problems Organizational The agency management were not prepared to lead a large technology project No thought given to workflow and job changes Preparation No preliminary study to evaluate the properties of the documents to be managed (volume, privacy, secrecy, etc)

13. CS 5150 13 Outcome: Deeply Flawed System No one wants to return money to congress Feasibility study was given short-shrift Agency adopted a pure waterfall model The system has had limited success

14. CS 5150 14 Scope The boundaries of the system Included and excluded high-level functionality Dependencies Current systems to be replaced or augmented Confusion over scope is very common

15. CS 5150 15 Example 2 Government library contracted out for a “repository system” to manage data Contractor built software to store and manipulate complex digital material Nobody built a system to load and validate the database in the first place The library thought that was implicit in the project The contractor disagreed

16. CS 5150 16 Benefits Can potential benefits be quantified? Marketable product? Market size? Improved efficiency? New capability? Improved safety or security? Personal development is not a good justification for a project, but organizational development can be

17. CS 5150 17 Technical Feasibility Rough draft of the requirements Rough draft of high level design (i.e. architecture) List of expected frameworks/libraries to be acquired/used High-level scale estimates (number of users, size of data, etc) Assessment of existing team’s experience

18. CS 5150 18 Planning and Resources A feasibility study must have a rough plan Estimates for staffing, equipment needs, project timetable Major milestones and decision points Interactions with external stakeholders Deliverables and delivery dates (Later lecture on planning details)

19. CS 5150 19 Alternatives and Risks Major alternatives Revise or rewrite? In-house or contracted out? Delivery phases and points to change course Risks What can go wrong? How will we know (visibility)? Are there palatable alternatives?

20. CS 5150 20 The Report A written document to be archived with the project Must be accessible to all stakeholders Short enough that people will read it Clear writing is crucial Should spend more time writing and revising than any other document in the project

21. CS 5150 21 Use Case Stories Powerful tool for bridging the gap between users/clients and developers Write short “stories” with “characters” using the software you are going to develop Keep them short! Add just enough fun detail to get the brain in story mode

22. CS 5150 22 5150 Feasibility Report Specific requirements Outline plan Discussion of business considerations Risk analysis

23. CS 5150 23 5150 Check List Team. Hours/week? Skills/experience? Time. Little flexibility here Should have at least one fall-back point Equipment/software. Any special needs? Client. Any concerns about client availability? Overhead. Time for meetings, setting up systems, etc. Business considerations. Is your plan too ambitious?

24. CS 5150 24 Example Reports Two example reports are linked on the course website

25. CS 5150 25 Feasibility A feasibility study precedes the decision to start a project What is the scope of the project? What relevant experience to the participants have? Projected benefits? Projected costs, risks, timetable? Beware McConnell’s wicked problem But don’t appeal to it too quickly

26. CS 5150 26 Feasibility for 5150 Mostly a scoping aid Sketch out projected work More in next lecture

27. CS 5150 27 Requirements Define the system’s behavior from the client’s perspective Higher resolution than feasibility study Priorities -- relative importance Can be developed before design or incrementally

28. CS 5150 28 System and Program Design Define the system from the implementer’s perspective System design (or architecture) High level. Should fit on a white board for 5150 Program design “Medium level” Source of much debate in software engineering

29. CS 5150 29 Implementation (Construction) Actual coding Or acquisition and integration of existing code

30. CS 5150 30 Acceptance and Release The system is tested against the requirements by the client The system is transferred to the client or made available to the public

31. CS 5150 31 Operation and Maintenance Operation: The system is in active use Maintenance: Errors and other problems are identified and fixed or triaged Evolution: The system is changed in response to changing requirements and priorities This might involve a whole new cycle through a software process Phase out: Use of the system ends (abruptly or gradually) The software life cycle

32. CS 5150 32 Three Categories of Testing User testing Using mock-ups, prototypes or the actual system to evaluate usability with real potential users Program testing The development team makes sure the system works as designed Acceptance testing The client compares the system with the requirements

33. CS 5150 33 What is a Software Process? More or less formal rules for organizing work on software Trivial example: Meeting with client Meeting with team Code code code Test Email finished program to client

34. CS 5150 34 Spectrum of Software Processes (Modified) waterfall model Iterative refinement Incremental (Agile)

35. CS 5150 35 The Waterfall Model

36. CS 5150 36 Iterative Refinement

37. CS 5150 37 Incremental In each increment (sprint) the team works through the full software development cycle and ends up with new production-ready features Each sprint is assigned a fixed (and short) time frame, e.g. 4 weeks Team size involved in a sprint is usually small (5-10)

38. CS 5150 38 Waterfall Discussion Pros Visibility and predictability Separation of tasks Quality control at each step Cost control at each step Cons Wicked problems

39. CS 5150 39 Modified Waterfall This is more realistic

40. CS 5150 40 Iterative Refinement Discussion Pros Complete (bare-bones) system done quickly Can correct mistakes in early design stages Cons Throw away a lot of code Can encourage feature bloat Can lead to half-done features

41. CS 5150 41 Incremental Development Discussion Pros Leads quickly to production code Feedback benefits of iterative refinement, but even faster Minimizes wasted code Cons Haphazard high-level architecture

42. CS 5150 42 “Choosing” a Process Often heavily influenced by the project’s environment Big bureaucracies often like waterfall End user software vendors usually do something like iterative refinement Internet applications often developed with an incremental process

43. CS 5150 43 Thought Exercise Software process conversation dominated by commercial software developers Do these processes make sense for open source? What is open source? (Linux, Haskell compiler, Uncle Joe’s photo organizer)