Lecture 2

1. Lecture 2 COMSATS Islamabad Enterprise Systems Development (CSC447) Muhammad Usman, Assistant Professor CIIT

2. Confusion with Programs and Products

3. Software Programming ≠ Software Engineering • Software programming: the process of translating a problem from its physical environment into a language that a computer can understand and obey. (Webster’s New World Dictionary of Computer Terms) • Single developer • “Toy” applications • Short lifespan • Single or few stakeholders • Architect = Developer = Manager = Tester = Customer = User • One-of-a-kind systems • Built from scratch • Minimal maintenance

4. Software Programming ≠ Software Engineering Software engineering • Teams of developers with multiple roles • Complex systems • Indefinite lifespan • Numerous stakeholders • Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User • System families • Reuse to amortize costs • Maintenance accounts for over 60% of overall development costs

5. Lecture 2Software Systems and Their Development Life Cycle

6. Software Systems • Software Systems Vs Other Engineering Artifacts • Civil Engineers develop roads, bridges etc. • Electrical Engineers develop circuits, chips etc. • Aeronautical Engineers develop planes • Software Engineers develop software systems

7. Software Engineering Difficulties Software engineers deal with unique set of problems Young field with tremendous expectations Building of vastly complex, but intangible systems Software is not useful on its own e.g., unlike a car, thus It must conform to changes in other engineering areas Some problems can be eliminated These are Brooks’ “accidental difficulties” Other problems can be lessened, but not eliminated These are Brooks’ “essential difficulties” 7

8. Essential Difficulties Only partial solutions exist for them, if any Cannot be abstracted away Complexity Conformity Changeability Intangibility 8

9. Complexity No two software parts are alike If they are, they are abstracted away into one Complexity grows non-linearly with size (scaling-up) E.g., it is impossible to enumerate all states of program Except perhaps “toy” programs From complexity comes the difficulty of Communication Enumerating Less understanding of all the possible states of the program 9

10. Conformity • Natural Science – God VSSoftware – People • Much of the complexity that he (developer) must master is arbitrary complexity, forced without rhyme or reason by many human institutions and systems to which his interfaces must conform. • These (standards) differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God.

11. Changeability • The software entity is constantly subject to pressures for change. Of course, so are buildings, cars, and computers. But manufactured things are infrequently changed. • Software of a system embodies its function, and the function is the part that most feels the pressure of change • In part it is because software can be changed more easily – it is pure thought stuff, infinitely malleable

12. Changeability • Building do in fact get change but the high cost of change understood by all serve to dampen the whims of the changes • The software product is embodied in a cultural matrix of applications, users, laws, and machine vehicles. These change continually, and their changes inevitably force change upon the software product.

13. Invisibility • Software is invisible and un-visualizable. • A geometric reality is captured in a geometric abstraction • The reality of software is not inherently embedded in space • As soon as we attempt to diagram software structure, we find it to constitute not one, but several, general directed graphs superimposed one upon another. • This lack not only obstruct the process of design within one mind, it severely hinders communication among minds.

14. Software Systems • Software Systems are developed by software engineers. • What is software engineering? • Let us define it first and then we will move on with development of enterprise software systems

15. WHAT IS SOFTWARE ENGINEERING? • The term S/W Engineering was/is sometimes confusing, firstly because S/W engineer (some times) work as system programmer, people assume that the engineering component of the term comes from this source. SO we have H/W engg and S/W engg. • Second cause of confusion lies in the fact that there is no generallyagreed definition of software engineering, although many are similar. • Software Engineering as a term was first coined in 1968 at a NATO conference in West Germany held to discuss the software crises • Other definitions such as Fairley’s 1985 explicitly include the concerns of management in the software development process: • ‘Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.’

16. What is Software Engineering? (2) "The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines" [Bauer 1972]. "cost-effective Software engineering is that form of engineering that applies the principles of computer science and mathematics to achieving solutions to software problems.“ [CMU/SEI-90-TR-003] "The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software" [IEEE Standard Computer Dictionary, 610.12, ISBN 1-55937-079-3, 1990].

17. What is Software Engineering? (3) • Software engineering is concerned with the theories, methods and tools for developing, managing and evolving software products. [ I. Sommerville, 6ed.] • A discipline whose aim is the production of quality software, delivered on time, within budget, and satisfying users' needs. (Stephen R. Schach, Software Engineering, 2ed.) • The practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate and maintain them [B.W. Boehm] • Multi-person construction of multi-version software (Parnas,1987)

18. So, Software Engineering is… • Scope • study of software process, developmentprinciples, techniques, and notations • Goals • production of quality software, • delivered on time, • within budget, • satisfying customers’ requirements and users’ needs

19. Concept of Life Cycle • Software Systems, like other engineering artifacts, have a lifecycle • Examples • Your cell phone has a lifecycle • We human being also have a life cycle

20. System DevelopmentLife Cycle (SDLC) Maintenance 9 Review 8 Feasibility Study 1 Implementation 7 System Specification 2 Testing 6 Outline Design 3 System Development 5 Detailed Design 4

21. Project Life Cycle Perspective Spring 2010

22. SOFTWARE DEVELOPMENT PROCESS MODELS • Problem solving loop with basic four activities, i.e., problem analysis, problem definition, technical development and solution integration. • Regardless of the process model chosen, all the four activitiescoexist simultaneously at some level of detail. • A process model is chosen based upon the: • nature of the project, • application, • methods and tools to be used, and • controls and deliverables that are required.

23. The Linear Models

24. (1) The waterfall model • It suggests a systematic, sequential approach to s/w development. Important features • All activities are to be performed in an order and one after the other. The output of one is the input to the other. • Verification and validation is to be performed after the end of each phase. • The inputs & outputs at each phase must be defined (i.e. goal of each group is defined). • Once the outputs of a phase are produced (i.e. phase completed) then these should not be changed as it is input to the other. The certified output of a phase that is released for the next phase is called a baseline.

25. Feasibility Study Work Tasks & Work Products System Specification Outline design Feasibility Report Detailed Design System Development Req. Document Project Plan Testing & Integration System Design Document Implementation Det Design Document Review Maintenance Programs Test Plans, Test Reports And Manuals Installation Report Review Reports Supplements 25

26. Limitations of Waterfall Model • Limits and freezes the requirements of the system. • Suits to the automation of existing manual system. But having unchanging (or changing few) requirements is unrealistic for new systems. 2. Freezing requirements may result in purchase of an obsolete hardware as the software development usually takes years (and h/w technology is changing fast). 3.Does not support partial system development. This is specially required as client also plays important role in the requirement specification.

27. (2) Prototyping • This approach is developed tocounter the first two limitations of the waterfall model. • A customer may define a set of general objectives for software but does not identifydetailed input, processing, or outputrequirements. • The developer may be unsure of (1) the efficiency of an algorithm, (2) the adaptability of an operating system, or (3) the form the human machine interaction should take. • Instead of freezing the requirements before design, coding can proceed, a throwaway prototype is built to help understand the requirements.

28. Prototyping….. • This prototype is based on the currently available requirements and put on trail. • Although the development of prototype also goes through the design and coding phases but main stress is not put on formal procedures. • By using the prototype the user gets the true working environment of the actual system to be designed and developed later on. • Hence more realistic requirement of the required system are brought in. • Typically useful for the areas where asystem (manual or automated)does not existor the overall system is very large and complex. • Also provides an implemented feasibility, which provides effective method of demonstration.

29. Requirements Analysis Design Code Design Code Test Test Disadvantages: • The only drawback seems the duplication of efforts and cost involved in build-twice approach. Justifications: • Prototyping need not be very costly and can actually reduce the overall development cost. • The prototypes are usually not complete systems and many of the details are not built in. • In addition, cost of testing and writing detail documents is reduced, which reduces the cost of developing prototype. • Further the experience gained during prototyping is very useful for developers when developing the final system. This experience also reduces the cost of development of actual system, and results in more reliable and better design.

30. Problems to be tackled by Prototyping • Customer’s misconception (req-completion/communication, involvement, expectations, automation) • Developer’s wrong habits (Not strict to req, misunderstanding, assumptions/imaginations) • Rules of the game are not defined at the beginning

31. (3) RAD Model • Rapid application development (RAD) is a linear sequential S/W development process model that emphasizes on extremely short development cycle. • high-speed RAD is achieved by using a component-based project construction approach. • If requirements are well understood and project scope is constrained (i.e. goals/ are fixed / freezed); the RAD enables a development team to create a “fully functional system” within very short time (e.g. 60-90 days).

32. RAD Phases (1) 1. Business Modeling(Business Processes) Information flows among business functions is modeled such that answers the questions: • What information is generated? • Who generates it? • Who processes it? • Where does the information go? 2. Data Modeling(Entities) (1) The information flow is refined into a set of data objects that are needed to support the business. (2) Characteristics (attributes) of each object are identified and (3) Relationships between these objects are defined.

33. RAD Phases (2) 3. Process modeling (Processes/Functions) (1) The data object defined in the data modeling phase are transformed to achieve the information flow necessary to implement a business function (i.e. transformation of input-object to output object defines flow of information in a process/function) (2) Such processing descriptions are created for adding, modifying, deleting, or retrieving a data object. 4. Application Generation (1) RAD is based on the use of 4GT, rather than using 3GL. (2) RAD process works to re-use existing components (when possible). (3) Create re-useable components (when necessary). In all cases automated tools are used to facilitate construction of S/W.

34. RAD Phases (3) 5. Testing and Turnover (1) Re-use releases from testing, as such components, are already tested. (2) New components must be tested and all interfaces must be fully exercised. Optimally, (3) If a business application can be modularized such that each major function can be completed in less than 3 months time, each can be addressed by a separate RAD team, and then integrated (to give working system in 3-6 months) Drawbacks (1) For large scalable projects, RAD requires sufficient human resources to create right number of RAD teams. (2) RAD requires developers & customerscommitted to complete a system in a short time frame, other wise if commitment is lacking from either side, RAD projects will fail.

35. (4) The Incremental Model OR Iterative Enhancement Model 1. Solves the problem of 3rd limitation of the waterfall model. 2. Basic idea: software should be developed in increments; each increment adding some functionality until the full system is implemented. 3. At each step, extensions and design modifications can be made . 4. Applies linear sequences in a staggered fashion as time progresses.

36. increment 1 Code Test Design Analysis delivery of 1st increment increment 2 delivery of 2nd increment a n a l y s i s d e s i g n c o d e t e s t delivery of increment 3 a n a l y s i s 3rd increment d e s i g n c o d e t e s t a n a l y s i s d e s i g n c o d e t e s t increment n delivery of nth increment

37. Advantages • Major advantage: it can result in better testing since testing each increment is likely to be easier than testing the entire system. 2. Similar to prototype each increment provides feed back which is useful for determining further/final requirements of the system. 3. Model proceeds in steps starting from the simple and key aspects of the system. 4. A project control list is prepared that contains, in order, all the tasks to be implemented in the final system; provides a bettercontrol and progress monitoring of development.

38. (5) Spiral Model • The activities in this model can be organized like a spiral. The spiral has many cycles. • The radial dimension represents the commutative cost incurred in accomplishing the steps done so far, and • The angular dimension represents the progress made in completing each cycle of the spiral.

39. (1) Each cycle begins with the identification of objectives and different alternative possible to achieve the objectives. (2) In the next step different alternatives are evaluated and uncertainties and risks are identified. (3) Next step is to develop strategies that resolve uncertainties of risks and software development takes place. (4) Finally the evaluationis made to help plan the next stage. (5) The spiral is based on risk driven nature, which enables any mixture of specification-oriented, prototype-oriented, simulation-oriented, or some other approach.

40.     Features • Each Cycle is completed with a review, which covers all the products developed in that cycle. • Equally useful for development and enhancement projects. • More cycles can be added to add activities not covered in the model (e.g. feasibility) • Provides Project management and planning activities, in addition to development project.

41. Agile Development 2001: Kent Beck and 16 other software developers, referred to as “Agile Alliance”, signed the “manifesto for Agile software development”. It stated: Through this work we have come to Value: Individuals and interaction over processes and tool Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following plan That is, while there is value in the items on the right , we values the items on the left more.

42. Agile Methods • Agile software development is a group of software development methodologies that are based on similar principles. • Agile methodologies generally promote a project management process that encourages • frequent inspection and adaptation • a leadership philosophy that encourages team work • a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals

43. What are Agile Methods? • Agile software development is a conceptual framework for undertaking software engineering projects. • Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which may typically last one to four weeks. • Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality.

44. Agile Methods v/s Traditional Methods Agile methods emphasize real time communication, preferably face-to-face, over written documents. Agile methods like XP relies on the close collaboration of activity engaged individuals with ordinary talents and has the ability to flexibly schedule the implementation of functionality, responding to changing business needs. Reference: Extreme Programming explained: Embrace Change By: Kent Beck with Cynthia Andres; 2nd ed., 2005

45. Different Agile Methods? Extreme Programming (XP) Scrum Agile Modeling Adaptive Software Development (ASD) Crystal Clear and Other Crystal Methodologies Dynamic Systems Development Method (DSDM) Feature Driven Development Lean software development Agile Unified Process (AUP)