CS223: Software Engineering Lecture 3: Software Develoment Processes

Recap Software engineering as a bridge between customer and developer Different misconceptions about software developments Legacy software Software developments phases

Objective After the end of the class students should be able to o State professional responsibilities of a software engineer o Explain the need of software processes o Describe ETVX model o Differentiate between different properties of software processes

How a Project Starts? Every software project is precipitated by some business need to o Correct a defect in an existing application o Adapt a legacy system to a changing business environment o Extend the functions and features of an existing application o Create a new product or system

Professional responsibility Confidentiality o Engineers should normally respect the confidentiality of their employers o Clients irrespective of whether or not a formal confidentiality agreement has been signed. Competence o Engineers should not misrepresent their level of competence. o They should not knowingly accept work which is outwit their competence.

Professional responsibility Intellectual property rights o Engineers should be aware of local laws governing the use of intellectual property such as patents, copyright, etc. o They should be careful to ensure that the intellectual property of employers and clients is protected. Computer misuse o Software engineers should not use their technical skills to misuse other people’s computers. o Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses).

Software engineering methods Structured approaches to software development Model descriptions o Descriptions of graphical models which should be produced Rules o Constraints applied to system models Recommendations o Advice on good design practice Process guidance o What activities to follow

CASE (Computer-Aided Software Engineering) Software systems which are intended to provide automated support for software process activities. CASE systems are often used for method support Upper-CASE o Tools to support the early process activities of requirements and design Lower-CASE o Tools to support later activities such as programming, debugging and testing

Software Process Process is distinct from product o products are outcomes of executing a process on a project Software Engineering. focuses on process Premise o Proper processes will help achieve project objectives of high QP

Why we need a process? Common understanding of different factors o Activities, o Resources and o Constraints involved in software development. Creating processes helps o Find inconsistencies, o Redundancies; and o Omissions

What is a software process? A set of ordered tasks to produce indented output of some kind o Involving activates, o Constraints; and o Resources The process of building a software product o Life cycle  Describes the life of the software from conception through  implementation,  delivery,  use and  maintenance.

Component Software Processes Two major processes o Development  focuses on development and quality steps needed to engineer the software o Project management  focuses on planning and controlling the development process Development process is the heart of software process; other processes revolve around it These are executed by different people o Developers execute engineering process o Project manager executes the management processes

Component Processes… Other processes o Configuration management process  manages the evolution of artifacts o Change management process  how changes are incorporated o Process management process  management of processes themselves o Inspection process  How inspections are conducted on artifacts

Process Specification Process is generally a set of phases Each phase performs a well defined task and produces an output Intermediate outputs – work products At top level, typically few phases in a process How to perform a particular phase o Methodologies have been proposed

ETVX Specification ETVX approach to specify a step o Entry criteria: conditions to be satisfied for initiating this phase o Task: what is to be done in this phase o Verification: the checks done on the outputs of this phase o eXit criteria: when can this phase be considered done successfully A phase also produces info for management

ETVX approach

Thank you Next Lecture: Process Models