Unit I Introduction to Software Engineering Software Process

Unit I Introduction to Software Engineering, Software Process Models (07 Hours )

1. Software Engineering Fundamentals: Nature of Software, Software Engineering Principles, The Software Process, Software Myths. 2. Process Models : 2. 1. A Generic Process Model 2. 2. Prescriptive Process Models: • The Waterfall, Incremental Process(RAD), Evolutionary Process, Unified Process, Concurrent. 3. Advanced Process Models & Tools: 3. 1. Agile software development: • Agile methods, Plan-driven and agile development, Extreme programming Practices, Testing in XP, Pair programming. 3. 2. Introduction to agile tools: JIRA, Kanban, 3. 3. Case Studies: An information system (mental health-care system), wilderness weather system

1. Software Engineering Fundamentals: 1. 1. Nature of Software, 1. 2. Software Engineering Principles, 1. 3. The Software Process, 1. 4. Software Myths.

2. Process Models : 2. 1. A Generic Process Model 2. 2. Prescriptive Process Models: 2. 2. 1. The Waterfall Model, 2. 2. 2. Incremental Process(RAD) Model, 2. 2. 3. Evolutionary Process Model, 2. 2. 4. Unified Process Model, 2. 2. 5. Concurrent Model.

3. Advanced Process Models & Tools: 3. 1. Agile software development: 3. 1. 1. Agile methods, 3. 1. 2. Plan-driven and agile development, 3. 1. 3. Extreme programming Practices, 3. 1. 4. Testing in XP, 3. 1. 5. Pair programming. 3. 2. Introduction to agile tools: JIRA, Kanban, 3. 3. Case Studies: An information system (mental health-care system), wilderness weather system

1. Software Engineering Fundamentals: 1. 1. Nature of Software, 1. 2. Software Engineering Principles, 1. 3. The Software Process, 1. 4. Software Myths.

1. 1. Nature of Software • Software plays on a dual role - • It is a product & • At the same time, the vehicle for delivering the product.

• Software is an information transformer - Producing, managing, acquiring, modifying, displaying or transmitting information. - ex. - Microsoft Office, Paint, PDF Creator, Media Players etc. • As a vehicle to used to deliver the product - Operating system - (windows XP, Linux etc. ) - software tools and environments (ex. Visual Studio 2008, Net Beans, Eclipse)

Defining - software • Software is – • Instructions (computer programs) - That when executed, provide desired features, function and performance. • Data structures – - that enable, programs to adequately manipulate information & • Descriptive information – - in hard copy & virtual forms that describes the operation & use of the programs.

Nature of software 1. System Software • collection of programs, written - to service other programs. • Ex – Compilers, Editors, Assemblers, Operating System. • They establishes – communication with the hardware. 2. Application Software – • Standalone programs, developed for - specific business needs. • This software may be supported by database systems. • Ex. Microsoft office, Media Player 3. Engineering/Scientific Software • These software - based on - complex numeric applications. • Used as – tools for special purpose. • Ex – MATLAB, WEKA, SCILAB.

4. Embedded Software – • This Software – can reside - within a product or system. • Controls – features and functions, for the end user and for the system itself. • Ex – robots, drones. 5. Web Applications – • Contains – web pages, that can be retrieved by a browser • The web pages - can be developed - using programming languages like – JAVA, PERL, CGI, HTML, DHTML. 6. Artificial Intelligence Software – • Based on - knowledge based expert systems. • Used in – Robotics, Expert Systems, Image And Voice Recognition, Artificial Neural Networks, Theorem Proving And Game Playing.

Software Myths Dec 12, 13, May 14 – 8 marks

Software Myths • Management Myths • Customer Myths • Practitioner’s Myths

Management Myths 1. We already have a book, that’s full of standards & procedures - for building software. • Won’t that provide my people with everything they need to know? OR The members of an organization can acquire allthe information, they require from a manual, which contains standards, procedures, and principles;

• Reality – • Standards are often incomplete, inadaptable, and outdated. • Developers are often unaware of all the established standards. • Developers rarely follow all the known standards

2. If we get behind schedule, we can add more programmers & reduce the time gap Reality – • Adding more manpower to the project, which is already behind schedule, further delays the project. • New workers take longer to learn about the project • as compared to those already working on the project.

3. If I decide to outsource the software project to a third party, I can just relax & let that firm build it. • Reality – • Outsourcing software to a third party does not help the organization, • which is incompetent in managing, controlling and maintaining the software project internally.

Customer Myths 1. Brief requirement stated in the initial process is enough to start development; • detailed requirements can be added at the later stages. Reality - • Starting development with incomplete and ambiguous requirements • often lead to software failure. • Instead, a complete and formal description of requirements • is essential before starting development. • Adding requirements at a later stage • often requires repeating the entire development process.

2. Software is flexible; • hence software requirement changes • can be added during any phase of the development process. • Reality - • Incorporating change requests - earlier in the development process - costs lesser than those that occurs at later stages. • This is because incorporating changes later - may require redesigning and extra resources.

Practitioners Myths 1. Once we write the program & get it to work, our job is done Reality – • 50% to 70% of all the efforts are expanded • after the software is delivered to the user. 2. The only deliverable work product - for a successive project is the working program • To make the project successful • the documentation and software configuration also plays crucial role.

3. Software engineering requires unnecessary documentation, which slows down the project. • Reality - • Proper documentation enhances quality • which results in reducing the amount of rework.

4. Software quality can be assessed only after the program is executed. Reality - • The quality of software can be measured during any phase of development process • by applying some quality assurance mechanism. • One such mechanism is formal technical review • that can be effectively used during each phase of development • to uncover certain errors.