Notes and recipes in software development life cycle

1. DEFINEER ACADEMY
www.defineer.com V1.0 1

2.  © 2017 Ertan Deniz All rights reserved.
 Content can be used and shared without permission.
2
COPYRIGHT
www.defineer.com V1.0

3.  Software Engineers should learn similarities from other
engineering diciplines.
 Software Engineers should learn differences between software
product and other engineering products.
 Software Engineering is more than coding. (SW Book,
Brugge&Dutoit)
 Software products should be treated as two distinct domains.
Business and Technology. They should be clearly separated. Main
focus should be on business.
 Software products are developed once, used/copied many times.
This was the specific feature that does not exist in other engineering
products.
3www.defineer.com V1.0
Software Engineering - General

4.  Software Project Managers should know about software processes
and support management activities in a process driven manner.
Resource allocation and scheduling are just some of the activities in
project management.
 Humans (Team Members) are the first class elements in any
software project.
 Like any project, Software project also has limited resources.
(Time, Budget, Humans, Technology)
 First document will be published in any software project should
be scope document. (Project Scope, Problem Definition)
 Includes high level requirements. (Main functionality included
in the system)
 If exists, clearly express the features not included in the system
4www.defineer.com V1.0
Software Project Management

5.  Software development is an engineering process. Firstly, identify
your process by selecting a well-known process. Secondly, customize
it based on your requirements.
 Monitor your software process and collect some metrics to
understand how to improve it.
 Software Process Customizations/Optimizations should be done
incrementally. (Track & Identify & Apply)
 Everytime be ready for change requests.
 Interconnect all the stakeholders (Users, Analysts,
Developers,Testers etc) in a well established communication
infrastructure.
 Develop a common communication language (Formats, Principles,
Models, Activities)
5www.defineer.com V1.0
Software Process Management

6.  Eliciting the requirements
 Firstly, Explain how will you work with the customer. (Users)
 Ask questions to understand the system behaviours.
 If exists, observe the current/old system behaviours.
 Identify the main problems/critical points that puts everyone in
trouble.
 Identify expactations that will make everyone comfortable and happy.
 Documenting requirements
 Explain as real life scenarios and in the form of flow. (Remember that
software statements are executed in flow sequentially or in parallel)
 Since software is an engineering product, it should be expressed in
terms of models that show interaction and dependencies between
elements.
 Share requirements documentation with customer/users and ask
them for validation.
 Requirements elicitation activity should be done incrementally.
6www.defineer.com V1.0
Requirements Elicitation & Analysis

7.  Identify design goals (Simplicity, Performance, Security, Rapid
Development)
Identify tradeoffs and the way to go. (Development time vs
Readability,Robustness; Maintainability,Usability vs Functionality,
Buy vs Build)
 Divide system into smaller subsystems (Subsystem
decomposition)
 Distribute the system responsibilities into sub-systems.
 Next, into classes. (In detailed design)
 Next, into methods (Functions) (In detailed design)
 Systems/Classes should be highly cohesive and loosely coupled.
Details will be published as new presentation (Notes On Object
Oriented Programming)
7www.defineer.com V1.0
Architecture & Design (1)

8.  Think frameworks are made up of reusable software components.
The tradeoff is in which degree software components may be
developed or reused from others. (Open source, Commercial)
 Using frameworks
 Provides high level of reusability
 Tested & Proven components (Developed and maintained by others)
 Decrease the cost of the project
 Easily focus on your business (Separation of concerns)
 Simplifies the development (Hides the complexity)
 Requires a learning curve
 Framework should be supported with many different samples
 If the framework tries to solve too many problems, it may be very
difficult to use after a while.
 Depending on a software framework completely comes with some
limitations. According to the project requirements (especially for larger
projects) these limitations may restrict the movement area.
8www.defineer.com V1.0
Architecture & Design –
Considering Application Frameworks (2)

9.  Developing frameworks
 If software project has no budget contraints and time pressure,
frameworks (i.e technical software components) may be developed.
 Be aware of architecting, developing, maintaining frameworks are hard.
 If there are similar projects in the same domain and reusability of the
framework is an ultimate goal, go ahead. They are like investments. You
pay some times. Next, you gain.
 Frameworks can be developed from stracth or based on pre-built (ready)
components
 It seems very difficult to develop everthing from scratch. Because,
problems are getting complex.
 Architect your framework infrastructure and develop
basic/common functionality for hosting components
 Let pre-built components plugged in.
 You can easiely change the component with the other one.
 Some of the components may developed from scratch within
your project balance.
9www.defineer.com V1.0
Architecture & Design –
Considering Application Frameworks (3)

10.  Model your architecture and design.
 Prepare an architecture documentation.
10www.defineer.com V1.0
Architecture & Design (4)

11.  Write programs that others can easily understand.
 Develop and follow coding guidelines. (Utilize from well-known
guidelines)
 Naming conventions are the first class.
 Firstly give meaningful names to your variables, classes and methods.
 Good naming decreases the documentations in the code.
 Classes/Functions should be in cooperation. Each one does one
job and well. (Unix Philosophy, Single Responsilibity Principle)
 Methods should include maximum 20-30 lines.
 Easily focus on method in the same screen without scrolling.
 Big methods should be converted into smaller methods.(Functional
Decomposition)
 Easy to read and easy to maintain.
 Smaller methods may be reusable.
 Details will be on new page. (Notes On Software Quality)
11www.defineer.com V1.0
Coding

12.  Testing is tightly bound with other activities in a software process.
You test the functionality specified in requirements analysis phase.
Requirement scenario will be the testing scenario. (System Testing)
You realize the integration between components and/or external
systems. (Integration Testing) Interconnection, messages, protocols
will all be specified in design phase and implemented in code
construction phase.
 Write programs to test your programs faster and with high level
coverage. (Unit Testing)
12www.defineer.com V1.0
Testing