Programming Fundamentals

Programming Fundamentals

Software Life Cycle • History • The "waterfall model", documented in 1970 by Royce was the first publicly documented life cycle model. The model was developed to help cope with the increasing complexity of aerospace products. The waterfall model followed a documentation driven paradigm. The next revolutionary new look at the development lifecycle was the "spiral model", presented by Boehm in 1985. The spiral model is focused on risk management.

Software Life Cycle • DEFINITION • System Development Life Cycle (SDLC) is the overall process of developing information systems through a multistep process from investigation of initial requirements through analysis, design, implementation and maintenance. There are many different models and methodologies, but each generally consists of a series of defined steps or stages.

Software Life Cycle • Why use Software Models? • Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises

Software Life Cycle • Why use Software Models? • To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. • The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next.

Software Life Cycle • Why use Software Models? • These stages can be characterized and divided up in different ways, including the following: • Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals. • # Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs. • Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.

Software Life Cycle • Why use Software Models? • These stages can be characterized and divided up in different ways, including the following: • Implementation: The real code is written here. • Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. • Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. • Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

Software Life Cycle • Why use Software Models? • But It Doesn't Work! • The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."

Software Life Cycle • Why use Software Models? • But It Doesn't Work! • Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed. • The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.

Software Life Cycle • Why use Software Models? • But It Doesn't Work! • The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology. • Build and fix is the crudest of the methods. Write some code, then keep modifying it until the customer is happy. Without planning, this is very open-ended and can by risky.

Software Life Cycle • Why use Software Models? • But It Doesn't Work! • In the rapid prototyping (sometimes called rapid application development) model, initial emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness. The prototype is an essential part of the requirements determination phase, and may be created using tools different from those used for the final product. Once the prototype is approved, it is discarded and the "real" software is written. • The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.

Software Life Cycle • Why use Software Models? • Big Time, Real Time • The synchronize and stabilize method combines the advantages of the spiral model with technology for overseeing and managing source code. • This method allows many teams to work efficiently in parallel. This approach was defined by David Yoffie of Harvard University and Michael Cusumano of MIT. • They studied how Microsoft Corp. developed Internet Explorer and Netscape Communications Corp. developed Communicator, finding common threads in the ways the two companies worked. • For example, both companies did a nightly compilation (called a build) of the entire project, bringing together all the current components.

Software Life Cycle • Why use Software Models? • Big Time, Real Time • They established release dates and expended considerable effort to stabilize the code before it was released. • The companies did an alpha release for internal testing; one or more beta releases (usually feature-complete) for wider testing outside the company, and finally a release candidate leading to a gold master, which was released to manufacturing. At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs.

Software Life Cycle • Methods • Life cycle models describe the interrelationships between software development phases. The common life cycle models are: • spiral model • waterfall model • throwaway prototyping model • evolutionary prototyping model • incremental/iterative development • reusable software model • automated software synthesis

Software Life Cycle • Methods • Because the life cycle steps are described in very general terms, the models are adaptable and their implementation details will vary among different organizations. • The spiral model is the most general. • Most life cycle models can in fact be derived as special instances of the spiral model. • Organizations may mix and match different life cycle models to develop a model more tailored to their products and capabilities.

Software Life Cycle • Learn • A software life cycle model depicts the significant phases or activities of a software project from conception until the product is retired. It specifies the relationships between project phases, including transition criteria, feedback mechanisms, milestones, baselines, reviews, and deliverables. • Typically, a life cycle model addresses the following phases of a software project: requirements phase, design phase, implementation, integration, testing, operations and maintenance. • Much of the motivation behind utilizing a life cycle model is to provide structure to avoid the problems of the "undisciplined hacker".

Software Life Cycle • Spiral Model • The spiral model is the most generic of the models. Most life cycle models can be derived as special cases of the spiral model. • The spiral uses a risk management approach to software development.

Software Life Cycle • Spiral Model • Some advantages of the spiral model are: • defers elaboration of low risk software elements • incorporates prototyping as a risk reduction strategy • gives an early focus to reusable software • accommodates life-cycle evolution, growth, and requirement changes • incorporates software quality objectives into the product • focus on early error detection and design flaws • sets completion criteria for each project activity to answer the question: "How much is enough?" • uses identical approaches for development and maintenance • can be used for hardware-software system development

Software Life Cycle • Waterfall Model • The least flexible and most obsolete of the life cycle models. • Well suited to projects that has low risk in the areas of user interface and performance requirements, but high risk in budget and schedule predictability and control.

Software Life Cycle • Throwaway Prototyping Model • Useful in "proof of concept" or situations where requirements and user's needs are unclear or poorly specified. • The approach is to construct a quick and dirty partial implementation of the system during or before the requirements phase.

Software Life Cycle • Evolutionary Prototyping Model • Use in projects that have low risk in such areas as losing budget, schedule predictability and control, large-system integration problems, or coping with information sclerosis, but high risk in user interface design.

Software Life Cycle • Incremental/iterative Development • The process for constructing several partial deliverables, each having incrementally more functionality.

Software Life Cycle • Automated Software Synthesis • This process relies on tools to transform requirements into operational code. Formal requirements are created and maintained using specification tools. • This is an active research area, and practical tools for this approach are yet to be developed.

What Is Programming? • Simply put, programming is the process of creating a set of instructions for the computer to follow. • These instructions are written in a language or languages which people can understand, and then "compiled" (literally, translated) into machine language, or interpreted by the computer from reading a script. HTML is a programming language, as are Javascript and VBScript. • The "syntax" of a programming language consists of the various language elements, conventions, and operators that are used to write the instructions.

Definitions of algorithm • A mathematical relation between an observed quantity and a variable used in a step-by-step mathematical process to calculate a quantity. In the context of remote sensing, algorithms generally specify how to determine higher-level data products from lower-level source data. For example, algorithms prescribe how atmospheric temperature and moisture profiles are determined from a set of radiation observations originally sensed by satellite sounding instruments. • is a procedure or formula for solving problems

Definitions of algorithm • A computer program (or set of programs) which is designed to systematically solve a certain kind of problem. WSR-88D radars (NEXRAD) employ algorithms to analyze radar data and automatically determine storm motion, probability of hail, VIL, accumulated rainfall, and several other parameters • A finite set of well-defined rules for the solution of a problem in a finite number of steps. • A set of rules that a search engine uses to rank the listings contained within its index, in response to a particular query.

Difference between Algorithm & Program • For small programs there's little value in planning - in fact, you'll probably end up wasting time. • As far as individual algorithms go, it's usually best to go with whatever seems the easiest to understand and only do more advanced things once you know that you need more speed or something like that.

Difference between Algorithm & Program • That's a pseudocode implementation of an algorithm. You can describe an algorithm in human language, in pseudocode or in a programming language. • create an empty jumble word while the chosen word has letters in it extract a random letter from the chosen word add the random letter to the jumble word

Difference between Algorithm & Program • That's actually *longer* than just writing the algorithm in Python directly, which is why we say that Python is executable pseudocode :). • Pseudo-code design has IMO little value in Python and should stop at a higher level if it's used at all. In this example I'd have said this before going to Python code: randomize letters in word

Difference between Algorithm & Program • By going into too much detail, you've actually overlooked the fact that you're recreating functionality from the Python standard library: random.shuffle. • If the prog. is like

Difference between Algorithm & Program #Game List list = ("GT4", "GTA Sanandreas", "Takken 5") print "My Games: " for i in list: print i print "\nI've got", len(list), "games."

Difference between Algorithm & Program add = raw_input(\n\nAdd more games: ") adding = (add) list += adding print "Total games are..." print list raw_input("exit.")

Difference between Algorithm & Program • The pseudocode could be something like this: list all games show nr. of games get the name of a new game add the new game list all games exit

Difference between Algorithm & Program • If you go into more detail, you'll end up writing a long version of the Python code, which kind of defeats the purpose of pseudocode.

Difference between Algorithm & Program • Useful advice for algorithm • It's more important (at least for larger progams) to think about good design in terms of modules, classes and functions than in terms of individual lines of code. Always stop designing when designing becomes as low-level as just writing the code.

Sequential Algorithm • Write an algorithm to find the average marks of a students he has obtained in three subjects: Step 1: Start Step 2: Accept num1, num2, num3 Step 3: sum = num1 + num2 + num3 Step 4: avg = sum/3 Step 5: display avg Step 6: Stop

Good Programming Style • Consistency • One of the hallmarks of good programming style is consistency--the fewer surprises, the better. • Consistency makes it easier to read the program primarily by reducing distractions. • But it also helps guide the reader's eyes, for example, by being consistent about ordering functions or including files to simplify finding them in the future. • It also makes it easier to deal with other style problems by making it easier for the reader to get used to them.

Good Programming Style • Clarity • Good style is about making your program clear and understandable as well as easily modifiable. • When in doubt, choose the most easily understood technique for a problem. • Remember that whatever you write, you will likely have to read at some point after you remember exactly what you were thinking. • Do your future self a favor and be clear the first time.

Good Programming Style • Whitespace and Formatting • Whitespace can set things off and reduce the strain on the reader's eyes. Because the compiler ignores whitespace, you're free to place things anywhere you want and format it however you want. • If you choose wisely, this can be a boon. • Whitespace comes in several forms, including indentation, how you put space around operators, how you lay out function ????declarations???, and where you place arguments to functions. • Of course, this is hardly everything covered by whitespace, but it should give you an idea of the many places whitespace can be used to improve readability.

Good Programming Style • Whitespace and Formatting • Indentation • If you don't indent your code, you soon will. It's just a natural thing to do because it lets you use your eye to quickly pick out the flow of control or mistakes in that flow of control. • The quick primer on indentation is that you should indent every block of code: if ( true ) { // code block }

Good Programming Style • Whitespace and Formatting • Brace Styles • There are a variety of ways to indent code, and many of them are tied to where you place your braces. Some people prefer the style used above. • Some people prefer the style below: if ( true ) { // code block }

Good Programming Style • Whitespace and Formatting • Brace Styles • Other styles include if ( true ) { // code block } • or even if ( true ) { // code block }

Good Programming Style • Whitespace and Formatting • Brace Styles • Any brace style you choose is up to you, although I'd recommend using the same brace style as everyone else working on your project. At any rate, there are arguments for each style. A good consideration is to use a brace style that allows you to put as much code on a screen at a time, but consistency with past practices is probably just as important.

Good Programming Style • Whitespace and Formatting • Indentation Depth • How far you choose to indent is a matter of personal preference--in any case, it's usually best to choose an indentation size that's small enough to comfortably fit your code on one screen. • I've found that any indentation width from 2 to 8 is reasonable and readable, although I've found that anything over four spaces for indentation can lead to lines that are too long. • In general, the best solution to dealing with lines that are too long is to reduce the complexity of the code or at least to pull out some functionality into separate functions. • Doing so will reduce the number of levels of indentation and can make the code more readable (if it is done correctly).

Good Programming Style • Whitespace and Formatting • Tabs vs. Spaces • There is something of an argument over whether to indent using tabs or spaces. • Note that this is not the same as asking whether you indent with the spacebar or the tab--most people let their editors take care of that problem for them (or choose to have tabs expanded to spaces). • The real issue of tabs vs. spaces is what happens when someone else opens your code. • Since you can set tabs to take up any number of columns, the person opening your code might not have the same tabstop width. • This can play havoc with otherwise well-formatted code. Using only spaces fixes this problem because it will always display the same way for everyone.

Good Programming Style • Whitespace and Formatting • Tabs vs. Spaces • Sometimes a decent code formatter, such as might be found in your text editor, can help mitigate this problem by reformatting the code. • You can also play with your own tab settings to display the code correctly (although this is obviously annoying). • The best solution, if you do decide to use tabs, is to be very careful with what you use tabs for. • The real problem, in fact, comes up when tabs are used not just for indentation but also as a quick way of moving four or eight characters to the right.

Good Programming Style • Whitespace and Formatting • Tabs vs. Spaces • For instance, let's look at the following code: if ( a_long_case_number_one_stretching_across_most_of_the_screen && a_long_case_number_two_also_stretching_across_most_of_the_screen ) { // code }

Programming Fundamentals