CS 5150 Software Engineering Lecture 3 Software Processes 2

CS Project Teams I will send out project suggestions this afternoon You should have a team soon Send to Ben & Yue when you have (most of) a team Team name Names of team members Client info Project topic

CS Projects Project suggestions continuing to come in You should have contacted a client by next week

CS Project Details

CS Software Processes in More Detail Feasibility and planning Requirements System and program design Implementation Acceptance and release Operation and maintenance

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)