Cs6403 unit I Software process and process management

1. Cs6403 unit ISoftware process and process management S Kharthikeyan Assistant professor, vcet-madurai

2. Introduction to software engineering • Is Software Dead??? • Software  an indispensable technology for business, science and engineering • Enables new creation of technologies (eg. Genetic engineering, Nano technology) • Extension of existing technologies (eg. Telecommunications : 2G - ??G) • Radical change in older technologies (eg. Printing industry) • Used in many domains like transportation, medical, telecommunications, military, industries, entertainment,.. the list is ENDLESS! • Software community continuously attempts to develop technologies that will make it easier, faster and cheaper to build and maintain high quality computer programs • Technology domain: Application (Websites), Technology (Object Oriented Systems), Broad based (Operating Systems like Linux, Android, iOS)

3. Nature of a software • Software  Product and also the vehicle for delivering the product • An information transformer • Produces, manages, acquires, modifies, displays, transmits information which are simple or complex • As a vehicle, software acts the basis for the control of the computer (OS), the communication of information (networks), creation and control of other programs • Software delivers information  transforming your personal data, managing some business information to enrich competitiveness, providing gateway to worldwide information networks

4. Nature of a software • Why does it take so long to get a software finished? • Why are development costs so high? • Why can’t we find all errors before a software is delivered to a customer? • Why do we spend so much time and effort in maintaining existing programs? • Why do we continue to have difficulty in measuring progress as software is being developed and maintained? • Leads to the adoption of software engineering practice

5. Definition of software • Instructions (computer programs) that when executed provide desired features, function, and performance • Data structures that enables programs to manipulate the information • Descriptive information in both hard copy and virtual forms that describes the operation and use of the programs

6. Characteristics : software vs hardware • Software is developed or engineered, it is not manufactured in the classical sense  activities are fundamentally different, high quality and good design required, both are dependent on people but the nature of work differs • Software doesn’t “wear out” (tire/exhaust) • Although industry is moving toward component based construction, most softwares continues to be custom built  Collection of standard designs, reusability. Eg: User Interface, Data Structure

7. Failure curve for software

8. Software application domains • System Software • Application Software • Engineering/scientific software • Embedded Software • Product-line software • Web applications • Artificial Intelligence Software

9. Software application domains • System Software – Collection of programs written to service other programs. Eg. Compilers, editors. Interacts heavily with the hardware, handles intermediate data, complex data structures, performs concurrent operations • Application Software – Stand alone programs solves specific business need. • Engineering/scientific software – characterised by algorithms

10. Software application domains • Embedded Software – resides within a product or system that controls specific features and functions for the user and for system itself. Eg. Keypad control for oven, dashboard displays etc • Product line Software – designed to provide specific capability for use by many different customers Eg. Word processing, DBMS, etc. • Web applications – called as WebApps are network centric software. Integrates corporate databases and business applications • Artificial Intelligence Softwares – uses nonnumerical algorithms to solve complex problems that cant be analysed straightforward. Applications include robotics, expert systems, pattern recognition, game playing, neural networks

11. Software – new categories • Open world computing—pervasive, distributed computing • Ubiquitous computing—wireless networks • Netsourcing—the Web as a computing engine • Open source—”free” source code open to the computing community (a blessing, but also a potential curse!) • Also … • Data mining • Grid computing • Cognitive machines • Software for nanotechnologies

12. Legacy softwares • Adapt to meet the needs of new computing environments or technology. • Enhanced to implement new business requirements. • Extended to make it interoperable with other more modern systems or databases. • Re-architected to make it viable within a network environment.

13. Attributes of webapps • Network intensiveness  A WebApp resides on a network and must serve the needs of a diverse community of clients. (Internet/Intranet) • Concurrency  A large number of users may access the WebApp at one time. • Unpredictable load  The number of users of the WebApp may vary by orders of magnitude from day to day. • Performance  If a WebApp user must wait too long (for access, for server-side processing, for client-side formatting and display), he or she may decide to go elsewhere. • Availability  Although expectation of 100 percent availability is unreasonable, users of popular WebApps often demand access on a “24/7/365” basis

14. Attributes of webapps • Data driven. The primary function of many WebApps is to use hypermedia to present text, graphics, audio, and video content to the end-user. • Content sensitive. The quality and aesthetic nature of content remains an important determinant of the quality of a WebApp. • Continuous evolution. Unlike conventional application software that evolves over a series of planned, chronologically-spaced releases, Web applications evolve continuously. • Immediacy. Although immediacy—the compelling need to get software to market quickly—is a characteristic of many application domains, WebApps often exhibit a time to market that can be a matter of a few days or weeks. • Security. Because WebApps are available via network access, it is difficult, if not impossible, to limit the population of end-users who may access the application. • Aesthetics. An undeniable part of the appeal of a WebApp is its look and feel.

15. Software engineering: Realities • Concerted effort should be made to understand the problem before a software solution is developed • Design becomes a pivotal activity • Software should exhibit high quality • Software should be maintainable

16. Software engineering: definition • [Software engineering is] the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

17. Software engineering: ieee definition • Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1)

18. A Layered Technology tools methods process model a “quality” focus Software Engineering

19. Layered technology • Quality focus: Bedrock that supports software engineering • Process : foundation for software engineering that glues technology, enables rational and timely development of computer software. Defines a framework for effective delivery of software

20. Layered technology • Methods: provide technical how-to’s for building software. Analysis, Design, Code, Test, Support • Tools : provide automated or semiautomated support for the process and methods

21. Software process • Process: Collection of activities, action and tasks performed when some product is created • Activity: Strives to achieve the objective and is applied irrespective of the application, domain, size of the project, complexity of the effort • Action: set of tasks that produces a major work product • Task: small well defined objective  tangible outcome

22. Software process framework • Establishes the foundation for complete software engineering process by identifying small number of framework activities applicable to all software projects, regardless of the size or complexity • Includes a set of umbrella activities applicable across entire software process

23. Framework activities • Communication • Planning • Modeling • Analysis of requirements • Design • Construction • Code generation • Testing • Deployment

24. Umbrella activities • Software project management • Formal technical reviews • Software quality assurance • Software configuration management • Work product preparation and production • Reusability management • Measurement • Risk management

25. Adopting a process model • the overall flow of activities, actions, and tasks and the interdependencies among them • the degree to which actions and tasks are defined within each framework activity • the degree to which work products are identified and required • the manner which quality assurance activities are applied • the manner in which project tracking and control activities are applied • the overall degree of detail and rigor with which the process is described • the degree to which the customer and other stakeholders are involved with the project • the level of autonomy given to the software team • the degree to which team organization and roles are prescribed

26. Software engineering practice • Essence of practice includes 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance).

27. Understand the problem • Who has a stake in the solution to the problem? That is, who are the stakeholders? • What are the unknowns? What data, functions, and features are required to properly solve the problem? • Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? • Can the problem be represented graphically? Can an analysis model be created?

28. Plan the solution • Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? • Has a similar problem been solved? If so, are elements of the solution reusable? • Can subproblems be defined? If so, are solutions readily apparent for the subproblems? • Can you represent a solution in a manner that leads to effective implementation? Can a design model be created?

29. Carry out the plan • Does the solution conform to the plan? Is source code traceable to the design model? • Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to algorithm?

30. Examine the result • Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? • Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements?

31. General principles of software engineering • 1: The Reason It All Exists – Value  YES/NO? • 2: KISS (Keep It Simple, Stupid!)  Simple Design • 3: Maintain the Vision  Clear vision, no compromise • 4: What You Produce, Others Will Consume  People should understand what you are doing • 5: Be Open to the Future  Systems must be ready to adapt the changes • 6: Plan Ahead for Reuse  Achieving high level of reuse is hard, reduces cost and increases value of components and the systems  • 7: Think! Place a clear and complete thought before action!!

32. Software myths    • Erroneous belief • Misleading attitudes that causes serious problems for managers and practitioners • Management Myths • Customer Myths • Practitioner’s Myths

33. Management myths    • Managers with software responsibility are always in pressure to maintain budgets, keep schedules from slipping and improve quality • Myth1: We already have a book that’s full of standards and procedures for building software. Won’t that provide my people with everything they need to know?    • Reality: ???

34. Management myths    • Myth II: If we get behind the schedule, we can add more programmers and catch up  Mongolian horde    • Reality: ??? Adding more people to a late software project makes it later!  • Myth III: I decide to outsource the software project to a third party, I can just relax and let that firm build it    • Reality: ??? • Organization would struggle if it doesn’t know how to manage and control projects internally! 

35. customer myths    • A person at the next desk, a technical group down the hall, marketing/sales department • Customer believes myths leading to false expectations and dissatisfaction with developers! • Myth I: A general statement of objectives is sufficient to begin writing programs – we can fill the details later   • Reality: ??? • Ambiguous statement of objectives is a recipe for disaster 

36. customer myths    • Myth II: Software requirements continually change, but change can easily be accommodated because software is flexible • Reality: ??? • Impact of change varies with time   

37. Practitioner’s myths    • Myth I: Once we write the program and get it work, our job is done.    • Reality: ??? • 60-80% of all effort are spent after its delivered to the customer for the first time    • Myth II: Until I get the program “running” I have no way of assessing its quality    • Reality: ??? • Software quality assurance mechanisms can be applied from inception of a project  technical reviews  

38. Practitioner’s myths    • Myth III: The only deliverable work product for a successful project is the working program    • Reality: ??? • Its only a part! There are variety of work products like models, plans, documents, etc    • Myth IV: Software engineering will make us create voluminous and unnecessary documentation and will invariably slow us down • Reality: ??? • Its not about creating documents, but creating quality products that reduces rework resulting in faster delivery times   

39. Process models • Roadmap that you follow to develop a software  Software process • Framework for the activities, actions, tasks to build high quality software • Is process synonymous with software engineering? • ‘YES and NO’

40. Generic Process model

41. Process flow • Describes how the framework activities and the actions and tasks that occur within each framework activity are organized with respect to sequence and time! • Four types of process flow • Linear – executes each of the framework in sequence • Iterative – repeats one or more activities before proceeding to the next • Evolutionary – executes the activities in a circular manner • Parallel – executes one or more activities in parallel with other activities

42. Process flow

43. Process flow scenario • Defining a framework activity • Identifying a task set • Process patterns

44. Process flow scenario • Defining a framework activity • For the given nature of the problem • Characteristics of people doing the work • Stakeholders who fund the project • Identifying a task set • List of stakeholders for the project • Invite them for meeting • Ask them to list features and functions required • Discuss the requirements and build final list • Prioritize the requirements • Note areas of uncertainty

45. Process flow scenario • Identifying a task set (for complex projects) • Make a list of stakeholders for the project • Interview each stakeholder and determine their needs individually • Build preliminary list of functions and features based on stakeholder input • Schedule a series of facilitated application specification meetings • Conduct the meetings • Produce informal user scenarios as part of each meeting • Refine user scenarios based on the feedback • Build a revised list of the requirements • Use quality function deployment technique to prioritize requirements • Package the requirements that can be delivered incrementally • Note the constraints and restrictions that will be placed on the system • Discuss the methods to validate the system

46. Process flow scenario • Process Patterns • describes a process-related problem that is encountered during software engineering work, • identifies the environment in which the problem has been encountered, and • suggests one or more proven solutions to the problem. • Patterns can be combined to solve problems and construct a process that best meets the needs of a project

47. Process flow scenario • Stage patterns—defines a problem associated with a framework activity for the process. • Task patterns—defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice • Phase patterns—define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature.

48. Prescriptive process models • Traditional process models • Advocate an orderly approach to software engineering That leads to a few questions … • If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? • Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

49. Prescriptive process models • Types • The Waterfall Model • The V-Model • The Incremental Model

50. The waterfall model • Classic life cycle model, suggest a systematic and sequential approach • A variation in the representation of waterfall model is the V-model