CS3500 Software Engineering Legacy Systems (1) Legacy systems are software (and sometimes hardware) systems that have been developed sometime in the past using older or obsolete technology (e.g. COBOL).  Often serve business-critical functions  Often too risky to replace them  Often were developed to run on centralised mainframe machines and then modified (but not re-designed) to run on distributed PC networks  very significant source of errors

CS3500 Software Engineering Legacy Systems (2)  Staff & budget shortages mean that legacy software persists in organisations rather than being replaced – obviously progress IS being made in eliminating old obsolete systems  Legacy systems require that obsolete skills be maintained (e.g. there is still a need for COBOL and DIBOL programmers although it is unlikely that much new software has been written in these languages for the last 20 years or more.  Legacy systems are extremely expensive to maintain because (a) they were usually not built with modification in mind (b) written in 2 & 3 GL code which has low productivity

CS3500 Software Engineering Software Development Models (1) Several different strategies have been developed for building software systems. This is so because  Experience has pointed to new and improved means for SD  Different kinds of systems may require different development approaches  New languages/development tools have allowed the development of novel SD strategies which would previously have been impossible These different strategies or approaches are referred to as software development models. In reality, a development team may tailor (modify) a model to suit themselves or indeed mix-and-match and borrow from several models in building a single system Read on this topic!

CS3500 Software Engineering Software Development Models (2) Waterfall Prototyping Agile Programming Exploratory Programming Object-oriented analysis & design Formal specification methods System assembly from re-usable components

CS3500 Software Engineering Software Development Models – Waterfall (1)

CS3500 Software Engineering Software Development Models – Waterfall (2) The Waterfall approach is process-centred and data-sensitive. Project work is broken down into separate phases for management purposes Each separate phase is allocated personnel, a budget and a time deadline for completion Phases have specific “exit criteria”. i.e. defined work elements that must be completed to standard before that phase can be signed off and next phase begun. (Exit criteria examined by an independent inspection team during a planned formal technical review (FTR)) Read about reviews and inspections! Understand these terms!

Software Development Models – Waterfall (3) CS3500 Software Engineering Advantages:  Should force tight control over budgets & time and therefore fit with traditional management culture  Should produce systems with good structure and architecture (making testing and modification/maintenance easier)

CS3500 Software Engineering Software Development Models – Waterfall (4) Disadvantages:  Imposing deadline on critical phases such as requirements gathering/analysis and testing can have disastrous consequences. (Read and find out why!)  More natural to develop requirements iteratively  System users not sufficiently included in the design process  A “working” system doesn’t appear until close to the end of the project – especially with a “bottom-up” development approach. Even a partially working system would provide the basis for gathering, understanding and discussing requirements. Read about “iteration” and “software development”

CS3500 Software Engineering Software Development Models – Prototyping(1) Prototyping involves iteration ! Read about “iteration” and “software development” “Mock-up” = a working but incomplete model of something

CS3500 Software Engineering Software Development Models – Prototyping(2) “ outline ” Prototyping involves users& developers in a quick & partial specification & Implementation of requirements The “mock-up”!

CS3500 Software Engineering Software Development Models – Prototyping(3) ) Ideally, the prototype should be regarded just as a way or mechanism by which a full set of requirements can be acquired. In the last diagram, the prototype is used to provide the specification and the basis on which the system will be designed and implemented. Also, some software components many be provided by the prototyping exercise.

CS3500 Software Engineering Software Development Models – Prototyping(4) A prototype is built and used only for the purpose of providing a rough demonstration of how requirements could be implemented and as a means of acquiring additional requirements from users. Prototype is then discarded and the software is engineered using a fresh design paradigm (model) Throwaway Prototyping (closed-ended):

CS3500 Software Engineering Software Development Models – Prototyping(5) ) Prototype is refined and new requirements and features added with each iteration. The prototype ultimately becomes the completed product. It is importantto note that systems built using this open-ended approach are more likely (1) to retain more embedded errors, (2) have a less well-defined structure (architecture) and (3) be more expensive to modify/maintain than systems built using the throwaway strategy. Evolutionary Prototyping (open-ended): Essentially the same as exploratory programming (see later)

CS3500 Software Engineering Software Development Models – Prototyping(6) Think about when you would use closed-ended and when you would use open-ended ?

CS3500 Software Engineering Software Development Models – Prototyping(7) ) In general, any application that creates dynamic visual displays, interacts heavily with a user or requires algorithms that must be developed in an evolutionary fashion is a candidate for prototyping. On the other hand, if an application will require the development of tens of thousands of lines of code before its functions can be visibly demonstrated then it is likely to be too complex for prototyping.

CS3500 Software Engineering Software Development Models – Prototyping(8) The keys to successful prototyping:  an appropriate application  selection of right approach (closed or open)  heavy user involvement during iterations  availability of appropriate tools such as 4G languages and tools which enable the software engineer to generate executable code quickly and/or  the availability of a library of software components from which a prototype can assembled, at least in part.