CS 5150 Software Engineering Lecture 4

1. CS 5150Software EngineeringLecture 4 • Feasibility Studies

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. 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. 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. 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. 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. 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. 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. 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. Example 1 • Decision before feasibility report • Government agency that manages a huge number of documents is slowly moving from paper to digital storage

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 5150 Feasibility Report • Specific requirements • Outline plan • Discussion of business considerations • Risk analysis

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. Example Reports • Two example reports are linked on the course website

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. Feasibility for 5150 • Mostly a scoping aid • Sketch out projected work • More in next lecture

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. 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. Implementation (Construction) • Actual coding • Or acquisition and integration of existing code

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. 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. 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. 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. Spectrum of Software Processes • (Modified) waterfall model • Iterative refinement • Incremental (Agile)

35. The Waterfall Model

36. Iterative Refinement

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. Waterfall Discussion • Pros • Visibility and predictability • Separation of tasks • Quality control at each step • Cost control at each step • Cons • Wicked problems

39. Modified Waterfall This is more realistic

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. 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. “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. 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)