CS 5150 Software Engineering Lecture 4 Feasibility Studies

CS 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

CS 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?

CS 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

CS 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

CS 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

CS 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?

CS 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?

CS 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?

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

CS 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

CS 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)

CS 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

CS 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

CS 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

CS 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

CS 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

CS 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)

CS 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?

CS 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

CS 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

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

CS 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?

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

CS 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

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

CS 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

CS 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

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

CS 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

CS 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

CS 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

CS 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 finished program to client

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

CS The Waterfall Model

CS Iterative Refinement

CS 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)

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

CS Modified Waterfall This is more realistic

CS 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

CS 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

CS “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

CS 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)