ContentsSystemsIntroductionInformation systems modelsWaterfallClassicalIterativePrototypeSpiralRADUP

IntroductionWhat is a system?Elements of a systemSystem classificationan information system?Data and informationComputer based information systems

SystemsInformation SystemsAutomation SystemsGeographical Information SystemsKnowledge Management SystemsManagement Support SystemsContent Management SystemsEnterprise Resource Planning SystemsExpert SystemsEmbedded Systems

Biscuit Manufacturing Process

Information System ModelsWaterfallClassicalIterative PrototypeSpiralRapid Applications DevelopmentUP

Classical Waterfall ModelA cascade of phases

Feasibility StudyAnalysis & SpecificationDesignImplementationTestingMaintenanceDevelopment

Feasibility Study: AimsPreliminary investigationCurrent systemProblemsAlternate solutionsPrioritizationEvaluate solution strategies in terms of:Technical feasibilityEconomical feasibilityOperational feasibilityOrganizational feasibility

The Requirements PhaseAim: to document the customer requirements:i.e. the PROBLEM!A customer may be a single person, a group, a department, or an entire organization:often with many employees (potential users).This phase involves two distinct activities:requirements gathering and analysis;requirements specification.

Requirements gatheringGather Information via meetings, interviews and discussions:this information is typically inadequate at first each user has only a partial view of the system.Identify and eliminate errors:inconsistency (contradictions);vagueness (ambiguities);incompleteness (omissions).Clarification involves further gathering andanalysis of information.

Requirements AnalysisAim: to understand exactly what the customer needswhich may not be what they ask for:data to be input to the system;processing to be performed on these data;data to be output from the system;characteristics of the system as a whole;constraints on the system/project.WHAT, not HOW!RequirementsFunctional requirementsNon-functional requirements

Functional Requirements:Functional requirements describe a software system as a set of functions {f()}.Each function f() transforms a domain of inputs to a corresponding range of outputs:Input Data f() Output Data

Each function is described in terms of:the input from and output to the user;the processing required.

Functional Requirements: A black box specificationThe functional requirements are a black box specification of the system:only externally visible behavior (i.e. input and output) is documented;the internal details of the system are not known.

In short, the functional requirements describe what the system must do, but not how!

Input DataOutput Data

Functional RequirementsExample: F1 Find BooksInput: the name of an author.Output: details of any books by the author title, publisher, ISBN, etc.Processing: search library catalogue for books by the specified author.Book DetailsAuthor Namef()

Non Functional RequirementsThese are characteristics of the system that cannot be expressed as functions...security e.g. internet systems;reliability e.g. safety-critical systems;performance e.g. real-time systems;usability (human-computer interface);maintainability and portability.Non-functional requirements are within the control of the developers use metrics!

The Requirements Engineering Process

Requirements EngineeringRequirements DefinitionRequirements definition is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements.Requirements SpecificationA detailed and precise description of the system requirement is set out to act as a basis for a contract between client and software developer.

Requirements Analysis ToolsUse case diagramsActivity diagramsDocument flow diagramsData flow diagrams

The Design PhaseAim: to transform the specification into a form suitable for implementation in a programming language.Design is a creative activity so its hard!The software design is derived from the software requirements specification(SRS)document using one of two approaches:function oriented methods - e.g. Structured Analysis & Design (SA/SD);object oriented methods.

The development phaseThis is the coding and unit testing phase.Each module is implemented independently, as a stand alone unit:translation into source code and documentation;Unit testing and debugging.Unit testing ensures that each module works correctly in isolation.The end product of this phase is a set of independently tested software modules....

The testing phase: Integration TestingAim: to integrate modules in a series of carefully planned steps.Integrating modules one at a time makes error location and correction much easier:it would be foolish to integrate several different modules at the same timebig bang!At the end of each step the incomplete system is re-tested using ALL of the test data.

The testing phase: System TestingAim: to ensure that the system meets the requirements in the SRS document.System testing takes place after all the modules have been integrated:alpha & beta testing;stress & acceptance testing.The system is delivered to the customer at the end of this phase:you get paid, and maintenance begins.

The Maintenance PhaseFor almost all software products:maintenance requires far more effort than the development phases;the ratio of development effort to maintenance effort is typically 40:60.There is now considerable emphasis on designing software to be maintainable:this is supposed to be a major advantage of OO methods over traditional ones.

In reality

Iterative Waterfall ModeFeasibility StudyAnalysis & SpecificationDesignImplementationTestingMaintenance

The Prototyping ModelBefore starting development of the actual system, a prototype may be built.A prototype is a toy system (or part thereof):limited functionality;low reliability (often full of bugs);inefficient performance;inaccurate results.Nevertheless, prototypes help in developing high-quality software products!

Prototyping: Why Bother ?To demonstrate concepts to the customer:user interfaces, novel ideas, etc;e.g. GUI-based prototypes are commonly used to refine customer requirements.To explore difficult technical issues:major design and implementation decisions often depend on technical issues e.g. hardware performance;e.g. efficiency (in time & space) of software.

Prototyping: Why Bother ?Construction of a working prototype involves additional cost; however...Overall development cost might be lower for:systems with unclear requirements;systems with unresolved technical issues.User requirements are clarified and technical difficulties are resolved:omitting the prototype would lead to change requests, and hence redesign costs.

Prototyping :Method (Part 1)It may be impossible to get a system right the first time, so build one to throw away!Carry out a quick requirements analysis.Carry out a quick design.Build a prototype using short-cuts:e.g. use look-up tables rather than performing difficult computations;e.g. do not perform error checking or exception handling.

Prototyping :Method (Part II)Submit the working prototype to the customer for evaluation.Use customer feedback to refine the requirements, and hence the prototype.The cycle (phases 2-5) continues until the customer approves the prototype.The final system is then developed using the classical waterfall model.

The Prototyping ModelBuild PrototypeGather requirements Design PrototypeEvaluate PrototypeRefine requirements COMPUTER APPROVALImplementTestMaintenanceFEEDBACKDesign

The Prototyping ModelThe requirements phase is eliminated:the prototype (with customer feedback) serves as a specification.The prototype must be thrown away:however, the experience gained from it is invaluable for developing the final product.Never give in to management or customer pressure to patch the prototype for release:it will be a maintenance nightmare!

The Spiral ModelProposed by Boehm (1988):A spiral model of software development and enhancement. IEEE Computer, 21 (5), pp 6172.Each loop of the spiral focuses on a phase of the software process; for example:the innermost loop might be concerned with system feasibility;the next loop with requirements specification;the next with system design; and so on.

The Spiral ModelThere are no fixed phases in this model (the diagram that follows is just one example).The team must decide how to structure the project into tasks and iterations:there are typically 36 task regions (framework activities) per iteration.Work begins using a generic model; extra tasks and iterations are added, either:to suit specific projects; orwhen problems are identified.

Example: A Spiral ModelEach loop in this spiral is split in to four task regions(quadrants) :

Quadrant 1- Objective SettingThe objectives of the phase are identified:strategies for meeting these objectives are considered.Risks are also identified:a risk is loosely defined as anything that might hamper successful completion of a project;

Quadrant 2- Risk ManagementIn each iteration, the spiral model facilitates understanding of, and reaction to, risks.A detailed assessment is carried out for each potential risk to the project.Steps are taken to reduce the risks:e.g. if the requirements are vague, a prototype may be developed;e.g. if the project is short-staffed, its scope may be reduced, or more staff recruited.

Quadrant 3 & 4Quadrant 3 - Development and Validation:the next level of the product is developed and validated;this is not necessarily an implementation phase!Quadrant 4 - Review and Planning:the results are reviewed with the customer;the next iteration of the spiral is planned.Each iteration of the spiral yields a more complete version of the software product.

The Spiral Model: A Meta-ModelThe spiral model subsumes the other life cycle models:it retains the step-by-step approach of the classical waterfall model;it uses prototyping as a risk reduction mechanism;each iteration of the spiral is an incremental level.The classical waterfall model corresponds to a single iteration of a simple spiral model:but the reverse is not necessary true!

Rapid Application Development (RAD)Because of rapidly changing business environments, businesses have to respond to new opportunities and competition.This requires software and rapid development and delivery is not often the most critical requirement for software systems.Businesses may be willing to accept lower quality software if rapid delivery of essential functionality is possible.

Why RAD?Because of the changing environment, it is often impossible to arrive at a stable, consistent set of system requirements.Therefore a waterfall model of development is impractical and an approach to development based on iterative specification and delivery is the only way to deliver software quickly.

CharacteristicsThe processes of specification, design and implementation are concurrent. There is no detailed specification and design documentation is minimized.The system is developed in a series of increments.End users evaluate each increment and make proposals for later increments.System user interfaces are usually developed using an interactive development system.

Unified ProcessThe Unified Process (UP) is related to the spiral and incremental lifecycle models: highly iterative; highly configurable. Compared to other methodologies the UP is: adaptive, rather than predictive; 'agile', rather than 'heavy'. The Rational Unified Process (RUP) is a commercial package of information and tools for the UP.

The UP PhasesInception: conduct feasibility study, produce business plan, sign contract with customer (i.e. project sponsor). Elaboration (build the bones): build software architecture, plan schedule, manage risks. Construction (build the flesh): highly iterative phase involving implementation and testing. Transition: beta release of software; final delivery and installation.

The Unified Process: Example

1. InceptionInception is typically 10% of the project duration. Define the main project requirements and constraints. Produce a business model for the project, including risk analysis and management strategies. Define an architecture for the proposed system. Produce an initial use case model (1020% complete). Develop an overall project plan with major milestones. Client agrees with estimates of cost, schedule, and scope. Client agrees with the initial use case model but is aware that there is more to come.

2. Elaboration: Build The BonesElaboration is typically 30% of the project duration. Elaboration involves establishing an overall design for the system: most of the architectural (large-scale) design is finalised; however, most of the detailed design is done later. The end of this phase is the point of no return for the developer: the Use Case model is about 80% complete; an executable prototype is available; hardware requirements have been finalized.

3. Construction: Build The FleshConstruction is typically 50% of the project duration. Construction focuses on completing the elements that make up the software system: design work is still happening, but the emphasis is on implementation and testing; the first version of the software is implemented on hardware like that at the proposed installation site. testing begins in earnest, but continues into transition. Documentation is completed: user manuals, training courses, release information.

4. TransitionTransition is typically 10% of the project duration. The software is installed on site. The users are trained and let loose beta testing. Problems are documented and used to plan newreleases. If the software is replacing an existing system, thetwo may be run in tandem during transition: discrepancies between the output of the two systems are used to identify bugs in the new system.

IterationIteration occurs within each phase of the UP. Each discipline (see later) occurs in at least twophases, and some occur in all phases: e.g. project management. What changes from one phase to the next is theemphasis: e.g. elaboration emphasises requirements and design; e.g. construction emphasises implementation and testing.

Modeling ElementsThe UP uses four modeling elements:1 Workers: which team members perform which activities?2 Activities: which activities must be performed to produce the software?3 Artifacts: the result of an activity e.g. diagrams, test cases, code.4 Disciplines: which workers perform which activities to generate which artifacts?

Models & ViewsA Model is a representation of a software system.A View is a way of looking at a model.An analogy:Rodin's famous sculpture "The Thinker" is a model of a thoughtful gentleman who has misplaced his clothes.A sketch or photograph of "The Thinker" presents a single view of the model.

The Thinker by Auguste RodinFront ViewA close-up view

RUP ModelsRUP has a number of models:Business Model;Use Case Model;Design Model;Implementation Model;Deployment Model.

RUP 4+1 viewsUse Case view

Life Cycle Models: ComparisonThe Classical Waterfall Model:is a hopelessly simplistic ideal.The Iterative Waterfall Model:is one of the most widely used life cycle models;is only suitable for well-understood projects.The Prototyping Model:is suitable for projects that are not well understood;for example when the requirements are unclear.

Life Cycle Models: ComparisonThe Incremental (Evolutionary) Model:is suitable for large projects that can be decomposed into (almost) independent parts incrementally developed and tested;Incrementally delivered to the customer.The Spiral (Evolutionary) Model:is suitable for technically challenging projects or projects that are subject to various kinds of risks.The Rational Unified Process (RUP) is partly based on a variant of the spiral model.

ReferencesPfleeger, S. Software Engineering: Theory and Practice. Prentice Hall, 1997

Example of a manual based IS and a computer based IS school leaving certificate 2 - Automation is the use of control systems and information technologies to reduce the need for human work in the production of goods and services.4 - Knowledge that is organized and stored in a repository for use by an organization5 - The support of management tasks by the application of technologies. Sometimes called Decision Support Systems or Business Intelligence. Includes 6,76 - is the collection of procedures used to manage work flow in a collaborative environment. http://www.steptwo.com.au/papers/kmc_what/index.html7 - Enterprise Information Systems - EIPs view information across entire organizations. Specialized systems include ERM, ERP.8 - Technologies that apply reasoning methodologies in a specific domain. Attempts to mimic human experts problem solving9 - An embedded system is some combination of computer hardware and software, either fixed in capability or programmable, that is specifically designed for a particular function. Industrial machines, automobiles, medical equipment, cameras, household appliances, airplanes, vending machines and toys

If a biscuit manufacturing company wants to ensure a quality biscuits to be manufactured. They need to come up with a well defined process.

How do they ensure that the biscuits are of the same quality?

The need to test samples of biscuits at every step of the manufacturing process. If there are defects they should address them.

In this analogy each biscuit or (biscuit batch) represents a software being manufactured by the software development company. The goal of a software development company is to ensure that all the software that they produce are excellent and meet the customers requirements. Without a proper process this is impossible. Without a process one project might work, many others will fail for different reasons.

There is a company that manufactures SOAP. Lets assume that they have their own distribution system where they send supplies to their agents throughout the country. They want to effectively manage their sales force. The agents use their own sales reps to deliver goods to the Shops.

The manager wants every sales rep to be given a PDA to enter details of sales when they visit shops. He also wants the system to be operated by voice and support sinhala, tamil and english. So when an invoice is made, the sales rep would dictate the order placed using voice in a language he is familiar with.

What are the problems of such a scenario ?

One is the cost would be expensive for getting PDAs.

There would be a technical difficulty getting the system to recognize voice in all three languages.

What could be the solutions to the scenario.

Using a Mobile phone, since everyone would have a mobile phone anyway (e.g. A Java based mobile solution)

Voice Dictation is probably prefered because it can be arguably faster. Instead a easy to use interactive GUI could be used that allows the sales rep to enter details quickly.

Its menus could easily support all three languages.

How do you go about developing such a scenario.

Get the details of the system (Requirements phase)

Meet the General Manager have an interview, meet other operational people in the Stores, Sales Distributions, Agents, Sales Rep, Clearks etc.

Inconsistencies When you ask the Distribution Manager how the items are delivered to the agents, he might say that the company sends its own delivery vehicle to all the agents based all over the country. But when you speak to the agent a particular agent says that actually he sends his vehicles to the regional stores and gets the items since there are delays in getting the items directly from the company through companies distribution system.

Who is correct? What is this Regional Stores?

You can speak to the Distribution Manager about this particular Agent to clarify this. Maybe for certain districts they initially stock the regional stores only and then the agents have to pick up the items from there.

Vagueness (Ambiguities) The Marketting Manager says he wants to get details of individual sales at each shop periodically. Does this mean monthly reports, weekly reports etc?. The IT manager says the system should be user friendly? Does this mean using voice commands, would a gui be sufficient with combo boxes etc.

Incompleteness - How are the returns of goods handled handled. Are they sent back when the sales rep visits the shops and sent back through the agents.

Important to emphasise What