The document describes the key activities and concepts in software development processes including requirements analysis, specification, architecture, design, implementation, testing, deployment, and maintenance. It discusses various process models like waterfall, agile, iterative, RAD, and XP. It also covers supporting disciplines such as configuration management, documentation, quality assurance, and project management as well as development tools.

1. Presented by Goutama Bachtiar
E: goutama@gmail.com | T: @goudotmobi 2008

2. Software Development Process
• Activities and steps
• Models
• Supporting disciplines
• Tools

3. Activities & Steps
• Requirements
• Specification
• Architecture
• Design
• Implementation
• Testing
• Deployment
• Maintenance

4. Models
• Agile
• Cleanroom
• DSDM
• Iterative
• RAD
• RUP
• Spiral
• Waterfall
• XP
• Scrum
• V-Model

5. Supporting Disciplines
• Configuration management
• Documentation
• Quality assurance (SQA)
• Project management
• User experience design

6. Tools
• Compiler
• Debugger
• Profiler
• GUI designer
• Integrated development environment

7. Definition
• A structure imposed on the development of a
software product
• A.k.a software life cycle & software process
• International standard for describing the
method of selecting, implementing and
monitoring the life cycle for software is ISO
12207 (23 Processes, 95 Activities, 325 Tasks
and 224 Outcomes)

8. Requirement Analysis
• Domain Analysis is often the first step in
attempting to design a new piece of software,
whether it be an addition to an existing software,
a new application, a new subsystem or a whole
new system
• Software Elements Analysis: extracting the
requirements.
• Incomplete, ambiguous or contradictory
requirements are recognized by skilled and
experienced software engineers . This is in
concern with the Software Process Activity/Steps

9. Requirement Analysis (cont’d)
• The process where clients requested to give details
as to what exactly the software should do for them;
what exactly do they want the software to achieve;
what expected output/results are expected
• The process tries to gather and understand various
elements of software that needs to be engineered
• This process can be achieved through question and
answer sessions. Demonstration of similar products
can also help the clients to give unambiguous
answers to the questions asked

10. Requirement Activities
• Eliciting requirements
Communicating with customers and users to determine
what their requirements are. Also called requirements
gathering
• Analyzing requirements
Determining whether the stated requirements are
unclear, incomplete, ambiguous, or contradictory, and
then resolving these issues
• Recording requirements
Documenting requirements in various forms, such as
natural-language documents, use cases, user stories, or
process specifications

11. Types of Requirements
• Customer Requirements
Statements of fact and assumptions that define the expectations of the
system in terms of mission objectives, environment, constraints, and
measures of effectiveness and suitability (MOE/MOS).
• Functional Requirements
Explanation what has to be done, and identified The necessary task, action
or activity that must be accomplished
• Performance Requirements
The extent to which a mission or function must be executed;
Generally measured in terms of quantity, quality, coverage, timeliness or
readiness
During requirements analysis, performance requirements will be
interactively developed across all identified functions based on system life
cycle factors;
Characterized in terms of the degree of certainty in their estimate, degree
of criticality to system success, and their relationship to other
requirements

12. Types of Requirements (cont’d)
• Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and
“how to execute” requirements for processes expressed in technical data
packages and technical manuals
• Derived Requirements
Implied or transformed from higher-level requirement
Example: a requirement for long range/high speed may result in a design
requirement for low weight
• Allocated Requirements
Established by dividing or otherwise allocating a high-level requirement
into multiple lower-level requirements
Example: A 100-pound item that consists of two subsystems might result
in weight requirements of 70 pounds and 30 pounds for the two lower-
level items

13. Specifications
• The task of precisely describing the software to be written,
possibly in a rigorous way
• In practice, most successful specifications are written to
understand and fine-tune applications that were already
well-developed, although safety-critical software systems
are often carefully specified prior to application
development
• Most important for external interfaces that must remain
stable
• A good way to determine are sufficiently precise is to have
a third party review the documents making sure that the
requirements and Use Cases are logically sound

14. Architecture
• An abstract representation of that system
• Concerned with making sure the software
system will meet the requirements of the
product, as well as ensuring that future
requirements can be addressed
• Addresses interfaces between the software
system and other software products, as well
as the underlying hardware or the host
operating system

15. Design, Implementation & Testing
• Implementation is part of process where software
engineers actually program the code for the project
• Software testing is an integral and important part of
the software development process. This part of the
process ensures that bugs are recognized as early as
possible
• Documenting the internal design of software for the
purpose of future maintenance and enhancement is
done throughout development. This may also include
the authoring of an API, be it external or internal

16. Deployment & Maintenance
• Deployment starts after the code is appropriately
tested, is approved for release and sold or
otherwise distributed into a production
environment
• Software Training and Support is important
because a large percentage of software projects
fail because the developers fail to realize that it
doesn't matter how much time and planning a
development team puts into creating software if
nobody in an organization ends up using it

17. Deployment & Maintenance
• People are often resistant to change and avoid venturing into an
unfamiliar area, so as a part of the deployment phase, it is very
important to have training classes for new clients of your software
• Maintenance and enhancing software to cope with newly
discovered problems or new requirements can take far more time
than the initial development of the software
• It may be necessary to add code that does not fit the original design
to correct an unforeseen problem or it may be that a customer is
requesting more functionality and code can be added to
accommodate their requests. It is during this phase that customer
calls come in and you see whether your testing was extensive
enough to uncover the problems before customers do

18. Agile Software Development
• Agile software development processes are built on the
foundation of iterative development. To that
foundation they add a lighter, more people-centric
viewpoint than traditional approaches. Agile processes
use feedback, rather than planning, as their primary
control mechanism. The feedback is driven by regular
tests and releases of the evolving software
• Interestingly, surveys have shown the potential for
significant efficiency gains over the waterfall method.
For example, a survey, published in August 2006 by
VersionOne and Agile Alliance and based on polling
more than 700 companies claims the following benefits
for an Agile approach

19. Rapid Application Development
• A software development methodology, which
involves iterative development and the construction
of prototypes
• It is a merger of various structured techniques,
especially the data driven Information Engineering
with prototyping techniques to accelerate software
systems development
• RAD calls for the interactive use of structured
techniques and prototyping to define user's
requirements and design the final system

20. Rapid Application Development (cont’d)
• Pros
– Promotes strong collaborative atmosphere and dynamic
gathering of requirements
– Business owner actively participates in prototyping, writing test
cases and performing unit testing
• Cons
– Dependency on strong cohesive teams and individual
commitment to the project. Success depends on disciplined
developers and their exceptional technical skills and ability to
“turn on a dime”. Decision making relies on the feature
functionality team and a communedecision making process with
lesser degree of centralized PM and engineering authority.

21. Iterative Process
• Iterative development prescribes the
construction of initially small but even larger
portions of a software project to help all those
involved to uncover important issues early
before problems or faulty assumptions can
lead to disaster. Iterative processes are
preferred by commercial developers because
it allows a potential of reaching the design
goals of a customer who does not know how
to define what they want

22. Extreme Programming
• The best-known iterative process
• In XP, the phases are carried out in extremely
small (or "continuous") steps compared to the
older, "batch" processes. The (intentionally
incomplete) first pass through the steps might
take a day or a week, rather than the months or
years of each complete step in the Waterfall
model.
• First, one writes automated tests, to provide
concrete goals for development

23. Extreme Programming (cont’d)
• Next is coding (by a pair of programmers), which is complete
when all the tests pass, and the programmers can't think of
any more tests that are needed
• Design and architecture emerge out of refactoring, and come
after coding. Design is done by the same people who do the
coding
• The incomplete but functional system is deployed or
demonstrated for (some subset of) the users (at least one of
which is on the development team). At this point, the
practitioners start again on writing tests for the next most
important part of the system.

24. Chaos Model
• A structure of software development that extends the spiral
model and waterfall model
• The phases of the life cycle apply to all levels of projects, from
the whole project to individual lines of code
• The whole project must be defined, implemented, and
integrated
• Systems must be defined, implemented, and integrated
• Modules must be defined, implemented, and integrated
• Functions must be defined, implemented, and integrated
• Lines of code are defined, implemented and integrated

25. User Experience Design
• Often abbreviated UX or UE, is a term to describe the
overarching experience a person has as a result of their
interactions with a particular product or service, it's delivery,
and related artifacts, according to their design
• Typical outputs include:
– Flows and Navigation Maps
– User stories or Scenarios
– Persona (Fictitious users to act out the scenarios)
– Wireframes (screen blueprints or storyboards)
– Prototypes (For interactive or in-the-mind simulation)
– Written specifications (describing the behavior or design)
– Graphic mockups (Precise visual of the expected end result)

26. User Experience Design (cont’d)
• Reducing excessive features which miss the
needs of the user
• Improving the overall usability of the system
• Expediting design and development through
detailed and properly conceived guidelines
• Incorporating business and marketing goals
while catering to the user

27. Waterfall Processes
• Requirements specification (AKA Verification)
• Design
• Construction (AKA implementation or coding)
• Integration
• Testing and debugging (AKA validation)
• Installation (AKA deployment)
• Maintenance

28. Waterfall Processes (cont’d)
• After each step is finished, the process proceeds to the next step,
just as builders don't revise the foundation of a house after the
framing has been erected.
• This approach is used in high risk projects, particularly large defense
contracts. The problems in waterfall do not arise from "immature
engineering practices, particularly in requirements analysis and
requirements management."
• Often the supposed stages are part of review between customer
and supplier, the supplier can, in fact, develop at risk and evolve the
design but must sell off the design at a key milestone called Critical
Design Review (CDR). This shifts engineering burdens from
engineers to customers who may have other skills

29. Other Models
• Capability Maturity Model (CMM) is one of
the leading models. Independent assessments
grade organizations on how well they follow
their defined processes, not on the quality of
those processes or the software produced
• ISO 9000 describes standards for formally
organizing processes with documentation

30. Other Models (cont’d)
• ISO 15504 (Software Process Improvement Capability
Determination)is a "framework for the assessment of
software processes". This standard is aimed at setting out a
clear model for process comparison. SPICE is used much like
CMMI. It models processes to manage, control, guide and
monitor software development. This model is then used to
measure what a development organization or project team
actually does during software development. This information
is analyzed to identify weaknesses and drive improvement. It
also identifies strengths that can be continued or integrated
into common practice for that organization or team

31. Other Models (cont’d)
• Six Sigma is a methodology to manage process
variations that uses data and statistical analysis to
measure and improve a company's operational
performance. It works by identifying and
eliminating defects in manufacturing and service-
related processes. The maximum permissible
defects is 3.4 per one million opportunities.
However, Six Sigma is manufacturing-oriented
and needs further research on its relevance to
software development

32. Other Models (cont’d)
• Test Driven Development (TDD) is a useful output of the Agile camp
but some suggest that it raises a conundrum.
• TDD requires that a unit test be written for a class before the class
is written. The class firstly has to be "discovered" and secondly
defined in sufficient detail to allow the write-test-once-and-code-
until-class-passes model that TDD actually uses
• This counter to Agile approaches, where developers are still
encouraged to code early, with light design
• To get the claimed benefits of TDD a full design down to class and
responsibilities is not necessary. This would count towards iterative
development, with a design locked down, but not iterative design -
as heavy refactoring and re-engineering might negate the
usefulness of TDD

33. Software Project Management
• Project planning, monitoring and control
The purpose of project planning is to identify
the scope of the project, estimate the work
involved, and create a project schedule.
Project planning begins with requirements
that define the software to be developed.
The project plan is then developed to describe
the tasks that will lead to completion.

34. Software Project Management (cont’d)
• Project monitoring and control
To keep the team and management up to date on the
project's progress
If the project deviates from the plan, then the PM
can take action to correct the problem. Involves
status meetings to gather status from the team
When changes need to be made, change control is
used to keep the products up to date

35. Software Configuration Management
• Task of tracking and controlling changes in the software
• Include revision control and the establishment of baselines
• Goals
– Configuration identification (What code are we working
with?)
– Configuration control (Controlling the release of a product
and its changes)
– Status accounting (Recording and reporting the status of
components)
– Review (Ensuring completeness and consistency among
components)

36. Software Configuration Management (cont’d)
– Build management - Managing the process and tools used
for builds
– Process management - Ensuring adherence to the
organization's development process
– Environment management - Managing the software and
hardware that host our system
– Teamwork - Facilitate team interactions related to the
process
– Defect tracking - Making sure every defect has traceability
back to the source

37. Software Documentation
• Requirements: Identify attributes, capabilities, characteristics,
or qualities of a system
• Architecture/Design: Overview of software. Includes relations
to an environment and construction principles in design of
software components
• Technical: Documentation of code, algorithms, interfaces, and
APIs
• End User: Manuals for the end-user, system administrators
and support staff
• Marketing: How to market the product and analysis of the
market demand

38. Software Quality Assurance
• Software quality control is a control of products, software
quality assurance is a control of processes
• Through PPQA audits: Process and Product Quality Assurance
is the activity of ensuring that the process and work product
conform to the agreed upon process
• Advantages
– Improved customer satisfaction
– Reduced costs of development
– Reduced costs of maintenance

39. Software Development Rythms
• The approach of software development rhythms seeks to answer the key
question of whether programmer productivity is impacted by the various
agile practices, rather than by any single software development method.
• Example:
– plan ~ do ~ check ~ act ~ plan ~ do ~ check ~ act ...
– pair programming ~ solo programming ~ pair programming ~ solo
programming ...
– testing ~ coding ~ refactoring ~ testing ~ coding ~ refactoring ...
– test first programming ~ test last programming ~ test first
programming ~ test last programming ...
– standardizing ~ tailoring ~ measuring ~ improving ~ tailoring ~
measuring ~ improving ...

40. Problem in Software Projects
• Come from 3 different viewpoints: PM, developers and
customers
• The problems of PM: poor roles definition, lack of estimating
& planning skills, lack of decision making skills
Do need to face schedule, budget & quality constraints
• The problems of developers: lack of knowledge in the
application area, lack of knowledge about developing
standards, lack of up to date documentations, deadline
pressure, changes of application requirements
• The problems customers face include: monetary constraints,
receiving products past the due date

41. GUI Builder
• A graphical user interface builder, or GUI designer is a
software development tool that simplifies the creation of
GUIs by allowing the designer to arrange widgets using a drag-
and-drop WYSIWYG editor
• A GUI must be built by manually specifying each widget's
parameters in code, with no visual feedback until the program
is run.
• User interfaces are commonly programmed using an event-
driven architecture, so GUI builders also simplify creating
event-driven code. This supporting code connects widgets
with the outgoing and incoming events that trigger the
functions providing the application logic.

42. Compiler
• A computer program that translates text written in a
computer language into another computer language
• The original sequence is usually called the source
code and the output called object code
• A program that translates from a low level language
to a higher level one is a decompiler
• To perform many or all of the following operations:
lexical analysis, preprocessing, parsing, semantic
analysis, code generation, and code optimization

43. Debugger
• A technique that allows great power in its ability to halt when
specific conditions are encountered but which will typically be
much slower than executing the code directly on the
appropriate processor.
• When the program crashes, the debugger shows the position
in the original code if it is a source-level debugger or symbolic
debugger,
• If it is a low-level debugger or a machine-language debugger
it shows the line in the disassembly

44. Debugger (cont’d)
• Offer more sophisticated functions such as running a
program step by step (single-stepping), stopping
(breaking) (pausing the program to examine the
current state) at some kind of event by means of
breakpoint, and tracking the values of some variables
• The importance of a good debugger cannot be
overstated. Indeed, the existence and quality of such
a tool for a given language and platform can often be
the deciding factor in its use, even if another
language/platform is better-suited to the task

45. Performance Analysis
• A.k.a profiling: investigation of a program's
behavior using information gathered as the
program executes
• Goal: To determine which sections of a
program to optimize - usually either to
increase its speed or decrease its memory
requirement

46. Performance Analysis (cont’d)
• Instrumentation
– Manual: Done by the programmer, e.g. by adding instructions to
explicitly calculate runtimes.
– Compiler assisted: Example: "gcc -pg ..." for gprof, "quantify g++
..." for Quantify
– Binary translation: The tool adds instrumentation to a compiled
binary. Example: ATOM
– Runtime instrumentation: The program run is fully supervised
and controlled by the tool. Examples: PIN, Valgrind
– Runtime injection: Code is modified at runtime to have jumps
to helper functions. Example: DynInst

47. Training Lead
• LinkedIn: www.linkedin.com/in/goutama
• Email: goutama@gmail.com
• Google+: www.gplus.to/goudotmobi
• Skype: goudotinfo
• Twitter: @goudotmobi