ADVANCE SOFTWARE ENGINEERING: RECOMMENDED BOOKS

SOFTWARE ENGINEERINGLECTURE 1: INTRODUCTION

Syed Saqib Raza Rizvi

PREFACEWhat is Engineering?What is Software?What is software engineering?What is a software process?Different types of process models?Different Models with Strengths and WeaknessesAgile Software Development

WHAT IS ENGINEERING?Engineering is the application of scientific and practical knowledge in order to invent, design, build, maintain, and improve systems, processes, etc.

WHAT IS SOFTWARE?The software is collection of Integrated programs

Software consists of carefully-organized instructions and code written by programmers in any of various special computer languages.

Computer programs and associated documentation such as requirements, design models and user manuals.

WHAT IS SOFTWARE ENGINEERING?

Software engineering is an engineering discipline that is concerned with all aspects of software production.

According to IEEE's definition software engineering can be defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.

WHAT IS A SOFTWARE PROCESS? A framework that describes the activities performed at each stage of a software development project.

A set of activities whose goal is the development or evolution of software.

Generic activities in all software processes are: Specification - what the system should do and its development constraints

Development - production of the software system Validation - checking that the software is what the customer wants

Evolution - changing the software in response to changing demands.

TYPES OF SDLC MODELS:Waterfall Model Incremental ModelRAD ModelSpiral ModelScrum ModelLean Development MethodologyExtreme ProgrammingEtc

.

WATERFALL MODEL

WATERFALL MODEL: STRENGTHSEasy to understand, easy to useProvides structure to inexperienced staffMilestones are well understoodGood for management control (plan, staff, track)Works well when quality is more important than cost or schedule

WATERFALL MODEL: DEFICIENCIESAll requirements must be known upfrontDeliverables created for each phase are considered frozen inhibits flexibility

Can give a false impression of progressDoes not reflect problem-solving nature of software development – iterations of phases

Integration is one big bang at the endLittle opportunity for customer to preview the system (until it may be too late)

WATERFALL MODEL: WHEN TO USERequirements are very well knownProduct definition is stableTechnology is understoodNew version of an existing productPorting an existing product to a new platform.High risk for new systems because of specification and design problems

INCREMENTAL MODELWhole requirement is divided into various buildsMultiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. 

Cycles are divided up into smaller, more easily managed modules. 

Each module passes through the requirements, design, implementation and testing phases.

A working version of software is produced during the first module, so you have working software early on during the software life cycle.

INCREMENTAL MODEL

INCREMENTAL MODEL: ADVANTAGES Generates working software quickly and early during the software life cycle.

More flexible – less costly to change scope and requirements.

Easier to test and debug during a smaller iteration.Customer can respond to each built.Lowers initial delivery cost.

INCREMENTAL MODEL: DISADVANTAGES Needs good planning and design.Needs a clear and complete definition of the whole system before it can be broken down and built incrementally.

Total cost is higher than waterfall.

INCREMENTAL MODEL: WHEN TO USERequirements of the complete system are clearly defined and understood.

Major requirements must be defined; however, some details can evolve with time.

There is a need to get a product to the market early.A new technology is being usedResources with needed skill set are not available

RAD MODELRapid Application Development model type of incremental model In RAD model the components or functions are developed in parallel as if they were mini projects.

The developments are time boxed, delivered and then assembled into a working prototype. 

This can quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements.

RAD MODEL

RAD MODEL: ADVANTAGESReduced development time. Increases reusability of componentsQuick initial reviews occurEncourages customer feedback

RAD MODEL: DISADVANTAGESDepends on strong team and individual performances for identifying business requirements.

Only system that can be modularized can be built using RAD

Requires highly skilled developers/designers.High dependency on modeling skills Inapplicable to cheaper projects as cost of modeling and automated code generation is very high.

RAD MODEL: WHEN TO USE RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time.

It should be used if there’s high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.

RAD SDLC model should be chosen only if resources with high business knowledge are available and there is a need to produce the system in a short span of time (2-3 months).

SPIRAL MODELThe spiral model is similar to the incremental model, with more emphasis placed on risk analysis.

The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation.

A software project repeatedly passes through these phases in iterations (called Spirals in this model).

The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed.

SPIRAL MODEL

SPIRAL MODEL: ADVANTAGESHigh amount of risk analysis hence, avoidance of Risk is enhanced.

Good for large and mission-critical projects.Strong approval and documentation control.Additional Functionality can be added at a later date.

SPIRAL MODEL: DISADVANTAGESCan be a costly model to use.Risk analysis requires highly specific expertise.Project’s success is highly dependent on the risk analysis phase.

Doesn’t work well for smaller projects.

SPIRAL MODEL: WHEN TO USEWhen costs and risk evaluation is importantFor medium to high-risk projectsUsers are unsure of their needsRequirements are complexNew product lineSignificant changes are expected (research and exploration)

WHAT IS AGILE?Traditional approach to managing software development projects was failing far too often, and there had to be a better way

Agile development is a different way of managing IT development teams and projects

Came up with the agile manifesto, which describes 4 important values that are as relevant today

AGILE MANIFESTO: Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

10 KEY PRINCIPLES OF AGILE:

1. Active user involvement is imperative

2. The team must be empowered to make decisions 3. Requirements evolve but the timescale is fixed 4. Capture requirements at a high level

5. Develop small, incremental releases and iterate

10 KEY PRINCIPLES OF AGILE: 6. Focus on frequent delivery of products

7. Complete each feature before moving on to the next

8. Apply the 80/20 rule

9. Testing is integrated throughout the project lifecycle – test early and often 10. A collaborative & cooperative approach between all stakeholders is essential

SCRUM METHODOLOGY:  Is also an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.

Scrum is the most popular and widely adopted agile method

Relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades

SCRUM METHODOLOGY•A product owner creates a prioritized wish list called a product backlog.•During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.•The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).•Along the way, the Scrum Master keeps the team focused on its goal.•At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.•The sprint ends with a sprint review.•As the next sprint begins, the team chooses another chunk of the product backlog and begins working again-

XP (EXTREME PROGRAMMING)XP (Extreme Programming) is a more radical agile methodology,

Focusing more on the software engineering process Addressing the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product.

XP (BASIC ACTIVITIES)1.      You need to improve communication.2.      You need to seek simplicity.3.      You need to get feedback on how well you are doing.

4.      You need to always proceed with courage.

XP (RULES) In XP these four basic activities are implemented by using practices which are traditional software engineering practices but elevated to embody and encourage XP values.

Although practices of Extreme Programing they can be compacted into twelve simple rules

XP (RULES)1. User stories (planning): User stories can be viewed as a smaller version of use case. In this

way, the customer define as briefly as possible the specification of the new application (features, value, priority). These stories will be the base for the project team to do cost estimation and management of the project.

2.      Small releases (building blocks): XP emphasizes on small, simple but frequent versions updates of the application. Each newly added requirement will instantly incorporated and the system is re-released.

3.      Metaphor (standardized naming schemes): Developers and programmers must adhere to standards on names, class names and methods.

4.      Collective ownership: In XP methodology, all code is considered to be owned by the whole team and not an individual property. Hence, all code is reviewed and updated by everyone.

5.      Coding standard: Styles and formats of coding must be the same in order to enable compatibility between team members. This approach results in more rapid collaboration.

6.      Simple design: Always look for system implementation that is as easy as possible implementation of the system yet meets all required functionality.

XP (RULES)7.      Refactoring: The application should be continually adjusted and improved by all team members. This requires extremely good communication between members to avoid work duplication.8.      Testing: Every small release (called building block) must pass tests before being released. XP’s uniqueness in this aspect is that tests are created first and then application code is developed to meet and pass the challenges of those pre-written tests.9.      Pair programming: XP programmers work in pairs. All code is developed by two programmers who work together at a single machine. The expectation is that pair programming produces higher quality code at the same or less cost.10.  Continuous integration: Software builds are completed several times a day. In this way all developers can avoid work fragmentations because they continuously releasing and integrating code together.11.  40-hour workweek: Keep mental and physical conditions to be up and running by not working more than what the bodies can handle.12.  On-site customer: The customer must be viewed as an integral part of the project. The customer must be arranged to be available at all times in order to ensure that the project is in the right track.