CS-70

1. CS-70 Introduction to Software Engineering

2. BLOCK 1. SOFTWARE ENGINEERING CONCEPTS | | <document classification>

3. UNIT1. Introduction to Software Product, Component and Characteristics | | <document classification>

4. What is Software? • Software: Programs that you use to make a computer do different things (Cambridge Learner’s Dictionary) • Instructions (Computer Programs) that when executed provide desired function and performance • Data structures that enable the programs to adequately manipulate information and • Documents that describe the operation and use of program (Software Engineering by Pressman) | | <document classification>

5. Characteristics of Software • SW is developed or engineered , it is not manufactured in classical sense • Software does not wear out • Most SW is custom built, rather than being assembled from existing components • Typically errors are high when software is built or changed and the error rates comes down • The cost of correction / change increases exponentially when we move ahead in the life cycle of a SW project | | <document classification>

6. What is Engineering? | | <document classification>

7. Software Engineering • Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, i.e. the application of engineering to software (IEEE) • 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 (Software Engineering by Pressman) | | <document classification>

8. Software Engineering:A Layered Technology | | <document classification>

9. Any engineering approach must rest on an organizational commitment to quality. Quality plays a major role in the software Engineering (TQM).The bedrock that supports software engineering is a quality focus. • Process defines a framework for a set of key process areas.(“A process defines who is doing,what ,when and how to reach a certain goal” ) for effective use of software technologies. It Forms a basis for management control and establishes context in which technical methods are applied, work products produced, milestones established, quality is ensured and change is managed. | | <document classification>

10. Software engineering methods provide the technical how-to’s for building software. Software Engineering Methods rely on a set of basic principles that govern each area of the technology and include modeling activities and other descriptive techniques. • Software Engineering Tools provide automated or semi automated support for the process and methods.(CASE tools) | | <document classification>

11. Software Engineering Phases • The Study Phase • The Design Phase • The Development Phase • The Operation Phase | | <document classification>

12. Documentation of the Software Product The three baseline Specifications • Performance specification:This is the result of study phase • Design Specification:This results at the end of the design phase • System Specification:This results at the end of development phase and consists of all the system documentation. | | <document classification>

13. Build first version Modify until client satisfy Build and Fix Model The software is developed without first addressing the specification or design. Instead the developers simply build a product that is reworked as many times as necessary until it satisfies its clients • This approach may work well on problems having about 100 or 200 lines of code but inadequate for complex problems. • Cost of this model is unacceptably high • Maintenance is extremely difficult. • Chances of fault occurring are considerable high. | | <document classification>

14. Requirements analysis and specification Design and Specification Coding and module Testing Integration and System testing Delivery and Maintenance Waterfall Model | | <document classification>

15. Waterfall Model | | <document classification>

16. Waterfall Model • This model is also called as the classic life cycle or the Waterfall model. • This model suggests a systematic sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and support. • This model has the following activities: • System / Information Engineering (Analysis and Design) • Coding • Testing | | <document classification>

17. Iterative Enhancement Model • The iterative development model ties to combine the benefits of both prototyping and the waterfall model. • The basic idea is that the software should be developed in increments, each increment adding some functional capability to the system until the full system is implemented. • At each step, extensions and design modifications can be made. • An advantage of this approach is that it can result in better testing because testing each increment is likely to be easier than testing the entire system as in the waterfall model. • The increment models provide feedback to the client i.e. useful for determining the final requirements of the system. | | <document classification>

18. The Prototype Model | | <document classification>

19. The Prototype Model Build Prototype Requirements gathering Customer evaluation Customer satisfied Quick Design Review & updation Development test Maintain | | <document classification>

20. The Spiral Model | | <document classification>

21. The Spiral Model | | <document classification>

22. Business Modeling Business Modeling Data Modeling Data Modeling Process Modeling Process Modeling Application Generation Application Generation Testing & Turnover Testing & Turnover Team-1 Team-2 The RAD Model | | <document classification>

23. Software Requirement Specification • The requirement analysis involves obtaining a clear and thorough understanding of the product to be developed. • SRS should be consistent, correct, unambiguous & complete document. • An SRS defines • External interfaces of the system • Function and non-functional requirements of the system • Design Constraints | | <document classification>

24. SRS Document Structure Introduction Purpose Document Conventions Intended Audience Additional Information Contact Information/SRS Team Members References Overall Description Product perspective Product Functions User Classes and characteristics Operating environment User Environment Design/Implementation Constraints Assumptions and dependencies. 24 | | <document classification>

25. 3. External Interface Requirements User Interfaces Hardware Interfaces. Software Interfaces. Communication Protocols and dependencies. 4. System Features 1. System Feature Description and priority, 2. Action/Result, 3. Functional Requirement. 25 | | <document classification>

26. 5. Other Non Functional Requirements. Performance Requirements Safety Requirements Software quality attributes Project Documentation User Documentation 6. Other Requirements. 1. Terminology/Glossary/Definition List 2. Appendix Simpler, Faster, Better 26 | | <document classification>

27. UNIT 2. Software Process Management | | <document classification>

28. Human Resource Management Effective software project management encompassesthree main areas: • People • Problem • Process | | <document classification>

29. The People • People management capability maturity model(PM-CMM) is developed to enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability . • Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective software engineering practices. | | <document classification>

30. The Problem • Before a project can be planned, product objectives and scope should be established, alternative solutions should considered, and technical and management constraints should b defined. | | <document classification>

31. The Process • A software process provides the framework from which a comprehensive plan for software development can be established. • A number of different task sets-tasks, milestones, work products, and quality assurance points –enable the framework activities to be adapted. • Finally Umbrella activities- such as software quality assurance, software configuration management and measurement-overlay the process model. | | <document classification>

32. The Players The Players -- It is important to recognize the different categories of people involved in a large software project. • Senior Managers - who define business issues. • Project Managers- who plan, motivate, organize and control the practitioners • Practitioners- who deliver the technical skill that are necessary to engineer the project • Customers- who specify the requirements • End users - who interact with the software once it is released. | | <document classification>

33. Team Leadership --A Critical Item • The Problem:The best programmers often make poor team leaders. • Different skills are required. • Technical leadership model • Motivation - the ability to encourage technical people to produce to their best ability. • Organization - the ability to mold existing processes that will enable the initial concept to be translated into reality. • Ideas and Innovation - the ability to invite creativeness even within a set of restrictions. | | <document classification>

34. The Characteristics that define an effective project manager emphasizes four key traits: • Problem Solving: An effective software project manager can diagnose the technical and organizational issues that are most relevant, systematically structure a solution or properly motivate other practitioners to develop the solution, apply lessons learned from past projects to new situations and remain flexible. | | <document classification>

35. Management Identity:A good project manager must take charge of project. She/he must have confidence to assume the control when necessary and the assurance to allow good technical people to follow their instincts. • Achievement:To optimize the productivity of a project team, a manager must reward initiative and accomplishment and demonstrate through his own action that controlled risk taking will not be punished. | | <document classification>

36. Influence and team building:An effective project manager must be able to “read” people;she/he must be able to understand verbal and nonverbal signals and react to the needs of the people sending these signals. The manager must remain in control in high-stress situations. | | <document classification>

37. The Software Team • The best team structure depends on the management style of an organization, the number of people who will populate the team and their skill levels and the overall problem difficulty.the following are the three generic teams: • Democratic decentralized (DD) • Controlled decentralized (CD) • Controlled Centralized (CC) | | <document classification>

38. Democratic Decentralized (DD) • This software team has no permanent leader. Rather ““Task Coordinators” are appointed for short durations and then replaced by other who may coordinate different tasks. • Decisions on problems and approach are made by groups consensus. • Communication among team members is horizontal. | | <document classification>

39. Controlled Decentralized (CD) • It has a defined leader who coordinates tasks, and secondary leaders who coordinates specific tasks and secondary leaders that have responsibility for subtasks. • Problem solving is group activity, but implementation of solution is partitioned among subgroups by team leader. • Communication among subgroups and individual is horizontal. • Vertical communication along the control hierarchy also occurs. | | <document classification>

40. Controlled Centralized (CC) • Top--level problem solving and internal team coordination managed by the team leader. • The communication between the leader and members is vertical. | | <document classification>

41. The Software Team Seven project factors considered when planning the structure of software engineering teams: • The difficulty of the problem to be solved. • The size of the resultant program(s) in lines of code or function points. • The time the team will stay together (team lifetime). • The degree to which the problem can be modularized. • The required quality and reliability of the system to be built. • The rigidity of the delivery date. • The degree of sociability required for the project. | | <document classification>

42. CC and CD teams produces fewer defects than DD teams Decentralized teams normally require more time to complete a project than a centralized structure | | <document classification>

43. Impact of Project Characteristics | | <document classification>

44. Organizational Paradigms • A closed paradigm structures team along a traditional hierarchy of authority. Such teams can work well when producing software that is quite similar to past efforts. • The random paradigm structures a team loosely and depends on individual initiative of the team members. These teams are used when innovation or technological breakthrough is required. But such teams struggle when “orderly performance” is required. | | <document classification>

45. The open paradigm attempts to structure a team in a manner that achieves some of the controls associated with closed paradigm but also much of the innovation that occurs when using the random paradigm. Well suited for solving complex problems. • The synchronous paradigmrelies on the natural compartmentalization of a problem and organizes team to work on pieces of problem with little active communication | | <document classification>

46. Organization, Information and Decision Tactical decisions Tactical Data Top Strategic decisions Strategic Data Middle Operational decisions Operational Operational Data | | <document classification>

47. Some Important Terms • Coupling: The manner and degree of interdependence between software modules. • In software engineering, the relation between various parts of a module to a central theme is called Cohesion • Third principle related to module decomposition involves the concept of abstraction, where the details of a step is separated from the way that step fits in to the solution as a whole. • Other related is the concept of information hiding where the details of a task at one level are hidden from the use of task at a higher level. This information hiding can be applied to both the structure of problems and the organization and manipulation of data. | | <document classification>

48. Software Crisis Software Crisis can be broadly classified into following categories: • From Programmer’s Point of View. • From User’s point of View. | | <document classification>

49. System Analyst • A system analyst is a person who conducts a study, identifies activities and objectives and determines a procedure to achieve the objectives. • Designing and implementing systems to suit organizational needs are the functions of the system analyst. • The analyst is the person who coordinates the efforts of different types of persons in an organization to achieve business goals. | | <document classification>

50. Role of a System Analyst • Problem Definition:-It is the job of system analyst to define the problem clearly and precisely. • He must consult with different people such as managers, users and other data processing professionals, to define problems and develop solutions. • Having gathered the data pertaining to a problem, the system analyst analyses them and thinks a plan to solve it by pulling together other people’s ideas and refining them until a workable solution is achieved. | | <document classification>