CS 111 – Nov. 22 Chapter 7 Software engineering Systems analysis Commitment –Please read Section 7.4 (only pp ), Sections –Homework #2 due Nov. 29

Software engineering Large software systems cannot be written by 1 person Several people work together –Each is responsible for portion of program –These portions interact… so must make sure your piece will fit correctly in jigsaw puzzle –Example: developing user interface for registration system: Your output (list of desired course sections) must be in format expected by next phase of program –Deadlines

Tips for success General guidelines –Don’t reinvent the wheel –Make your solution efficient, elegant, easy to understand –Build solution incrementally, test & document often –It’s easier to fix a bug the sooner it’s found! –Work in pairs, check each other’s work Integrated development environment (IDE) –Software that simplifies job of writing code –As you type, “code” becomes color coded –Automates compiling and testing –Built-in debugger: can trace through instructions one by one, inspecting values of variables: rather than modifying code by inserting print statements!

Software life cycle Very similar to problem solving procedure 1.Problem specification written 2.Design of solution 3.Implementation 4.Testing 5.Maintenance

Systems analysis Distinction… –Software engineering is mainly concerned with implementation of the project –Systems analysis is mainly concerned with specification and design Definition of systems analysis (Whitten & Bentley): –“A systems analyst facilitates the study of the problems and needs of a business to determine how the business system and IT can best solve the problems and accomplish improvements for the business.” –The finished product is eventually a new or improved computer application, implemented by software engineers.

Principles Get the owners and users involved –The program you’re designing doesn’t belong to you. It’s to help other people. Find out what they desire. Follow problem solving procedure –Define what a suitable solution must accomplish / do. –Evaluate possible algorithms, and choose the best –After testing, evaluate new system’s impact, get feedback from stakeholders. Establish a schedule for the software life cycle –How much time do you have –How many people can you have on your team & for how long? –What are their strengths and weaknesses?

Principles (2) Establish coding and documentation standards –Your software engineers are writing code for you. Almost like they are students in your class. –Essential to have code written in a consistent style –Encourage good documentation  communication, including list of known problems. Let your people know they won’t be penalized for admitting their work is incomplete. You don’t want these to be a secret, or else risk future debugging. –Give people a list of deadlines of deliverables. –Have your team members meet with you to discuss their accomplishments. Is the project work cost-effective? –May need to scale down, trim some functionality or put off to later version.

Principles (3) Beware the “mythical man-month” –Doubling your staff will not make project take half the time. IBM found this out the hard way in its System/360 project. –Diminishing returns Don’t be afraid to scale down or cancel project –Project should have milestones / checkpoints to evaluate path toward success –Decide how to get back on track, or reduce scope of project. –Can final deadline be extended? –If doomed, abort project and cut losses. –But, will your superiors understand?

Principles (4) Divide and conquer –A large project can be overwhelming at first. Break into small, manageable parts. –Reminds me of studying for a final exam, or writing large essay. –Top-down design and bottom-up implementation. Design for future growth and change –Your project may be in service for 10+ years –People who adopt and like your work may want to continue using it forever. –You will have to live with decisions you make today. (For example, choice of programming language)